Remove most remaining uses of users collection #6056
Conversation
"users" is the domain of the identity service only and should not be altered by the API Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
"users" is the domain of the identity service only and should not be altered by the API Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
to afterAccountUpdate Signed-off-by: Eric Dobbertin <[email protected]>
that is no longer needed Signed-off-by: Eric Dobbertin <[email protected]>
Will reimplement in the near future Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
for email mutations Signed-off-by: Eric Dobbertin <[email protected]>
kieckhafer
left a comment
There was a problem hiding this comment.
I'm seeing an odd error message when using the addAccountEmailRecord and removeAccountEmailRecord email mutations.
When I addAccountEmailRecord, the email gets added to my account, however I get an error message that says "No unverified email found".
The same thing happens when I removeAccountEmailRecord, the email is removed, but I get the same error message.
When checking in the collection, verified = false, so this error message doesn't seem to make sense to be thrown here.
In addition, when I add an email, the new email gets a provides: default added onto the object... in fact every new email I add has provides:default attached to it, so If I add 10 emails, I have 10 emails that all provides: default
I'd expect only one email address to have provides: default attached to it, and I would also expect that to be the email I signed up with, not the newly added one, unless I explicitly changed my default.
There is confusion here about verifying for users vs. account. Will add proper account email verification in the future. Signed-off-by: Eric Dobbertin <[email protected]>
|
@kieckhafer Regarding How would you propose that we handle it? Do you think we should just add them without any What about the case where there isn't already a default one and I call Maybe we should prevent removal of the default in the first place? You have to make another one default before removing that one? I fixed the "No unverified email found" error by just removing the email validation calls. Those were looking at "users" whereas this is doing "accounts". We can add a validation flow for account emails in a separate PR later. |
|
@aldeed I think you've mentioned a combo of what's probably the best flow here.
I created a PR (into your I think this PR will be good to go once #6062 is merged into it, so if you want to take a look at my work there, merge it in here if it looks good, then this one should be mergeable. |
Signed-off-by: Erik Kieckhafer <[email protected]>
Signed-off-by: Erik Kieckhafer <[email protected]>
Signed-off-by: Erik Kieckhafer <[email protected]>
Signed-off-by: Erik Kieckhafer <[email protected]>
Signed-off-by: Erik Kieckhafer <[email protected]>
|
Approved, pending getting the changes from #6062 merged into this branch. |
…ovidesDefaultForEmail refactor: only allow provides: default for one email address
Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
Impact: minor
Type: feature
Issue
The "users" collection is the domain of the identity service, which is no longer part of the API in 3.0. But it is still being used in several places in API code.
Solution
I've removed most uses of the "users" collection where possible. For a couple mutations in which the identity service currently calls the API, I've moved the users-specific things to live in the "authentication" plugin, which is also specific to the default identity service.
Big picture, this allows you to swap out the Reaction Identity service for some other compatible identity service by creating your own custom plugin to replace the default "authentication" plugin. (In theory. We haven't yet tested any in particular.)
Breaking changes
Because we have no other solution ready, we've removed the sending of emails to "admins" when a new order comes in. Issue #6055 is tracking re-implementation of this in a better way.
addAccountEmailRecordandremoveAccountEmailRecordstill modify the Account emails list but no longer modify the User emails list. Changing User email list can be implemented on Reaction Identity if needed.Testing
Verify that the affected mutations/flows work.
addAccountEmailRecordandremoveAccountEmailRecordGQL mutations still modify the Account emails list properly.