now that we also cache group permissions (in addition to course ones),
start grabbing the permissions in load_all_contexts. although we cache all
of them, only return ones that are requested (to keep js ENV etc. small)
slight refactor of conversations around permission stuff, and added the
ability to specify an :if check for a permission (i.e. the permission is
only on for a user if the policy says so *and* the :if method returns
true)
test plan:
n/a, see specs (new one, plus existing ones that exercise
load_all_contexts in its various capacities)
Change-Id: I82f4f71edf221c6c859a15156224d8e5b719edc5
Reviewed-on: https://gerrit.instructure.com/12983
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Site admins can manage developer keys. This provides a
basic interface for allowing key management. Admins can
add new keys, edit existing keys, etc. Also adds an
icon url for each key. If keys have an icon url, then
the oauth screen will display this icon to end-users.
test plan:
- manually add a key from the "developer keys" page in
the site admin account
- confirm that the key is created correctly
- edit the key
- confirm that the changes persist
- delete the key
- confirm that the key is properly deleted
- create more than 15 developer keys
- confirm that the page properly paginates
- set an icon url for a key
- do the oauth dance
- confirm that the icon appears in the approval step
- do the oauth dance for a key without an icon url
- confirm that no icon appears in the approval step
Change-Id: I5d64d14974fdcef8be21c6aa84ab13f681217bd7
Reviewed-on: https://gerrit.instructure.com/10979
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
this creates a "plugin" that allows an account to choose
assignment properties that can be locked when a course is
copied
Test Plan:
* enable the plugin for an account
* create an assignment and set it to be locked on copy
* copy the course to another course
* as an admin of the account you should still be able to edit the assignment
* as a non-admin teacher of the course you should not be able to edit the frozen properties
refs #7931
Change-Id: I61d5dbfdf10f8f7519f8db06449b14ef5e7b8454
Reviewed-on: https://gerrit.instructure.com/10190
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
migrate most stuff to :manage_site_settings permissions, use the
already exist :view_error_reports permission as appropriate, and add
a :read_messages permission
also remove one-liner helpers whose only purpose was to default to
the now defunct permission
test plan:
* ensure site admins have no reduced functionality by default
Change-Id: I7e4d5f9a43fd12f96d76add451c7e8ffc03fd553
Reviewed-on: https://gerrit.instructure.com/9954
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
allows course admins to view the course from a student perspective. this is
accessible from a button on the course/settings page. They should be able to
interact with the course as a student would, including submitting homework and
quizzes. Right now there is one student view student per course, so if the
course has multiple administrators, they will all share the same student view
student.
There are a few things that won't work in student view the way the
would for a normal student, most notably access to conversations is disabled.
Additionally, any publicly visible action that the teacher takes while in
student view will still be publicly visible -- for example if the teacher posts
a discussion topic/reply as the student view student, it will be visible to the
whole class.
test-plan:
- (the following should be tried both as a full teacher and as
a section-limited course admin)
- set up a few assignments, quizzes, discussions, and module progressions in
a course.
- enter student view from the coures settings page.
- work through the things you set up above.
- leave student view from the upper right corner of the page.
- as a teacher you should be able to grade the fake student so that they can
continue to progress.
- the student should not show up in the course users list
- the student should not show up at the account level at all:
* total user list
* statistics
Change-Id: I886a4663777f3ef2bdae594349ff6da6981e14ed
Reviewed-on: https://gerrit.instructure.com/9484
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
break out lib/permissions.rb for registering/listing permissions, so
that plugins can register them too without requiring all of
RoleOverride. also, enhance AdheresToPolicy to allow multiple
set_policy blocks for one class, so that plugins can define additional
policies on classes that already have some from stock canvas-lms.
test-plan:
* run specs in vendor/plugins/adheres_to_policy to ensure it didn't
break
* add a permission from a plugin, load the account permissions page,
see the new permission
* add a policy to an existing class from a plugin and add a view
controlled by that policy.
- existing views controlled by existing policies should behave as
before
- new view should be properly controlled by new policy
Change-Id: I9426c2eff37642a7ae01ada869b7c59e7ac178a1
Reviewed-on: https://gerrit.instructure.com/9111
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
and adjust all places we expose SIS IDs to check this permission
instead of manage_users. Adjust permissions UI to show the account
permissions section even for course level roles.
closes#7112
test plan:
* grant teacher read sis, but not manage students. ensure secondary ID
is populated in gradebook2
Change-Id: I6293a91971aa2bc13425839ad52dd59b90bfd3c2
Reviewed-on: https://gerrit.instructure.com/9052
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
provides a role override permission for viewing discussions. primarily useful
for disallowing observers from reading discussion, although by default it is
enabled.
test plan:
- create a course
- create a discussion (d1) in that course
- create a discussion assignment (d2) in that course
- log in as an observer and make sure you can see both discussions above
- log in as an admin and revoke the read_forum permission for observers
- log back in as the observer and make sure you can't see the discussions
- also check that the assignment shows the assignment page, but does not
redirect to the associated discussion.
Change-Id: I4c6441c781c24e6aadacbfc23dcc307c772ecd2c
Reviewed-on: https://gerrit.instructure.com/8069
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
fixes#6194
test-plan:
- create a course
- create a user
- add the user to the course as a designer
(course.add_designer(user).accept in script/console)
- the user should be able to do almost everything a teacher can in the
course
- the user should *not* be able to view grades or user notes
- the user should *not* be included in the course roster
Change-Id: Id0e642fb19906529627917fffac26f0dae378bcc
Reviewed-on: https://gerrit.instructure.com/8047
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jacob Fugal <jacob@instructure.com>
only adds the creation mechanism requested by #6182 for now
test-plan:
- try the API action to create a new admin role specifying
explicit/enabled/lock for some or all permissions
- try without giving a role name; should fail
- try giving an already used role name; should fail
- try using a reserved role name; should fail
Change-Id: I3b38247dccb704da694b0fd32df16cdd63df6810
Reviewed-on: https://gerrit.instructure.com/7553
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
closes#6251
test plan:
* uncheck the new permissions for teachers
* log in as a teacher
* verify that you can't conclude a course, or create/edit/delete sections
Change-Id: I787373442b21079e9987198d0e9b516d64542709
Reviewed-on: https://gerrit.instructure.com/7047
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
phased out AssessmentQuestion#context, did some ground work for #5026
and #5027
Change-Id: Ice4567a0f069dd49da8ce57bf0c8325b0b062115
Reviewed-on: https://gerrit.instructure.com/5303
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
* Daily job to evaluate alerts
* Spawns a new job for each root account (for parallelization).
It could be broken down to per-course level if needed (i.e.
if there is a *huge* root account).
* Evaluating criteria at a course level using efficient queries.
* UI for CRUD on alerts
* Render existing alerts
* Delete existing alerts
* Create a new alert
* CRUD for criteria, recipients, repetition
* Validations
* Improve instructure_helper's formErrors to support passing errors
for specific elements
* Improve Rails' :include to be able to :exclude an :include
inherited from a named scope
* Specs!!
* Note that we want to slowly roll this out, so there is a setting on
root accounts to enable it
So I ran an alert with just an interaction criterion on a test
cluster against 50,000 courses, and it took less than 10 minutes
without any parallelization. That seems like acceptable
performance to me (since there are only just over 3000 courses
in production that would even be elligible to have alerts sent
right now). Of course, that's probably skewed because I'm sure
a bunch of those 50,000 courses were essentially empty.
Change-Id: Ie028ef206c9155b9a72fb2a820f3e0e516de562a
Reviewed-on: https://gerrit.instructure.com/4799
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Basically, being an admin doesn't imply full access. Instead, it
only implies :read_as_admin, which only lets you see things like
course name and section names.
Add two new role overrides:
* :read_course_content implies :read on the course
* :manage_content is now a full fledge RoleOverride instead of
an internal permission implicitly given to Teachers and Admins
Actually start using :view_all_grades override so that Admins
without it won't see grades (replaces :read_as_admin that was
granted to concluded teachers; :view_all_grades is always granted to
concluded teachers, but not to Admins).
Spiffy up several helper functions to take an array of permissions,
and return if any of them are true.
Make sure not to show course tabs that the user does not have access
to.
Fix up lots of permission checks, especially around viewing users
(:read_roster, :manage_students, or :manage_admins might allow you
to see the users in a course; :read_roster only allows you to see
prior enrollments if it was granted to you as an account admin).
Change-Id: Iafcab7956649e9d28e17bd5eedcb155a9ea76af4
Reviewed-on: https://gerrit.instructure.com/5092
Reviewed-by: JT Olds <jt@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
simplifies RoleOverride lookup logic, and the query once again uses
the already existing index
Change-Id: I2b165b7debc9aa7aa6fd032d7917cbbc23b4361c
Reviewed-on: https://gerrit.instructure.com/5063
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
Refs #4952
* Fix saving role overrides for Site Admin account roles
* Add the following permissions:
* read_course_list (for listing or searching courses)
* view_statistics (for viewing account statistics)
* manage_user_notes (instead of being implied-ish by read_reports)
* Hide UI elements that provide access to features that are not
allowed
* Remove lots of not applicable stuff from Site Admin settings
Change-Id: I7414368b472ba655d04118db30c1bb46542deb37
Reviewed-on: https://gerrit.instructure.com/5054
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
closes#4332
* Allow :become_user to be granted to any root account admin role,
not just site admin roles.
* Adjust policy on User objects to properly grant :become_user:
* You can always become yourself (stop masquerading)
* Site admins can become any user besides other site admins
* Root account admins can only become users that are not account
admins, and that belong to accounts that this root account admin
has permissions to
* Adjust masquerading code to check for :become_user on the user
object itself, rather than checking just on the site admin account
* This means we have to figure out the target user before checking
permissions
* Because the permission check already checks for becoming another
site admin user, that special case was removed in the
masquerading code
* Special case the UI to not show the "become" link for the
current user (i.e. you can't become yourself, and you can't
become the user that you already are)
Change-Id: I69bc855b8ee24098b9a63b0b1c8d7edf2063b625
Reviewed-on: https://gerrit.instructure.com/4614
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
So, we have several account level permissions, we just weren't
respecting them. Most notably is :manage_account_settings instead
of :manage, the generic permission.
Account users get all the generic permissions (:create, :read,
:update, :delete, :manage) because there are still lots of course
level things that check those permissions. We still want to keep
those intact until we fix all those other checks, so for account
level things we need to use specific permissions as much as possible.
Things that are either odd or not correctly checked (due to having
to work with courses as a context with the generic permission):
* Listing and searching Courses, and viewing Statistics, is
available to any account admin, because there aren't specific
permissions for them
* Rubrics are not linked to without :manage_outcomes, but are
accesible via direct URI
* External tools is available to any account admin
* Account reports uses the :read_reports permission, which is
described in the UI as "View usage reports for the course"
Change-Id: Ia0f9409659dfc421f1199f7c8ab93b43edcde511
Reviewed-on: https://gerrit.instructure.com/3735
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
RoleOverride.permission_for was accounting for 25% of all objects
allocated when loading my dashboard, this small tweaks drops it to 4%
Change-Id: Id837e0243c5450c7e3b206b70375df2c97e742e3
Reviewed-on: https://gerrit.instructure.com/2652
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
account admins can create "Alerts" from the account
settings page that show up as sticky messages on the
user dashboards. The alerts stay until the end_at
date, or until the user clicks the "close" link. If
you add an alert to the site_admin account then it's
considered a global alert and will go to all root
accounts.
fixes#3738
Change-Id: I47e6eaf717145af24d847d4387e0ad5c36800094
Reviewed-on: https://gerrit.instructure.com/2293
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
In /accounts/*/role_overrides
The value was being saved correctly, but the UI was incorrect and super
confusing. It'd always show a bold "explicit" green checkmark, rather
than the semi-transparent check/cross depending on the actual default.
refs #3711
Change-Id: Ide0a0603b6c820ea0ec94646c4327239d980b09c
Reviewed-on: https://gerrit.instructure.com/2194
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
Once we're storing these permissions caches in a shared memcache
cluster, we can flush them only when they've actually been invalidated.
But until then, we have to flush on each request, in case a role
override was changed on a different app server.
Change-Id: I4479605b96a4fcf36a686033939be4a158aa9699
Reviewed-on: https://gerrit.instructure.com/2224
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
Jacob Fugal