-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add daily syncing of LTI rosters #7178
add daily syncing of LTI rosters #7178
Conversation
Pull Request Test Coverage Report for Build 10924676601Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pretendWhale nice work! I left a few inline comments. It would also be good to add some test cases, e.g. checking that the controller correctly schedules (or removes) the job depending on the automatic_sync
option.
job_args[:role_types] = roles | ||
job_args[:can_create_users] = allowed_to?(:lti_manage?, with: UserPolicy) | ||
job_args[:can_create_roles] = allowed_to?(:manage?, with: RolePolicy) | ||
name = "#{@current_course.name}_#{root_path.tr!('/', '')}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is just a unique identifier for the job? If so, I think using the deployment id (in addition to root_path
) is safer, since I believe we allow courses to have multiple deployments.
Also adding the name of the class LtiRosterSyncJob
would be good in case we want to do more scheduling in the future.
can_create_users: allowed_to?(:lti_manage?, with: UserPolicy), | ||
can_create_roles: allowed_to?(:manage?, with: RolePolicy)) | ||
job_args = {} | ||
job_args[:deployment] = deployment.id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Name this deployment_id
(consistent with other, similar params)
config[:args] = { job_class: 'LtiRosterSyncJob', arguments: [job_args] } | ||
config[:cron] = Settings.lti.sync_schedule | ||
config[:persist] = true | ||
config[:queue] = 'DEFAULT_QUEUE' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem like it should be hard-coded. Can we use the LtiRosterSyncJob.queue_name
method?
app/jobs/lti_roster_sync_job.rb
Outdated
def perform(args) | ||
args = args.deep_symbolize_keys | ||
lti_deployment = LtiDeployment.find(args[:deployment]) | ||
course = lti_deployment.course |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like defining a course
variable is redundant here; can you modify roster_sync
so that it doesn't take in a course
argument?
config/initializers/config.rb
Outdated
@@ -193,6 +193,7 @@ | |||
required(:domains).array(:str?) | |||
required(:token_endpoint).filled(:string) | |||
optional(:unpermitted_new_course_message).filled(:string) | |||
optional(:sync_schedule).filled(:string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be required, otherwise the automatic sync functionality will fail.
config/locales/common/en.yml
Outdated
@@ -48,6 +48,7 @@ en: | |||
select_course: Select the course that matches %{course_name} | |||
start_grade_sync: Syncing Grades | |||
start_roster_sync: Syncing Roster | |||
sync_automatically: Sync Automatically |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reword to "Enable automatic syncing"
Changelog.md
Outdated
@@ -42,6 +42,7 @@ | |||
- Calculate and display the exact future time for the next token generation to help students plan their test runs more effectively. (#7127) | |||
- Set the default date for "Tokens available on" to the current time (#7173). | |||
- Add setting to enable filtering of new course creation from LTI launch (#7151) | |||
- Add daily roster syncing via LTI (#7178) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entry is in the wrong section
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are absolutely correct - thanks for the catch!
Failing test seems to be a flaky test unrelated to the changes in this PR ( |
@pretendWhale while this might be a flaky test, I've now re-run the tests twice and they failed both additional times. This is suspicious. Can you please confirm that this test is passing for you locally on this branch? |
@david-yz-liu that is strange. I can confirm that this test (and all tests in |
Proposed Changes
(Describe your changes here. Also describe the motivation for your changes: what problem do they solve, or how do they improve the application or codebase? If this pull request fixes an open issue, use a keyword to link this pull request to the issue.)
Adds an option to automatically sync student rosters from an external LMS once daily. Note: I did not add tests here, because it would involve ensuring that a schedule was set in redis, which our unit tests do not typically interact with to my knowledge.
Screenshots of your changes (if applicable)
Associated documentation repository pull request (if applicable)
https://github.com/MarkUsProject/Wiki/pull/216Type of Change
(Write an
X
or a brief description next to the type or types that best describe your changes.)Checklist
(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the
[ ]
into a[x]
in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)Before opening your pull request:
After opening your pull request:
Questions and Comments
(Include any questions or comments you have regarding your changes.)