-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Support User: Add SupportUser component. #1202
Conversation
dd9d8ac
to
6513d45
Compare
supportToken = ''; | ||
}, | ||
req: { | ||
del: function( ...args ) { |
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.
After a bit of digging, I came to learn that functions in JavaScript can only ever be bound a single time. Every bind/call/apply after that won't change this
. I've setup a test demonstrating this behavior and also found it in MDN's documentation on bind, stating that the this
"cannot be overridden".
I'm not sure of why this was chosen to be the case, but it jumps out to me here where we double-bind. If the behavior is incorrect with a different iteration of the code, we probably have something strange going on and should fix it otherwise we might discover some crazy bugs.
Probably we could rewrite this with a simple call:
req: {
del: ( ...args ) => del( ...( extendRequest( 'del', request ) ) ),
}
Or with null
as the this
to make it clearer than using wpcom
req: {
del: ( ...args ) => del.apply( null, extendRequest( 'del', args ) )
}
These should be identical and I'd be very interested to find out.
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 now uses the spread operator on extendRequest
, which clarifies that post
et al. are bound once to a const
and then called, without needing to apply
them.
67a392f
to
bc0b48b
Compare
9257141
to
34d0e22
Compare
I've just added some changes to give the support user feedback in two cases:
When one of these errors occurs, they're displayed on the entry screen along with the error message. Currently the message is displayed as the class |
071123e
to
61b254e
Compare
61b254e
to
ece3fdb
Compare
93bde26
to
c6178f3
Compare
This change intercepts errors that occur when a support token becomes invalid. When this happens, the support user entry dialog is displayed along with the error message. This also now provides the user feedback when the password is entered incorrectly.
Stores a copy of the user data when a change is anticipated; uses this to display the original user’s data on the “Restore User” modal.
This change disables the 'Change user' button while the switching is in progress. Part of this change includes waiting until the token has been successfully received and the user information has been updated before altering the UI (including Masterbar color) to show that support user is active.
This change reloads the user settings when activating and deactivating support user mode. This should prevent some issues with sticky data on the user profile page.
c6178f3
to
833773d
Compare
This PR adds a component for providing support across REST API queries.
An access token is granted when a support user and password are provided; the token can be revoked during a restore operation, or will expire after a set period of time. Once granted, the support username and token are passed along all queries to the API.
Edit (@jordwest): This PR is being divided into smaller PRs for easier review:
Support User: Add Support User libraries #2368Support User: Add Support User libraries (fix) #2510: support.js and librariesSupport User: Add Redux integration #2512Support User: Add (pure) Redux integration (alternate implementation) #2819: Redux actions, action types, and reducer