Skip to content
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

Merged
merged 2 commits into from Nov 10, 2021

Conversation

jamescodeorg
Copy link
Contributor

@jamescodeorg jamescodeorg commented Nov 5, 2021

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:

  • Moved the code to get progress-related app_options to a separate method.
  • Stopped sending progress and isHoc fields in the response (since they weren't being used on the client).
  • Started sending isStarted, skipInstructionsPopup, readonlyWorkspace, and callouts

Some additional small changes:

  • Pass through user_id in both the user_progress and user_app_options calls on the client.
  • Handle new values returned by user_app_options on the client.
  • Removed slogging for activity_start and activity_finish which are no longer needed (slack).
  • Update ApiController#user_progress to check that signed-in user can see requested user's progress.

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:

  • Tests provide adequate coverage
  • Privacy and Security impacts have been assessed
  • Code is well-commented
  • New features are translatable or updates will not break translations
  • Relevant documentation has been added or updated
  • User impact is well-understood and desirable
  • Pull Request is labeled appropriately
  • Follow-up work items (including potential tech debt) are tracked and linked

@jamescodeorg jamescodeorg requested a review from a team November 5, 2021 22:17
Copy link
Contributor

@maureensturgeon maureensturgeon left a 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

apps/src/code-studio/progress.js Show resolved Hide resolved
@jamescodeorg jamescodeorg force-pushed the jamescodeorg/cached-level-load-source branch 2 times, most recently from 509c2cb to bdc4b21 Compare November 9, 2021 15:47
apps/src/code-studio/progress.js Show resolved Hide resolved
`/api/example_solutions/${serverScriptLevelId}/${serverLevelId}?section_id=`
)
.returns(exampleSolutionsResponse);
ajaxStub.onCall(0).returns(userAppOptionsResponse);
Copy link
Contributor Author

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.

@jamescodeorg jamescodeorg force-pushed the jamescodeorg/cached-level-load-source branch from bdc4b21 to 908fced Compare November 9, 2021 18:22
@jamescodeorg jamescodeorg force-pushed the jamescodeorg/cached-level-load-source branch 2 times, most recently from b8a7977 to 368e4f3 Compare November 10, 2021 00:30
@jamescodeorg jamescodeorg force-pushed the jamescodeorg/cached-level-load-source branch from 368e4f3 to 7aa8d4d Compare November 10, 2021 01:04
@@ -131,16 +131,6 @@ def milestone
user_level: @user_level
)

if solved
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@maureensturgeon maureensturgeon left a 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])
Copy link
Contributor

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?

Copy link
Contributor Author

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])
Copy link
Contributor

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?
Copy link
Contributor

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 ?

Copy link
Contributor Author

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. :-)

Copy link
Contributor Author

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
Copy link
Contributor

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?)

@jamescodeorg jamescodeorg merged commit c8da451 into staging Nov 10, 2021
@jamescodeorg jamescodeorg deleted the jamescodeorg/cached-level-load-source branch November 10, 2021 20:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants