to avoid ambiguity, don't allow custom roles named 'student',
'teacher', 'ta', 'observer', or 'designer'
also fix the error message from the api not to assume that
the base role type is invalid
test plan:
- using the api, try to create a custom role with one of the
above names
-> it should tell you the name is reserved
- also, try to create a custom role with a valid name
but an invalid base role type
-> it should tell you the base role type is invalid
Change-Id: Ic7f91a56e79d2929a64780115553ed38aec5f592
Reviewed-on: https://gerrit.instructure.com/15978
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
QA-Review: Adam Phillipps <adam@instructure.com>
This is a convenience method for various places in the UI
that want to show base roles and their types
refs #cnvs-1166
Change-Id: If3138bd0b9bed54bec60c69633e1b704bdda5904
Reviewed-on: https://gerrit.instructure.com/15994
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
also fix a bug in the spec where we weren't testing what we
thought we were testing
test plan:
1. try to create two roles with the same name
in the same account. this should fail.
2a. create a role.
2b. change a permission in the role.
2c. delete the role.
2d. create a role with the same name as the one
deleted in the last step. this should
succeed.
2e. the permission change made in 2b should not
be present in the newly created role
Change-Id: I3d7eb3a3f14c75eb42d1a1da22603b41c7e25b94
Reviewed-on: https://gerrit.instructure.com/15743
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Updates the role permission checking to use base role types
(Account type and enrollment types) when calculating
permissions
Test Plan:
* Test all the permissions
* Test again
* Create custom roles for accounts and each enrollment type
* Change permissions and verify they work correctly
* Delete roles and verify they still enforce permissions
* Create roles in parent accounts and make changes in sub accounts
* Verify those permissions too
closes#11740
Change-Id: Icce22f961065073b27252bb9e2f238de1e59e33b
Reviewed-on: https://gerrit.instructure.com/15735
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* migrate and confirm that the csv in
account.membership_types is now split into
Role objects with base_role_type of
'AccountMembership'
* also, roleoverrides that aren't referenced
in membership_types are assumed to have been deleted
so confirm that a Role is still made
but it is 'inactive'
Change-Id: Ic96c0ecdfd70e5678f74467686a9c9f385e53725
Reviewed-on: https://gerrit.instructure.com/15712
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
test plan:
* specs (for now)
* (once able to check with the UI) test the api actions:
'activate', 'add_role', 'index', 'remove_role' and 'update'
for course roles (by setting the base_role_type argument)
closes#11743#11744
Change-Id: I1b8d54c37cf7dc32b6898349a1b6452349dac7c0
Reviewed-on: https://gerrit.instructure.com/15590
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
closes#11739
test plan: run specs (this is just infrastructure, no
functionality yet)
Change-Id: Icbe5a8db49665cede4371e023c6e37c32a1ad978
Reviewed-on: https://gerrit.instructure.com/15511
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Jeremy Stanley