This data fixup should be run again now that 10325309 has been merged
in. Before that, developer keys that had scopes that were defined
in a plugin would have run into a validation error when this job
ran the first time.
Keys that were already fixed the first time around will be unaffected
by this second run.
fixes INTEROP-7615
flag = none
Change-Id: Iecf0be69f072cc1893daf7e72eca6557a3ceb765
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/300179
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Tucker Mcknight <tmcknight@instructure.com>
Reviewed-by: Steve Mcgee <steve.mcgee@instructure.com>
refs QUIZ-9572
flag=none
test plan:
- check that your Quiz LTI ContextExternalTool
record does not have the canvas_rcs_host custom field.
- execute rails db:migrate
- check that your Quiz LTI ContextExternalTool
record HAS the canvas_rcs_host custom field
Change-Id: I3d66a6d88698b1c83ce047ae21c289f82417beff
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/295040
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
Migration-Review: Ben Rinaca <brinaca@instructure.com>
QA-Review: Endre Berki <endre.berki@instructure.com>
Product-Review: Endre Berki <endre.berki@instructure.com>
test plan:
- enable the scheduled page publication feature in
your account
- create or edit a page and set a publish_at date
in the near future
- wait for that time (and ensure jobs are running and
not backlogged)
- ensure the page became published (and its module item was
published if it's in a module)
- ensure when a page scheduled to be published in the future
is copied as part of course copy, the copy gets published
at that time too
- unless dates are shifted. the publish_at date should be
shifted the same as the others
- if a page is scheduled for publication in the near
future, then the course is copied after the page is
published, shifting the publish_at date into the future,
the page in the destination course should be unpublished
(and the calendar icon should show the publication date)
- ensure when a page in a blueprint associated course is
automatically published, future syncs still update the page
(the auto-publish isn't counted as a downstream change
that causes sync exceptions)
- on the pages index, a page that is scheduled for publication
but not yet published shows a red calendar icon in place of
the gray circle-slash thing ordinarily seen next to unpublished
pages
- same goes for the modules page
and the button at the top of page show
- clicking the icon lets you publish the page now,
unpublish it (remove the scheduled publication), or
change the publication date
- when a page that is scheduled for publication is included in
an unpublished module, publishing the module doesn't publish
the page (and you get a notice)
if the feature is turned off after scheduling pages to be published,
no evidence of it is visible in the UI and the page will not be
published when the time arrives. (we figure this is easier than
updating all pages in the account to wipe the publish_at date
for a scenario that doesn't seem likely to begin with anyway)
note that I removed the tooltip from the publish button on page show
because it always duplicates the button text, but the tooltip
remains on the publish icon
closes DE-1346
flag=scheduled_page_publication
Change-Id: Iba16b3d788bcb0051e022e2706446020e6b8171b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/297715
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ed Schiebel <eschiebel@instructure.com>
QA-Review: Ed Schiebel <eschiebel@instructure.com>
Product-Review: David Lyons <lyons@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
why:
* explicitly set lti version on tool model instead of in settings hash
* remove all direct usage of settings["use_1_3"]
* set lti_version: 1.3 on all tools that have 1.3 in settings
closes INTEROP-7598
flag=none
test plan:
* have a 1.3 ContextExternalTool that has a developer_key associated
with it and `use_1_3: true` in its settings hash
* run `dcr web rake db:migrate`
* reload that tool - it should have lti_version: 1.3 and not have
use_1_3 in its settings hash
Change-Id: Ib82aedaf1a19fec48eab28f9cd408c4712ec21c0
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/298327
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
closes INTEROP-7597
flag=none
test plan:
* have a 1.3 tool installed
* by default it should have an lti_version of "1.1"
* `dcr web rake db:migrate`
* reload that tool - it should have an lti_version of "1.3"
* create a new 1.3 tool using an LTI developer key
* that new tool should also have an lti_version of "1.3"
Change-Id: I446a523f62c4de58386375c4223dbfc9ac2e184d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/298589
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
why:
* explicitly set lti version on tool model instead of in settings hash
* remove assumption that the presence of a developer_key_id means that
a tool is 1.3
* include new column in tool import/export
closes INTEROP-7596
flag=none
test plan:
* run `dcr web rake db:migrate`
* in a Rails console, run `ContextExternalTool.last`
* the model should have an lti_version of "1.1"
Change-Id: I101111a17f6ce06c466c142e7b312e6ba7c5149f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/298326
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
why:
* the last fixup mistakenly only searched for resource links created
since 7/26 (since the first hotfix that introduced this bug)
instead of since 6/12 (the initial commit that added urls to resource
links and made this bug possible)
closes INTEROP-7580
flag=none
test plan:
* with a course with at least one resource link in it
(either LTI assignment, LTI module item, or LTI content item in an RCE),
that has a nil url (this is the old way of doing it and
you may need to manually create one like this)
* create a new course and Import Existing Content
* choose the original course as a source
* in a rails console, find all Lti::ResourceLinks associated
with the newly copied course
* update all of their created_at to be before 6/12,
and all of their urls to be not nil (you could use the tool's url since
that is what happened before the bug fix)
* run `DataFixup::FixResourceLinksFromCopiedCoursesNullUrls.run`
* these resource links should correctly have nil urls
Change-Id: I587a194ba96cc428b3880dd516870f33ba26f8e9
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/297808
Reviewed-by: Paul Gray <paul.gray@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
why
With resource_links now having urls, when looked up via retrieve, the
url launched is taken from the resource link's url column. If that
column is nil, then the tool's url will be used. Some resource links
rely on this behavior to launch the url. During course copy, the url in
the export is now included in the export and persisted in the import,
causing all imported resource links to never persist a nil url.
This commit updates the exporter with a new custom property in the cc
export, a resource_link_url, which includes the url column from the
exported resource_link. The importer will use this to populate the new
resource link's url column, and will use the standard cc launch_url
simply to lookup the tool to associate.
fixes INTEROP-7572
flag=none
test plan:
Find an existing course with a resource_link that has a nil url, and
copy that course. the new course should have the same resource_link,
except the url in the new resource link should still be nil.
Change-Id: I62f85689a4a6a7a2cbd8f95f82c6dde343d7b8e0
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/297340
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Paul Gray <paul.gray@instructure.com>
fixes LS-3162
flag=course_paces
[fsc-max-nodes=18] [fsc-timeout=30]
test plan:
- Configure course paces in a course
- Make that course a blueprint
- Associate it and sync it to a second course
- Check that the proper assignment durations
flow downstream
- Alter course pacing in the child course
- Check that on further syncs downstream
changes aren't overwritten
- Lock the duration for some assignments
- Check that on further syncs those durations
are now overwritten
Change-Id: I0a92835407566bd47581c7782039def18d31fe2c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293351
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Robin Kuss <rkuss@instructure.com>
QA-Review: Robin Kuss <rkuss@instructure.com>
Product-Review: Allison Howell <allison.howell@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
why
Previous to g/293521 the lti_resource_links table did not have a url
column. That commit added it, and modified resource links added via RCE
to rely on the url in the resource link. The resource link exporter
wasn't updated to copy this url, instead, using the associated tool's
url. When courses were copied, they use the export/import logic, and so
resource links were being copied without the correct url.
test plan:
Create a course with a single assignment, which is RCE text content.
Inside that text, add a Deep link url chosen from the lti13testtool,
when launching, you'll see that the
`https://purl.imsglobal.org/spec/lti/claim/target_link_uri` claim has a
url with a `deep_link_location` parameter.
Copy the course, and find the same assignmnent you created, and click
the link. The launch should contain the same `deep_link_location`
parameter.
fixes INTEROP-7562
flag=none
Change-Id: I62deea4f9fdc232d9e6069e7f02cd399a3bcd923
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/296776
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
This api will be used by students and admins to see what account
calendars are available (all available calendars, not the calendars
that the user is "subscribed" to). It will also be used by admins to
set account calendar visibility.
Includes a miration to add an account_calendar_visible column to the
accounts table. This is preferable to using a setting on Account since
we'll be querying accounts using this valueas a parameter and prefer
the performance of a column.
closes LS-3253
flag = account_calendar_events
Test plan:
Part 1: index
- Enroll a user in a few courses in different accounts
- GET /api/v1/account_calendars as that user
- Expect to see an entry for each account where the user has an
enrollment, as well as all of those accounts' parents, up the chain
- In the rails console, set one of the account's calendars as hidden:
account = Account.find(x)
account.account_calendar_visible = false
account.save
- GET /api/v1/account_calendars again, and expect the same result as
before, but without the hidden account
Part 2: show
- GET /api/v1/account_calendars/xyz as the user from before, where
xyz is the account id of one of the user's associated accounts
- Expect to see the account calendar details
- Try to request an account calendar that the user doesn't have
access to; expect to see 401
- Attempt to access the hidden account calendar; expect a 401
- As an admin with the manage_account_calendar_visibility
permission, attempt to access the same hidden calendar; expect
success
Part 3: update
- As an admin with manage_account_calendar_visibility permission,
PUT /api/v1/account_calendars/xyz with param visible=<true/false>
- Expect the visibility to be updated accordingly
- Try to update visibility as a student (or any user without the
permission); expect 401
Part 4: all_calendars
- As an admin with manage_account_calendar_visibility permission,
GET /api/v1/accounts/xyz/account_calendars, where xyz is the
*root account* id
- Expect a list of all account calendars for the entire
institution, regardless of visibility status
- Expect this request to return 401 for students or admins without
the permission
Change-Id: I0a3bcd58b509c62326b0a885b87ec3f8779fcd37
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/296293
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Eric Saupe <eric.saupe@instructure.com>
QA-Review: Eric Saupe <eric.saupe@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jackson Howe <jackson.howe@instructure.com>
Create a new database migration file to add a boolean variable
to the calendar events that shows whether it is a blackout date
or not. Add a test to make sure this field is there in
spec/models/calendar_event_spec.rb
closes LS-3290
flag=account_level_blackout_dates
Test Plan
- Open the project in the command line
- Run `rails db:migrate`
- Run `rails db:migrate RAILS_ENV=test`
- Run `rails c`
- Run `CalendarEvent.last`
- Notice that the `blackout_date: false,` field is somewhere in the output
- Run `rspec spec/models/calendar_event_spec.rb`
- Notice that the tests pass
Change-Id: I4ba40323afe92320cdc69ff7b4fddc43ef30fb50
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/296579
Reviewed-by: Jackson Howe <jackson.howe@instructure.com>
QA-Review: Jackson Howe <jackson.howe@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Joshua Richardson <joshua.richardson@instructure.com>
Adds median and quartile calculations, and uses them to generate a
proper box and whiskers plot.
fixes GH-1871
fixes GH-1139
flag = enhanced_grade_statistics
test plan:
- Grade an assignment for at least 5 students
- Verify the student view score details show median and quartile
numbers
- Verify the box plot matches those numbers and looks reasonable
Change-Id: I6ce4b792a112eed72df095503a6f4e82da2912c1
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/242741
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Spencer Olson <solson@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Jody Sailor
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Several API routes were changed in ceed52fc49.
This data fixup will change the scopes field for any developer
keys that references those API routes, and change them to
the new API routes.
flag = none
test plan:
- Create a developer key, either in the UI or the rails console,
and limit it to some API routes.
- Temporarily change one of those API routes in config/routes.rb
- Run the data fixup manually, like so:
```
old_route = "url:GET|/api/v1/your_chosen_route"
new_route = "url:GET|/api/v1/what_you_changed_it_to"
change = [ { old: old_route, new: new_route } ]
DataFixup::UpdateDeveloperKeyScopes.run(0, DeveloperKey.last.id, change)
```
- Also see that it works by running the migration (and adding your
changed route to the list of routes in the migration file).
- Verify that when you look at developer_key.scopes, the route is
changed.
- Poke around the developer keys page and verify that things still work.
Change-Id: Ia0f522b12e53c424de1ef48d1c5904c5d21bb899
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/295903
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Tucker Mcknight <tmcknight@instructure.com>
closes INTEROP-6817
flag=none
Why:
- When a user's primary email changes, if the root account is set up to
use email as the login attribute, mapping which maps the user to the
Microsoft 365 user will be out-of-date.
- We never delete UserMappings except when changing Microsoft Sync
settings at an account level so currently this is almost impossible
for customers to rectify
I didn't want to actually immediately delete a mapping, because if a
CommunicationChannel changes in the middle of a sync, the missing
UserMapping could cause us to remove the user from the Microsoft 365
group, even if the user's primary email has not even really changed (for
instance, if the user added a non-primary email). So instead I use a
needs_updating field.
Test plan:
- Make sure you have an account set up with Microsoft Sync using email
as the login attribute.
- Make sure you have a course set up with Microsoft Sync, ideally with
2+ users. Make sure it is successfully synced so that there are 2+
users in the group visible in Microsoft 365 admin console.
- Look at one of the users who has a account in the Microsoft 365
tenant and change their primary email address to another email address
of a another user on the Microsoft 365 side
- Manually sync the course
(course.microsoft_sync_group.syncer_job.run_synchronously)
- Look in the Microsoft 365 admin console and check that the old user
has been removed and the new user has been added to the group.
- Change the email address again to something not corresponding to any
user on the Microsoft side
- Sync again and see that the user has been removed from the Microsoft
group
- Make sure one of your tests used the API to update the email address
- add a communication channel with the POST API endpoint, e.g.:
tok http://canvas-lms.docker/api/v1/users/123/communication_channels \
communication_channel[type]=email \
communication_channel[address]=someaddress@example.com \
skip_confirmation=true
- remove the old communication channel
tok http://canvas-lms.docker/api/v1/users/123/communication_channels
tok delete http://canvas-lms.docker/api/v1/users/123/communication_channels/456
- Repeat the steps above but update a primary email address from a
SIS import. You should be able to do this by creating a users.csv file
like this and uploading with "SIS Import" in the account menu (and
choose the "Override UI changes" checkbox):
user_id,login_id,first_name,last_name,email,status
sisuser1,sisuser1login,FirstNameOne,LastNameOne,myemailaddress@instructure.com,active
- from a console, set the needs_updating on user's UserMapping to false,
then destroy one of the user's email communication channels with
commchannel.destroy_permanently!
- make sure the UserMapping has gotten needs_updating set to true
- destroy all email communication channels for a user, or make all their
communication channels something without a user on the Microsoft 365
side. Sync the course. The user should be removed from the course
(note that you cannot remove the last course owner), and the
UserMapping should no longer exist at all.
Change-Id: I9e2f3d5e439bebc8c9eaf89b1595908213dc1981
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294820
Product-Review: Alexis Nast <alexis.nast@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Migration-Review: Ben Rinaca <brinaca@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
closes LS-2805
flag=calendar_series
I do not know how to test the message channels
for sms, summary, twitter
test plan:
for notifications to work the email communication channel
must be confirmed for your student(s). For the student, do
stud = User.find(student_id)
c = stud.communication_channels.where(path_type: "email")
c.first.confirm
it will help to know how to find messages being sent to students
in the console:
Message.where(context_type: "CalendarEvent").pluck(:id, :subject)
# find the id with the title of the event you just created
Message.find(:id)[:body]
# or for html email
Message.find(:id)[:html_body]
in psql canvas_development
select id, subject from messages where context_type='CalendarEvent' order by created_at;
-- find the id of with the title of the event ou just created
select body from messages where id=<message_id>;
first with a single event
- as a teacher, create a calendar event in your course
- inspect the messages table
> expect a message like
There's a new event scheduled for Course 1 that you should be aware of:
etc.
- now create a recurring event series in your course
- inspect the messages table
> expect only 1 message for the event series
> expect the link in the message to point to the first event
in the series
> expect the message to now include text about how it repeats.
> expect the message "html_body" column to also include text
about how it repeats
Change-Id: I68b576710896c26bef12d15e2ae44fcc8385564d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/295025
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jackson Howe <jackson.howe@instructure.com>
QA-Review: Jackson Howe <jackson.howe@instructure.com>
Product-Review: Allison Howell <allison.howell@instructure.com>
Migration-Review: Alex Slaughter <aslaughter@instructure.com>
also, allow arbitrary length to error report's subject column.
closes FOO-2912
flag = none
Test plan:
• trigger a HelpDialog CreateTicketForm component to render
the ticket dialog form
• ensure no more than a generous 200 characters gets posted
on form submit for the "error[subject]" input
Change-Id: I2c8f32e25bba1a0c5593fac0e6feb66367f8c3be
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/295080
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
This commit adds the ability to update events in a recurring series.
It should behave like google calendar.
(also slipped in an auth check to destroy_from_series)
when which="one"
- update the one event whose id is in the url
- invalid request if the rrule changed
when which="all"
- update all events in the series
- invalid request if the start_at date changed
(time is OK)
- if the rrule changed, the series may get more or fewer
events.
when which="following"
- update the event from the URL and all those after it
- if the rrule changed, the series may get more or fewer
events
- if the start date or time changed, it creates a new
series with the updated events
- in all cases, the api returns the updated events
- if a series shrunk as a result, the deleted events
are not returned by the api.
- if the series spans a DST transition, the wallclock
time of the event should remain consistent
NOTES: I know nothing about sharding. Did I screw anything up?
closes LS-2804
flag=calendar_series
test plan:
- with calendar_series site_admin flag on
- create a recurring event series with the create api
POST to /api/v1/calendar_events
the data should be event data + an rrule. For example:
{"calendar_event":{"title":"abbbaa",
"start_at":"2022-11-04T12:00:00-06:00",
"end_at":"2022-11-04T13:00:00-06:00",
"context_code":"user_1",
"rrule": "FREQ=DAILY;INTERVAL=1;COUNT=4"}}
- modify the series with the update api
PUT to /api/v1/calendar_events/:event_id
JSON with the new properties. The JSON looks just
like the create, but with new values in there.
> expect the returned events (or more easily, refresh
the calendar in Canvas) to be what you expected
> expecdt to see only 1 sql UPDATE setting the
context's updated_at time, no matter how
many events were updated.
Some interesting test cases
- the invalid requests (see above)
- which="following" with a new time
- which="following' with a new date
- which="following' with a new rrule
- which="all" with a new rrule
- a new rrule that makes the series longer
- a new rule that makes the series shorter
Change-Id: I9fa6ed0e90887510e9f7a38575dd7aa182e7e09f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293568
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
Reviewed-by: Jackson Howe <jackson.howe@instructure.com>
QA-Review: Jackson Howe <jackson.howe@instructure.com>
Product-Review: Ed Schiebel <eschiebel@instructure.com>
refs MAT-890
flag=none
[ignore-stage-results=Flakey Spec Catcher]
Test plan
- Delete a file using the API like this
DELETE https://<canvas>/api/v1/files/:id?replace=true
- Then in the console, find the attachment and
restore using "resurrect_from_purgatory" and
make sure it works and looks right
- I don't think there's a good way to test
what happens with mixed instfs/older files
Change-Id: I2a8f506a648c704fafccab8b17620d43aab4b1dc
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293368
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Gonzalo Penaranda <gonzalo.penaranda@instructure.com>
QA-Review: Gonzalo Penaranda <gonzalo.penaranda@instructure.com>
Migration-Review: Alex Slaughter <aslaughter@instructure.com>
Product-Review: Mysti Lilla <mysti@instructure.com>
why:
Resource Links created via the RCE lti integration
include the url as a parameter. This url can be changed
by anyone, and thus a user can launch any tool by modifying
the url parameter.
This path introduces a url column to the resource links
themselves, which keeps track of the urls, so they are
not provided via a paramater that can be modified. Since
existing links are stored in the db as HTML, they will
not be migrated in this patch, and so the retrieve
endpoint will still default to the url for existing links.
In addition to populating the url column for Deep Links
created via the RCE plugin, there are other instances where
it will now be populated:
1. RCE Deep Linking
2. Assignment Deep Linking
3. Content Tag Deep Linking
4. Resource Link Importer
flag=none
fixes INTEROP-7072
test plan:
1. Create an LTI Deep Link via RCE (You can use the LTI Testing Tool)
Ensure the link's href does not contain a url parameter, and ensure
that the retrieve endpoint correctly redirects
2. Create an assignment via Deep Linking, and ensure it works properly
3. Create a Content item in a module via deep linking and ensure it
works properly
4. Export a course that has a resource link, and import it,
and ensure the resource links still work properly.
Change-Id: Icee4320ab0977f6c18db49a1afe9f588d816084f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293521
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Migration-Review: Ben Rinaca <brinaca@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
refs FOO-2959
rather than log diving when a user's login is deleted, we can record
the who and where for easy look-up.
test plan:
* create a user with multiple logins
* delete one of those logins
* find the login record in the rails console and do `.auditor_records`
to it, you should get a record that shows you who did it, when, and
where
flag = none
although there is a killswitch, pseudonym_auditor_killswitch, if it
needs to be turned off for some reason
[pin-commit-multiple_root_accounts=5dc6158fa2023833311a3c8f7bf037b1d517ac26]
Change-Id: I7828d0b96be4790c2cfbf92d821a371b9a290867
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293431
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Ben Rinaca <brinaca@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
flag=none
test plan:
- assignments table has an index on workflow_state
Change-Id: I0fe95622fb8dce8af6c77c6270a841d0e545227a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293661
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Alex Slaughter <aslaughter@instructure.com>
Product-Review: Alex Slaughter <aslaughter@instructure.com>
Migration-Review: Alex Slaughter <aslaughter@instructure.com>
closes LS-2797
flag=none
test plan:
- run bin/rake db:migrate RAILS_ENV=development
- run psql canvas_development
- in psql exec \d calendar_events
> expect to see series_id and rrule columns
> expect to see an index on series_id
Change-Id: Icd0fcafd18adcd0d277b92d939dd0908d98b7fbd
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293120
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Robin Kuss <rkuss@instructure.com>
QA-Review: Robin Kuss <rkuss@instructure.com>
Product-Review: Ed Schiebel <eschiebel@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
Change-Id: Iad400936d7e53a5f92644f260c95bfb5bf9e972f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293144
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Jacob Burroughs <jburroughs@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: August Thornton <august@instructure.com>
Reviewed-by: Alex Slaughter <aslaughter@instructure.com>
Migration-Review: Alex Slaughter <aslaughter@instructure.com>
test plan:
- create a job that will fail
(e.g. `delay.raise "whoops"`)
- find the failed job in /jobs_v2 and click its id
- scroll down to the job details table and click the
"requeue job" button
- the job should be requeued and the id of the requeued
job should appear in place of the button
- search that id and you should find the newer failed_jobs
entry (after the requeued job fails)
flag=jobs_v2
closes DE-1194
Change-Id: I33d637db616aad1ec431428e7c5c60c6253660aa
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/292334
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Isaac Moore <isaac.moore@instructure.com>
QA-Review: Isaac Moore <isaac.moore@instructure.com>
Migration-Review: Alex Slaughter <aslaughter@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
Before this change, if an assignment was assigned to a section that a
student was deactivated in AND that student had another enrollment in
the course that was active, the student would maintain visibility of
the assignment. After this change, students will no longer be able to
see assignments that are assigned to sections they are deactivated in.
closes EVAL-2262
closes QO-707
flag=none
[fsc-max-nodes=20]
[fsc-timeout=45]
Test Plan 1:
* Pre-requisites: Migrations have been run, and a student enrolled in
two sections of the same course (A & B), and an assignment assigned
only to the B section.
1. As the student submit to the assignment.
2. Assign a grade to the student for the assignment.
3. Go to the user page for the student (courses/:course_id/users/:id),
click 'more user details...', and then hover over (but do not click)
the 'Conclude this Enrollment' or 'Delete this enrollment' link for
the section B enrollment and you should see the URL in the bottom
left-hand side of your browser that has the enrollment ID in it
(i.e. /courses/:course_id/conclude_user/:enrollment_id). Take note of
the enrollment ID and then make an API request to deactivate that
enrollment:
DELETE <host>/api/v1/courses/:course_id/enrollments/:enrollment_id
?task=deactivate
4. Act as the student and verify the assignment cannot be accessed.
5. Make an API request to reactivate the enrollment:
PUT <host>/api/v1/courses/:course_id/enrollments/:enrollment_id
/reactivate
6. Act as the student and verify the assignment can be accessed.
Test Plan 2:
* Pre-requisities: Migrations have been run.
1. Create a course with 2 sections.
2. Create a quiz with access dates in the past assigned to only one
section
3. Create a student in the course with an active enrollment in one
section and an inactive enrollment in the other section
(this should be the section assigned to the quiz). See Step 3 on
Test Plan 1 for how to deactivate the enrollment.
4. As the student navigate to the quiz and see you do not have access
to take the quiz. You should see a flash message that reads,
"You do not have access to the requested quiz." and you should be
redirected to the quizzes index page.
Change-Id: Ic00d9189ae40972fefa0352e12e137a3ac0cd73f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/289631
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Kai Bjorkman <kbjorkman@instructure.com>
Product-Review: Jody Sailor
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Reviewed-by: Kai Bjorkman <kbjorkman@instructure.com>
why:
* to conform to LTI spec by returning endDateTime
in the response of AGS create/update calls
* though the date is now stored twice (once on Assignment, once on
Lti::LineItem), there is a situation where they can be different
(set on line item that's not the primary for the assignment), even
though that wouldn't actually do anything
refs INTEROP-7265
flag=none
test plan:
* run migrations
* follow test plan from parent commit to create/update line item
using AGS API
* note that the endDateTime attribute is present in the response
Change-Id: Id3bbdd5f328476fb02fd96a005a655902fa8dac4
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/291045
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
It turns out when we query for effective due dates, which happens
in due_date_cacher, we fetch all students affected by adhoc overrides.
This happens with a join on AssignmentOverrideStudent, so without
accounting for such objects, we have logic that just deletes the
submission if it's not "viewable" to the target user.
fixes FOO-2773
flag = none
Test plan:
• Create an assignment and assign it to the one student with a
due date (Assignment due date override for individual user)
excluding the "everyone" default section scope
• Create a second user and merge the first student into the
newly created user
• Check the submission API for the merged student and assignment
and notice that the "cached_due_date" displays the assigned due
date used when creating the assignment and the workflow state is
is as it was before "unsubmitted"
Change-Id: Ic9701326a9dac0f8a44dbddfad59738032be230a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/290068
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ben Rinaca <brinaca@instructure.com>
Migration-Review: Ben Rinaca <brinaca@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
In a subsequent commit, this will allow a setting to be marked as
"secret", and its value redacted in the forthcoming Settings UI.
refs DE-1138
flag=none
test plan:
- verify the column is added, and `setting=` is successful
Change-Id: I0dfad0ea584e199828ff04fabe91964069d3e676
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/289857
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Isaac Moore <isaac.moore@instructure.com>
Product-Review: Isaac Moore <isaac.moore@instructure.com>
fixes LS-757
flag=none
test plan
- Verify Mastery Path is no longer in Feature Options
- Verify the setting is there on the account settings
- Verify that locking it disables changing it for subaccount and courses
- Verify that with the setting on all of mastery path still works
Change-Id: I9ee1b243439eb2eefa35885ecfce0db7589fbe13
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/288418
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Jackson Howe <jackson.howe@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jackson Howe <jackson.howe@instructure.com>
Product-Review: David Lyons <lyons@instructure.com>
refs DE-1048
Change-Id: I0a090f01fa40265aed7c3353f685000453bc2bc2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/288424
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
refs DE-1108
Change-Id: I6537f03215a40d3789177bcd72a74435551aa6b3
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/288384
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
fixes LS-2989, LS-2988
flag=pace_plans
test plan:
- Specs should pass
- Enable the course paces account feature flag
- Enable the course paces setting on a course
- All current pacing related features should work as expected
Change-Id: Ibd1d9f3295f624a3f2411c72ad5ace9410d965ca
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/286519
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Eric Saupe <eric.saupe@instructure.com>
Reviewed-by: Robin Kuss <rkuss@instructure.com>
QA-Review: Robin Kuss <rkuss@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
closes LS-3036
flag = none
Change-Id: Idf26d753b0bced34f33dc0619b693a93df8e6dd7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/286935
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Isaac Moore <isaac.moore@instructure.com>
Reviewed-by: Robin Kuss <rkuss@instructure.com>
QA-Review: Robin Kuss <rkuss@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jackson Howe <jackson.howe@instructure.com>
Change-Id: I9370a96eb9eb0fde8c11f0243dc0785489002a55
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/285831
Reviewed-by: August Thornton <august@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Jacob Burroughs <jburroughs@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
Test plan:
- Create SIS Import with
diffing_data_set_identifier set
- Create another SIS import with the same
identifier and diff_row_count_threshold provided
When number of changes is below the threshold the
diffing_threshold_exceeded flag should be false.
When number of changes is above the threshold the
diffing_threshold_exceeded flag should be true.
When diffing_data_set_identifier does not exist,
value should not be in the response.
Closes SOS-2471
flag=none
Change-Id: Ieda0c0d6ba595ea06e6d3dd301bcc4c52268a0be
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/285844
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Tamas Nagy <tamas.nagy@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Balazs Komaromi <balazs.komaromi@instructure.com>
Product-Review: Balazs Komaromi <balazs.komaromi@instructure.com>
Change-Id: I89129633731a68c38a5026b6b26318d1f3699a2a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284968
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: August Thornton <august@instructure.com>
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Jacob Burroughs <jburroughs@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
refs INTEROP-7066
flag=none
Test plan
- Have two tools with the exact same set up
for name, description, context, key, secret,
settings, domain, url and workflow_state
- Remove their identity_hash
- Run the database migration
- One should end up with a real identity hash
- The other should end up with "duplicate"
in their identity hash
- If you need an example, the Vimeo setup on
eduappcenter is pretty simple
- Try with various set ups of tools that already
have identity_hash filled in and duplicates
of those versus tools that don't already
have an identity_hash that are duplicates
- Should use the identity_hash index on
large context external tools table, but
you probably can't tell locally
Change-Id: I1b05e2cdecfd24895cb864e4234e9853290fa3b9
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284611
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Mysti Lilla <mysti@instructure.com>
This PS uses most of the work done in the previous implementation.
The main difference is the moment when the word count is calculated,
a new column was created to store this value at the moment of
saving the file, this will avoid requesting the AWS s3 bucket for
each file when loading the speed grader
flag=word_count_in_speed_grader
fixes LS-2922
test plan:
- Enable word count in speed grader flag
- In a course that has many attachments in speedgrader
- Create an assignment that requires submissions
- Submit a PDF, RTF, TXT, and DOCX file
- In speed grader, verify the word counts are present when
selecting the different files
Change-Id: I7262afe43787ffdf7859fbf2d10cd16a52521996
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283607
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Eric Saupe <eric.saupe@instructure.com>
QA-Review: Eric Saupe <eric.saupe@instructure.com>
Product-Review: Jonathan Guardado <jonathan.guardado@instructure.com>
fixes INTEROP-7066
flag=none
Test plan
- Have two tools with the exact same set up
for name, description, context, key, secret,
settings, domain, url and workflow_state
- Remove their identity_hash
- Run the database migration
- One should end up with a real identity hash
- The other should end up with "duplicate"
in their identity hash
- If you need an example, the Vimeo setup on
eduappcenter is pretty simple
- Try with various set ups of tools that already
have identity_hash filled in and duplicates
of those versus tools that don't already
have an identity_hash that are duplicates
Change-Id: I73cf92afb3eceef190d24d169a21ffadf909577e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/282597
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Mysti Lilla <mysti@instructure.com>
fixes INTEROP-7064
Test plan
- Save a new context external tool
- Ensure it has an identity hash field on the tool
- Save the exact same context external tool
- Ensure it says "duplicate" in the identity_hash
field on the tool
Change-Id: I4690b64d3940d2cfd62f982821658fffb459f049
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/282138
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Mysti Lilla <mysti@instructure.com>
refs MAT-625
flag=none
Test Plan:
- Verify you can create, edit, and delete files
as before via the UI. UIs can be found at /courses/:id/files
and /users/self/files.
- In a rails console, run the following:
```
course = Course.find(<some course with files uploaded>)
course.attachments.last.update!(category: Attachment::BUTTONS_AND_ICONS)
```
and verify no errors are raised.
- In the same rails console, run the following:
```
course.attachments.not_buttons_and_icons
```
Verify the list of returned attachments does not include
the attachment that was updated in the previous step.
Change-Id: Iab251a0de82a2a1dfcfe0cb19864957b8f440a2c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283443
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jon Scheiding <jon.scheiding@instructure.com>
QA-Review: Jon Scheiding <jon.scheiding@instructure.com>
Product-Review: Weston Dransfield <wdransfield@instructure.com>
Migration-Review: Alex Slaughter <aslaughter@instructure.com>
fixes FOO-2671
flag = none
Test plan:
• After checking out this patchset run:
• `rails db:migrate`
• `./script/nuke_node.sh`
• Using the default Themes templates found under /brand_configs
select or ensure you're using the Default Template and navigate
to the Global Navigation dropdown tab
• Verify the default "Nav Badge Active" color is set to: #0374B5
• Verify the default "Nav Badge Text Active" color is
set to: #ffffff
• To trigger a notification badge to appear on one of the global nav
menu items, it's easiest to just send a message via Inbox to
the user in question that is under test. You will then be able
to verify the badge has a white background with black text
indicating the number of notifications needed to be read
• See associated Jira for more details and acceptance criteria
Change-Id: Iebbfd850fc5e3cdba47ee8ac145dbaa6ef799484
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283057
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ben Rinaca <brinaca@instructure.com>
Migration-Review: Ben Rinaca <brinaca@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
refs CORE-1981
flag = none
BrandableCSS and BrandConfig are coupled to 2 migrations for reasons
explained below. There was code introduced to validate the integrity of
these migrations at runtime, which proved very hard to troubleshoot as
code around it changed. Now one of those checks is done at build time,
the other dropped as it's not necessary.
TL;DR you need to compile the assets before migrating the DB. And if you
modify the brand variables but fail to rename the migration files, the
build will fail and tell you about it.
////////
DETAILS
\\\\\\\\
If you follow the trail of patches surrounding the now-removed code in
lib/brandable_css.rb, you will note that the intent was to behave more
friendly towards people who are:
1. modifying the default branding variables
2. setting up canvas for the first time
The case for the former is that anytime you modify a variable value,
or replace an image referenced by a variable, the BrandConfig records
in the DB must be re-generated with those new values in mind. This
process takes place in "special" predeploy and postdeploy migrations.
I say "special" because their names have semantics beyond what
ActiveRecord assigns to DB migration names: the digits in their name
denote not a date, but actually the numeric subset of a MD5 digest of
the brand default variables at the time of writing. This is now clearly
expressed in the migration files themselves. Additionally, the check for
this correspondence between the default variables and their migrations
is now done in a spec as opposed to anytime BrandableCSS is interfaced
with at runtime.
Which takes me to the second case: for BrandConfig records to be written
to the DB, we must be able to calculate that digest, possible only if we
have the fingerprints for images and other static assets, which comes
from Gulp. This makes Gulp, or in practice "rake canvas:compile_assets",
a dependency of this operation, one that is communicated already in our
documentation - both public and internal. This is no longer enforced or
checked for in the codebase.
___\______
~ TEST PLAN ~
____.
- change some variable value in app/stylesheets/brandable_variables.json
- rerun spec spec/lib/brandable_css.rb and verify it fails and gives you
instructions on how to address the problem
- apply the instructions and verify it's ok now
reset your changes and let's test for image/static asset changes now:
- change an image like public/images/canvas_logomark_only@2x.png
- run "yarn gulp rev"
- run the test and verify it fails again
Change-Id: I957145f4cebe4e0a3d9c733206bb91ad4dbc3555
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/282579
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
closes INTEROP-7063
flag=none
We're adding a column to context external tools
so that we can dedupe off of it. For that, we
need a way to verify that two (potentially
deeply nested with arrays and hashes) are
the same
Test plan
- Run the database migration and make sure
the column shows up
- On a tool, calculate the identity_hash
- Save it to the new column and make sure
it saves correctly
- Try some tools that should be identical
and make sure that their hashes are
identical
- Try some tools with minute differences
in the identity fields and make sure
we are seeing differences in the hash
Change-Id: Ie6d15320aa7c6ccb04f760f8dd15ea513f954404
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/282071
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Mysti Lilla <mysti@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Mark Starkman <mark.starkman@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
Migration-Review: Jeremy Stanley <jeremy@instructure.com>
Tucker McKnight
