-
-
Notifications
You must be signed in to change notification settings - Fork 546
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 profile and change password form tags #6400
Conversation
Great work on this Jack |
Hi @jacksleight! Thanks for your work! Any ideas, what's missing or why it is still not merged? |
Think they just haven’t got to it yet, sure it'll be reviewed in due course. It's a fairly big PR so might take some time. |
This is really great, thank you. But the asset fields are complicated. As it stands, if you have an avatar, and you submit the form, the avatar field gets wiped. So while you said:
It is possible... It just does it when you probably don't want it to. For now, so this can get merged and used, I'm going to filter out asset fields. We can figure out asset field handling in a separate PR. |
I could be wrong (can't test it right now) but I think that's accounted for by these two bits: request()->hasFile($field->handle()) ->only(array_keys($values)) These should prevent blank files overwriting the existing values by filtering out the item from the collection if nothing has been uploaded. Will do some testing to check though, I'm fairly sure that works OK in the addon (where most of this comes from). |
It wiped it when trying here. That hasFile only happens in the uploadAssetFiles, but not normalizeAssetValues, so the null value still gets submitted. There's also the issue of how to display the file when one already exists, how to let a user remove it, and what to do when you have other assets fields that may have max_files != 1. |
|
Ah OK, must not have spotted that before, no worries. 👍 And yeah there are other issues to consider as well. |
…nt, don't allow it to be updated by the form.
Continuing with what @edalzell started in #6023, merging in what I've implemented in my addon.
This PR adds the following:
{{ user:profile_form }}
tag that allows users to edit their information{{ user:password_form }}
tag that allows users to change their passwordCouple of notes:
I'm sure the way I've passed the default values from the user data to the profile form (including the change to
getRenderableField
) probably isn't the best way to do that, but I wasn't really sure how else to do it.At the moment it's not possible for a user to remove assets from their accounts through the profile form, only replace them. I'm not sure if that should be supported and if so how best to do it?
In my addon I implemented the profile form with a list of fields that were allowed to be submitted, defined via a config option. I've not implemented that here as the registration form doesn't have that. But perhaps it would be a good idea, to stop people submitting values they shouldn't have the ability to change? Maybe a block list instead of an allow list?
Also the tests have to check for either
validation.current_password
orThe password is incorrect.
because there's novalidation.current_password
string when running prefer-lowest.Closes statamic/ideas#676.