#7436 /auth/preferences cleanup
- Add a section at the top of readonly information, show:
- Username: {{username}}
<a href="{{user.private_project().url()}}">My profile and my projects</a><a href="{{user.private_project().url()}}admin/overview">Set avatar icon</a>
password_change_formandupload_key_formshouldn't be tied to the theme. Move the forms to a better place (auth something..)- Make every part of the page (
password_change_formandupload_key_form, Display Name, Page Size, Email, User Messages, etc in a unique jinja block. Instead of "if" statements that checkauth.methodor the theme, every section on the page should be contained in a block so that a simple template override can be set up foruser_prefs.htmland any individual block can be made to be empty (or something else) - Improve the layout between each section as best you can. And within the email block especially. It seems like everything is just run together. It is extra confusing that there a multiple separate forms with their own save buttons. I think dedicated forms for pwd change and ssh keys makes sense, but it is confusing to have so many forms on the page. I am open to suggestions for the multiple forms issue. Best idea I have so far is to have a
<hr>between each form, to visually show the separations. (Ideally would have it all auto-save ajax or all one single form, but those would be big projects).
Hm, after looking at the controllers... seeing that auth.py
def updatehas an "if" statement based onauth.methodto match the "if" stmt in the template, I think the jinja blocks won't be sufficient. Controllers need to disable features not just the HTML form (so that a sneaky user can't simulate a form submit).Setting up blocks to allow for overriding still is nice, but I'm now thinking that we should have config options similar to the existing
auth.allow_user_to_disable_accountfor each of the sections and "if" statements in each jinja block and in the relevant controller methods.For now I'm heading for something like this to visually separate forms.
"Email" part needs to be adjusted yet, especially extremely counterintuitive "Claim Address" & "Save Changes" behavior (I think, one button should handle both cases, but still don't sure exactly how). Or maybe separate "email" and "general settings" (display name, page size, etc) into two forms? But it would require controller refactoring and I don't sure if you up to such changes or want only cosmetic changes like above for now.
I like it. I haven't used a fieldset in a long time, but they're good! I think leaving general settings and email together is acceptable. But as you work through the buttons within the Email section, if it really warrants separating email out from the other settings, then feel free to do that.
Closed #599.
je/42cc_7436I've left functionality for emails section as is, but changed layout a bit, I think now it's more clear.
Notes:
New option:
auth.allow_edit_prefsupload_key_formdoesn't work and didn't worked before, since corresponding auth provider methods are not implemented for local provider. Don't sure why it was shown in a first place. Maybe it's better to hide it, then?password_change_formchanges password even if you enter invalid old password. It was fixed in [#7432].I've rebased [#7432] to this branch and updated code a bit, since it uses password change form, which was moved.
Related
Tickets:
#7432auth.allow_edit_prefsshould default to True in the code.{% if c.password_change_form %}then too, I think its unnecessary). Default the ssh key form to False and the rest to True.Closed #601. Updated
je/42cc_7436