Storing userData in place of userId in progresses to minimize additional API calls from the frontend. #2309
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Date: 20 Dec 2024
Developer Name: Anuj Chhikara
Issue Ticket Number
#2294
Description
In this PR, we have updated the logic for storing user-related information when a progress is created. Previously, only the
userId
was stored, but now we are storing the completeuserData
object. This change ensures that more comprehensive user details are available directly within the progress data, reducing the need for additional API calls to fetch user information from the frontend.Documentation Updated?
Under Feature Flag
Database Changes
Breaking Changes
Development Tested?
Screenshots
Screenshot 1
Post Request working fine
userData field getting add in place of userId
Test Coverage
Screenshot 1
Additional Notes
The addUser function in the utils previously only returned userId. To support storing userData in progresses, I added a second argument (defaulted to false). When set to true, the function now returns userData, which we use in tests to store the full user data in the progress documents.