Port User Profile pages to zamboni with new designs

RESOLVED FIXED in 5.10

Status

addons.mozilla.org Graveyard
Public Pages
P5
normal
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: fligtar, Assigned: clouserw)

Tracking

Dependency tree / graph

Details

(Whiteboard: [z][qa-])

Attachments

(2 attachments)

(Assignee)

Updated

8 years ago
Summary: Port Edit Profile to zamboni with new designs → Port Edit Developer Profile to zamboni with new designs
(Assignee)

Comment 1

8 years ago
This is talking about the edit user page and needs clearleft designs.
Summary: Port Edit Developer Profile to zamboni with new designs → Port Edit User Profile to zamboni with new designs
(Reporter)

Comment 2

8 years ago
Note that this is not the Developer Profile, but the profile for normal users.
Target Milestone: 5.7 → 5.8

Updated

8 years ago
Blocks: 544281
(Reporter)

Comment 3

8 years ago
Created attachment 425849 [details]
E-mail & Settings mock, v1

First round of designs are in. Some comments:

* I told them tabs were okay, but to at least reduce the number, which they did
* I told them not to mess with the translation box, and they didn't
* I'm pretty happy with these designs, so let me know if anyone has feedback
(Reporter)

Comment 4

8 years ago
Created attachment 425850 [details]
User Profile mock, v1
(Reporter)

Updated

8 years ago
Whiteboard: [z] → [z][clearleft]
(Assignee)

Comment 5

8 years ago
I think editors have a checkbox for every add-on review they are "watching."  That could make the first mockup uglier.  I'm not worried about it though.
(Assignee)

Comment 6

8 years ago
Front end for this bug is bug 546818
Blocks: 546818
(Assignee)

Comment 7

8 years ago
Start of this is at http://github.com/clouserw/zamboni/tree/users
Assignee: nobody → clouserw
(Assignee)

Comment 8

8 years ago
Current to do list for this bug:

* Required fields aren't marked.  We need to figure out a way to mark them until we can do the change in comment 4.
* Why does the users and auth_user tables have so much duplicate data?  How do we avoid that?
* Is there a standard way to print the "Some HTML allowed" code on the page?  If not, there should be since we'll use that all over.
* "Delete account" isn't hooked up.  That requires a second view with explanation and password confirmation.
* After updating the user, the PurifiedField "in a little more detail" is blank.  Refreshing fills it.  I have memcache disabled.
* Managing user images has to be hooked up.  This means accepting the upload, resizing/verifying the images, and saving to disk.
* Email change logic needs to be written.  If a user changes their email address you have to email the new address with a confirmation URL and a key.  We need a new view to accept that key and confirm/deny their change.
* After we click submit, it would be nice if we were on the same tab we left.

This involves not only a lot of new code, but new libraries (image, email) that aren't incorporated yet.  I'm worried about getting this finished by code freeze but I'll get as much done as I can.  Basic user editing (regular fields) is working fine.
(Assignee)

Comment 9

8 years ago
Also, to write tests for this stuff, login() would have to be done
FWIW, Django comes with "lost your password?" and "change your email" logic, AFAIK. Might be able to use that relatively easily.
(In reply to comment #8)
> Current to do list for this bug:
> 
> * Required fields aren't marked.  We need to figure out a way to mark them
> until we can do the change in comment 4.

Do the Django fields output some kind of class=required?  Is this just a CSS issue?

> * Why does the users and auth_user tables have so much duplicate data?  How do
> we avoid that?

I think the only thing that needs to be synced are the auth_user and user ids.  Then we have to fill out whatever fields the Django auth.User requires.  It's not a big deal to keep them in sync, because auth.User fields will only show up in the admin.

We want to use auth.User so that admin and sessions work out of the box.  davedash can speak more on this.

> * Is there a standard way to print the "Some HTML allowed" code on the page? 
> If not, there should be since we'll use that all over.

Make a helper function.  Or if it's just a chunk of HTML, you can directly {% include "some_html_allowed.html" %}

> * After updating the user, the PurifiedField "in a little more detail" is
> blank.  Refreshing fills it.  I have memcache disabled.

Are you doing POST-redirect-GET?

> * After we click submit, it would be nice if we were on the same tab we left.

It's probably possible to do this by extracting some of the code that drives the homepage tabs.  Can we figure out what tab they were on from the referrer?  You might not even need the homepage code if you can get the fragment from there.
(In reply to comment #9)
> Also, to write tests for this stuff, login() would have to be done

We don't need a login() view to test logged-in functionality.  We already have tests that do logins.
(Assignee)

Comment 13

8 years ago
I committed password reset functionality tonight.

> > * Required fields aren't marked.  We need to figure out a way to mark them
> > until we can do the change in comment 4.
> 
> Do the Django fields output some kind of class=required?  Is this just a CSS
> issue?

No, just design.  Since we're splitting "username" from "real name" (via tab-panels) the messaging is harder.  Not a big deal.  To be honest, my comment was half notes to myself. :)

> > * Why does the users and auth_user tables have so much duplicate data?  How do
> > we avoid that?
> 
> I think the only thing that needs to be synced are the auth_user and user ids. 
> Then we have to fill out whatever fields the Django auth.User requires.  It's
> not a big deal to keep them in sync, because auth.User fields will only show up
> in the admin.
I was worried about this because of saving user objects.  As long as we stick with saving user objects off the get_profile() we'll be fine but we should fix it in the future.

> 
> > * After updating the user, the PurifiedField "in a little more detail" is
> > blank.  Refreshing fills it.  I have memcache disabled.
> Are you doing POST-redirect-GET?
I don't think so, but I'll look tomorrow.

> 
> > * After we click submit, it would be nice if we were on the same tab we left.
> 
> It's probably possible to do this by extracting some of the code that drives
> the homepage tabs.  Can we figure out what tab they were on from the referrer? 
> You might not even need the homepage code if you can get the fragment from
> there.
I didn't think fragments were ever sent to the server.
(Assignee)

Updated

8 years ago
Priority: P2 → P3
Whiteboard: [z][clearleft] → [z]
Target Milestone: 5.8 → 5.9
(Assignee)

Updated

8 years ago
Priority: P3 → P5

Updated

8 years ago
Blocks: 555859
(Assignee)

Comment 14

8 years ago
This is getting r?'d, but isn't a high enough priority to land by tomorrow.
Target Milestone: 5.9 → 5.10
(Assignee)

Comment 15

8 years ago
Alright, I scope creeped this pretty badly, so I'm going to resolve it as fixed and add [qa-].  The commit is 7a0a873497b01e44e180c3153e3e4e44e05c5650.  I wrote log in, log out, delete, most of edit, the email change interactions, registration, registration confirmation resend, and all the password reset/confirmation/etc. code.

I don't consider this a public page which makes it not a priority.  Therefore, I'm filing some bugs for the remaining things: Bug 558506, bug 558507, bug 558508, bug 558509, bug 558510, and bug 558511.

Once we're ready to push /users/ URLs live, we'll file a general "Have your way with /users/" bug for QA.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Summary: Port Edit User Profile to zamboni with new designs → Port User Profile pages to zamboni with new designs
Whiteboard: [z] → [z][qa-]
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.