closes FOO-1766
flag = none
[fsc-max-nodes=18]
[fsc-timeout=30]
Test Plan:
- Run the migration and make sure there are no errors
- Some things to check:
* How it acts as a teacher, student, and public user
in course files/folders and personal files/folders
with the various settings above toggled to different states
* How it acts as a teacher, student, and public user
in discussions, modules, content migrations/import/exports
(RCE should behave similarly throughout the site)
* Should only be able to upload or add folders if the
Course Files - add permission is enabled for the user's role
* Should only be able to manage file access, usage rights, move,
or rename course files/folders if the Course Files -
edit permission is enabled for the user's role
• Check Toolbar header at the top of Course files
• Check Cog (hamburger menu) to the right of each file/folder
• Check Usage Rights Indicator under usage rights column
that can be found in course and group file pages. This can
be enabled under course settings if not available
* Should only be able to delete course files/folders if the
Course Files - delete permission is enabled for the user's role
* Any given user/role should have full access to their respective
personal files/folders regardless of granted permissions. The
same also applies to a group context with some caveats
• Should not be able to modify file access in a group context
• Should not be able to modify usage rights in personal files
* A student enrollment not granted any file permissions (the default)
should only be able to _view_ and _download_ files unless granted
additional access from an authorizing role
* REST API works as expected
* UI works as expected with no additional javascript errors
Change-Id: I5e7f717494d658e6c8ec9be8a8039015afcebc63
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262775
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
Note: we'll want to re-run the data fix-up when we're ready to turn
on the feature flag permanently; in hopes to capture any differences
made to course files permissions between now and then.
Modified the files_controller quota and api_quota permission checks
to make them more lenient in regards to accepting any or all of the
files permissions role overrides. This allows legacy grouping and
new granularized files permissions to live in harmony and be modified
without causing unauthorized errors on the quota resource.
This commit will cover the backend permissions required to granularize
files / folders permission calls, however there will be a follow-up
ps to clean up the course file page to hide elements the user might
not be authorized to use.
closes FOO-130
refs FOO-1501
flag = granular_permissions_course_files
[fsc-max-nodes=18]
[fsc-timeout=30]
Test Plan:
- Run the migration and make sure there are no errors
- With the granular_permissions_course_files FF turned off,
course sections and REST API should work the same with this patch
set checked out as it does in beta/production
- Some things to check:
* How it acts as a teacher, student, and public user
in course files/folders and personal files/folders
with the various settings above toggled to different states
* How it acts as a teacher, student, and public user
in discussions, modules, content migrations/import/exports
(RCE should behave similarly throughout the site)
- With the granular_permissions_course_files feature flag turned on
course files/folders and REST API should work as expected. The same
list checked above should be done so again, but this time:
* Should only be able to upload or add folders if the
Course Files - add permission is enabled for the user's role
* Should only be able to manage file access, usage rights, move,
or rename course files/folders if the Course Files -
edit permission is enabled for the user's role
• Check Toolbar header at the top of Course files
• Check Cog (hamburger menu) to the right of each file/folder
• Check Usage Rights Indicator under usage rights column
that can be found in course and group file pages. This can
be enabled under course settings if not available
* Should only be able to delete course files/folders if the
Course Files - delete permission is enabled for the user's role
* Any given user/role should have full access to their respective
personal files/folders regardless of granted permissions. The
same also applies to a group context with some caveats
• Should not be able to modify file access in a group context
• Should not be able to modify usage rights in personal files
* A student enrollment not granted any file permissions (the default)
should only be able to _view_ and _download_ files unless granted
additional access from an authorizing role
* REST API works as expected
* UI works as expected with no additional javascript errors
Change-Id: Ieb2d10915c274959e8da4c623f7aba11d3540c2b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/253777
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: August Thornton <august@instructure.com>
Reviewed-by: Michael Ziwisky <mziwisky@instructure.com>
Change-Id: Ie137c1040260b363979160e1f0558883577ebebd
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/222510
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
teacher specs already test teacher UI; just use factories. also don't
rely on implicit wait timeout to assert nonexistence of stuff
brings group time down from 2:27 -> 0:27
brings slowest example down from 0:26 -> 0:04.7
Change-Id: If1afe575308314bd44ad5e09426d58444b7d34d8
Reviewed-on: https://gerrit.instructure.com/98235
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
Fixes: CNVS-26754
Test plan:
- Open a course or user file page in Safari (and
other supported browsers)
- Rename a file or folder so the name is really long
(see the screencast in JIRA that shows the bug)
- The bug where the filename overlaps the file-type
icon should now be fixed
- Also made a couple of other small enhancements,
which are detailed here:
http://screencast.com/t/kWbJ6CsbImx
Change-Id: I86461da545375d235facf9f750ca00a2764f1c8b
Reviewed-on: https://gerrit.instructure.com/83399
Tested-by: Jenkins
Reviewed-by: Colleen Palmer <colleen@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
QA-Review: Nathan Rogowski <nathan@instructure.com>
fixes SD-1063, speeds up :allthethings:
negative DOM assertions are 💩, but if we must have them, make them
more tolerable. the old way:
expect(f(".something-that-should-be-gone")).to be_nil
expect(fj("buhleeted:visible")).to be_nil
expect(fln("Can't Click Here Anymore").to be_nil
the new way:
expect(container).not_to contain_css(".something-that-should-be-gone")
expect(container).not_to contain_jqcss("buhleeted:visible")
expect(container).not_to contain_link("Can't Click Here Anymore")
(you can of course use these new matchers for positive assertions as well)
although it's a tad more verbose, the new way is better because:
1. it's smart enough to bail once the assertion is met (versus the old way
which would take 10-20 seconds to not find the thing and *then* run the
assertion)
2. it requires them to be scoped, to reduce the likelihood of false
positives (e.g. if the page is totally broken, then of course the
assertion would pass)
also reworked the various flash message assertions... see the new
expect_flash_message and expect_no_flash_message
this should remove over an hour of linear time off the build (10 sec per
old assertion, except fj ones which took 20 sec)... so like a minute of
actual time, cuz parallelization :P
a consequence of this change is that f/fj/ff/ffj now raise if nothing is
found, so you really have to go out of your way to do it the bad way. so
don't :)
Change-Id: I0fe6e8500947c27d748b70bb2cda585edf71e427
Reviewed-on: https://gerrit.instructure.com/78420
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
- reasoning: this group contains set-up and teardown,
it does not include 'it' blocks
Change-Id: I1803420a5c7f59246f3af211e42ced808a994c3f
Reviewed-on: https://gerrit.instructure.com/60329
Tested-by: Jenkins
Reviewed-by: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Matt Fairbourn <mfairbourn@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
August Thornton