-
Notifications
You must be signed in to change notification settings - Fork 138
fix: UserModel::save() can't update User's email/password #275
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
Conversation
8cde372
to
19b44c2
Compare
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.
If this works then let's go with it but I still have plans to add the original method parameters to the event data in the framework, which would make this much easier.
Sorry, I didn't mean to hit "approve" - I'm good with the approach but obviously will need to pass tests 😂 |
@MGatner this PR is in position |
I removed the approval. |
The enhancement is good, but we need to wait for v4.3. So I think this PR is needed. |
Okay, I think this is ready for reviews. |
I think
|
@kenjis I agree. I think the ultimate solution is to modify |
c811ad5
to
057b221
Compare
Yes. I added a commit: 39aaf14 |
057b221
to
39aaf14
Compare
4581609
to
76b15a5
Compare
src/Models/UserModel.php
Outdated
*/ | ||
public function save($data): bool | ||
public function saveWithEmailIdentity(User $data): void |
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.
Did we need to rename this for a specific reason? If so, or the team majority says we should then ok, but I'm in favor of keeping it as an override of Model::save
.
I understand this is a more specific naming, but the whole purpose of the override was to make it as seamless as possible for the developer so they didn't have to think too much about it. This forces them to remember a new method for that single model, which is inconvenient and, as far as I can tell, unnecessary.
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.
Reading back through I see the discussion between you two so I'm overruled here. Just going on the record to say I disagree :)
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.
👹 Contention noted!
I think this does two good things for us:
- It lets us still use
save()
without messing with identities. - It allows us to force the
User
type parameter which makes this method much easier to handle.
Also just to say it again: this should just be a temporary measure until we get better Model event parameters in place.
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 overrode save()
again.
After all, if save() is going to be used in the future, it is better for users to use save() now.
It is confusing only save() can save Email Identity, but users do not need to use insert() or update().
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.
Alternative idea...
The whole reason we override this method is that afterInsert
and afterUpdate
receive the data as an array, not the original User
entity, and that array is filtered by $allowedFields
so the credentials are stripped. What if we override insert()
and update()
to store credentials in a new private property before calling parent::method()
and then still use the after____
methods to handle the identities, just using the stored versions instead?
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.
Added UserModel::saveEmailIdentity()
and the Model Events call it when afterInsert and afterUpdate.
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.
LGTM!
I try de update the password to existent user and it not working, when the user try to login with new password he get this error message: "Please check your password." |
hi @manukieli, |
4d4ce9d
to
ed7ff5e
Compare
I rewrote UserModel::save() (and update(), insert()) with the Model Events. |
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.
Thanks for taking a pass at this @kenjis! It didn't end up being quite as clean as I hoped but I still think it is a big improvement. I wish we had the allowEmpty()
method, but what can you do 🤷♂️
One of the strengths to this approach is that we can support "normal" model operations instead of relying on special use cases with save()
. To that end I think that we should still support array parameters, and just have the callback events skip identity updates whenever there is no $tempUser
. I'm happy to hear an alternate opinion but I think that improves the transparency of these methods, which I believe was @lonnieezell's original intent.
src/Models/UserModel.php
Outdated
* Override the BaseModel's `save()` method to allow | ||
* updating of user email, password, or password_hash | ||
* fields if they've been modified. | ||
* @param User $data |
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 we should still support arrays, and the callback events would just ignore them.
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.
Frankly, I am not sure why it is necessary to accept arrays, but I implemented it that way to try it out.
bc7b647
to
d9410fe
Compare
src/Models/UserModel.php
Outdated
$user->saveEmailIdentity(); | ||
|
||
return $data; | ||
} | ||
|
||
// Update | ||
$this->tempUser->saveEmailIdentity(); | ||
|
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 know $tempUser
is reset on each call but I would feel better if it were also reset after the identity update, unless there is some logical reason to keep it around.
$user->saveEmailIdentity(); | |
return $data; | |
} | |
// Update | |
$this->tempUser->saveEmailIdentity(); | |
$this->tempUser = $user; | |
} | |
// Update and reset | |
$this->tempUser->saveEmailIdentity(); | |
$this->tempUser = null; |
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.
Added $this->tempUser = null
.
Since we create a User object manually, we need to call it for consistency.
When updating User's email/password, parent::save($data) may return DataException (no data to update).
…vents Remove saveWithEmailIdentity().
…ents do not save Email Identity
d9410fe
to
1ecdbdd
Compare
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 one has been a long road! Thanks for all your work on it @kenjis. I believe it's ready!
@MGatner Thank you for the review! |
Fixes #254
Fixes #253
UserModel::save()
,update()
andinsert()
save Email Identity with Model EventsUserModel::findByCredentials()
RegisterController::registerAction()
User::saveEmailIdentity()
ValidationException