canvas-lms/app/messages/appointment_group_published...

5 lines
194 B
Plaintext
Raw Normal View History

<% define_content :link do -%>
pop-up event in calendar for appointment group reserved slots. - also redirect student to find appointment mode if they do not have appointment. - add additional specs, remove parameter to specify find_appointment statically. - add specs for group appointments. Test Plan: Verify that the new appointment available notification correctly routes the user to the appropriate calendar view. When the user has reserved an appointment, the user should be directed to the agenda view on the day of their appointment. When the user does not have an appointment, find_appointment mode should be activated in the agenda view of the calendar. Links to the event in the syllabus should also correctly route the user to the correct find_appointment mode based on whether or not they have an appointment. Additionally the “Appointment Reserved by User” notification should be tested. Proposed change can be tested by creating an appointment group as a teacher, and creating an event with several slots for students. As a student, sign up for a slot. The teacher should receive a notification. As the teacher, follow the link in the notification, and verify that the appointment event opens as a pop-up in the calendar month view. Fixes PFS-6257, PFS-6318 Change-Id: Id906d77813bd2bf7fd3f4c3b9ca736accafe0cf2 Reviewed-on: https://gerrit.instructure.com/98922 Reviewed-by: Jeremy Stanley <jeremy@instructure.com> QA-Review: David Tan <dtan@instructure.com> Tested-by: Jenkins Product-Review: Chris Ward <cward@instructure.com>
2017-01-06 06:54:50 +08:00
<%= appointment_group_url(asset) %>
<% end -%>
use url helpers in messages fixes CNVS-11838 and then choose the host more intelligently to use one the user can actually log in to test plan - have accounts on two shards, referred to as "account 1" and "account 2" from now on - have account domains that are resolvable for the accounts, referred to as account1.canvas.dev and account2.canvas.dev from now on - have account 2 trust account 1 by POSTing to account2.canvas.dev/api/v1/accounts/<account 2 id>/trust_links with a site admin's auth token and setting trust_link[managing_account_id] to account 1's global id. you can now use users from account 1 on account 2 - regression test notifications, especially considering notifications generated by account 2 that are sent to account 1 users. - account 1 users should have links that use account1.canvas.dev and have global ids for referenced objects that live on account 2's shard, e.g. account1.canvas.dev/courses/2~1/discussion_topics/2~30 - avatars should use the avatar owner's account domain - account 2 users should have links that use account2.canvas.dev and have local ids, e.g. account2.canvas.dev/courses/1/discussion_topics/30 - following the links when the user receiving the notification is logged in should take the user to the linked object - following the links when not logged in should take the user to a login page that they are able to log in to - be sure to at least check: context file downloads links (e.g. discussion topic attachments) file downloads links (e.g. conversation message attachments) avatars links conversation notifications discussion notifications peer review notifications Change-Id: Idebd247fee99a2b973d3fa6f4f2fca0e723d99a5 Reviewed-on: https://gerrit.instructure.com/31867 Tested-by: Jenkins Reviewed-by: Matthew Wheeler <mwheeler@instructure.com> QA-Review: Steven Shepherd <sshepherd@instructure.com> Product-Review: Joel Hough <joel@instructure.com>
2014-03-14 01:44:09 +08:00
<%= t :message, 'Canvas Alert - Signups are open for "%{appointment_name}".', :appointment_name => asset.title %>