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
Update user_progress and user_app_options to support teacher view for cached levels #43422
Conversation
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.
Looks good! Just a couple small comments
509c2cb
to
bdc4b21
Compare
`/api/example_solutions/${serverScriptLevelId}/${serverLevelId}?section_id=` | ||
) | ||
.returns(exampleSolutionsResponse); | ||
ajaxStub.onCall(0).returns(userAppOptionsResponse); |
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.
Path-specific stubbing wasn't working because different tests use different query parameters. This is a temporary fix so that we can get this merged and unblock the next set of work. If it's ok with you, I'd like to merge this and then clean-up these tests in a follow-up PR.
bdc4b21
to
908fced
Compare
b8a7977
to
368e4f3
Compare
368e4f3
to
7aa8d4d
Compare
@@ -131,16 +131,6 @@ def milestone | |||
user_level: @user_level | |||
) | |||
|
|||
if solved |
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.
Just curious what this was for?
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 was for the "activity monitor". See this slack thread for more info on why it's no longer needed.
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.
LGTM! Just a couple of questions
@@ -425,8 +425,14 @@ def script_standards | |||
# Return a JSON summary of the user's progress for params[:script]. | |||
def user_progress | |||
if current_user | |||
if params[:user_id].present? | |||
user = User.find(params[:user_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.
Should we guard against ActiveRecord::RecordNotFound
here? Or replace with find_by
or some other method which will return nil if record couldn't be found?
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.
Good question. It's intentional that we throw an exception here so we don't continue execution here (same as the previous behavior). As written, if the request has an invalid user_id, the whole request will fail with a 404 error. I'm not sure if this is the best error to return and we also don't really handle this error on the client but this behavior is pre-existing and I'm inclined to solve that problem another day?
# and note if the signed-in user is viewing another user (e.g. a teacher | ||
# viewing a student's work). | ||
if params[:user_id].present? | ||
user = User.find(params[:user_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.
Same question here about checking for ActiveRecord::RecordNotFound
# TODO: There are many other user-specific values in app_options that may | ||
# need to be sent down. See LP-2086 for a list of potential values. | ||
|
||
response[:disableSocialShare] = !!user.under_13? |
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'm curious why the !!
is needed, under_13?
seems to imply it returns a boolean from the ?
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.
Oh, good catch. I wonder why I did that. :-)
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'll pick up this change in my next PR.
|
||
user = create :user | ||
sign_out user | ||
test "user_app_options should normally return reduceChannelUpdates false" do |
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.
Nit: "normally" could be clarified (not in emergency mode?)
This change updates ApiController#user_app_options to take a user_id, verify that the signed-in user is allowed to see the requested user progress, and returns the requested user's data. The diff doesn't do a great job of capturing the actual changes. Most of the logic in user_app_options is pre-existing with the following changes:
progress
andisHoc
fields in the response (since they weren't being used on the client).isStarted
,skipInstructionsPopup
,readonlyWorkspace
, andcallouts
Some additional small changes:
activity_start
andactivity_finish
which are no longer needed (slack).With these changes, teacher view works for cached levels if you comment out the line that returns the "Student code cannot be viewed for this activity."
Links
Testing story
Deployment strategy
Follow-up work
Privacy
Security
Caching
PR Checklist: