-
Notifications
You must be signed in to change notification settings - Fork 6
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 user_id as a hidden field populated from search params #2660
Conversation
src/app/pages/contact/form.js
Outdated
|
||
return ( | ||
<SalesforceForm postTo={postTo} afterSubmit={afterSubmit}> | ||
<input type="hidden" name="external" value="1" /> | ||
<input type="hidden" name="product" value={product} /> | ||
<input type="hidden" name="user_id" value={searchParams.get('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.
can we populate this for osweb submissions as well? from api/user
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.
So have the form pull it if it's not supplied as a parameter?
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.
the cookie user is loaded already right? or no? i think we put the cookied user id in here if no user id is passed in the url
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 user cookie is maintained in accounts, not directly visible to osweb.
osweb uses the accounts API to populate a context for user info. That's what I've got it using.
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 you're understanding what i'm saying and i'm just saying it in a confusing way.
the cookied user is potentially different from the active user in assignable, because assignable uses a session managed by token passing based on the lti launch. so assignable will pass a user uuid to this form and it might be different from the "authenticated user" as far as osweb is concerned, and that is fine. we should use the passed id as a priority and fall back on the user in osweb's standard authentication as a fallback
df26d0c
to
5a8c01a
Compare
DISCO-318