Ticket #9311 (closed PLIP: wontfix)

Opened 7 years ago

Last modified 6 years ago

Clean up of user related actions UI

Reported by: dokter Owned by: dokter
Priority: minor Milestone: 4.0
Component: Unknown Version:
Keywords: Cc: plip-advisories@…, grahamperrin@…

Description (last modified by dokter) (diff)

Proposer: Duco Dokter
Seconder: Alexander Limi, David Convent

Motivation

The user admin related actions, from the perspective of the user itself, are scattered over the user interface. The following actions are available:

  • access to the dashboard,
  • user data
  • preferences
  • personal preferences
  • profile (author info)
  • user folder
  • change password

The several configuration sets are not uniform: name and email address are part of preferences for example, but are clearly user data, as opposed to wysiwyg editor setting or skin preference. Also, the personal bar is really in the way of the overall design.

Assumptions

It is hard for users to determine exactely what access to use to get to a specific setting.

Proposal & Implementation

User related actions are moveed to new package plone.app.users.

What should be available to the user is:

  • public profile, based on tiles. The user can determine what to show to the public, for instance a 'recently added' tile, or an overview of specific user data.
  • preferences, where a user can set favorite editor, skin, etc.
  • user data, where a user can administer personal data, like email address, surname, etc.
  • dashboard
  • change password
  • user folder

In the UI, there should only be a maximum of three accessors:

  1. a clickable login name, that takes the user to his/her dashboard
  2. Account, that takes the user to user the, config panel. This panel provides three tabs: user data, preferences and change password.
  3. My stuff, in case a user has a personal folder.

Also, the user can set his/her start page for the site in the preferences. This should be the page the user is directed to after login. Default is the plone start page. Other options are dashboard, my stuff, etc.

The personal bar will be moved to the top of the page, to remove it from overall design, and give it a clear place.

The user data and preferences will be implemented using the same back-end as in the current situation, only the way to navigate there will be changed, and the forms will be implemented using zope.forms, located in tabs in an overall user admin screen.

Deliverables

Personal bar moved to top, user data and preferences clearly separated, less entry points for user functionality, unit tests for all forms.

Other than that, localization and unit tests are largely in place, but need to be adapted to the new situation and moved to plone.app.users. Documentation will be altered and moved whereever necessary.

Risks

The new design is a deviation from the current situation; migration to Plone 4 will require adaptation of users to the new way of accessing functionality.

Participants

Wietze Helmantel, helmantel Kim Chee Leong, kcleong David Convent, davconvent

Progress

Some of the work has been done at the Baarn 2009 sprint

Change History

comment:1 Changed 7 years ago by alecm

+1

These are good ideas; a sane reorganization of account configuration is important. However, if this is going to be acceptable for 4.0 it needs an implementation that doesn't involve tiles. I imagine this will be intimately tied to the user properties customization portion of #9310 and perhaps can't really be implemented until that is complete. Does it make sense to combine these?

comment:2 Changed 7 years ago by erikrose

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:3 Changed 7 years ago by optilude

If we do this, it may be worth looking at plone.app.memberschema.

This has two features:

1) A PAS properties plugin that exposes properties based on a list of schema interfaces.

Those interfaces can be listed on the plugin config (so we'd have some default ones, but people could then add their own). Depending on the PAS config, this can be a replacement for the standard properties plugin, or just a supplement. It also interleaves properly with LDAP and other properties plugins, of course.

The advantage of this approach is that it's easier to create property schemata (on the filesystem, although it wouldn't be too hard in the future to adopt plone.schemaeditor for this purpose) and make them available to users. Things like required fields, default values, validators etc can be represented more easily.

2) The ability to generate forms based on these schemata

This uses plone.autoform and z3c.form. I'm not sure if that's something we want to adopt in the core yet. But if we do, it's a lot easier to make a 'preferences' form (and 'join' and 'create member' forms) built from these schemata. Integrators could quite easily install their own schemata (there's a GS syntax for this, so you write an interface + a GS XML file) and they should "just work".

plone.app.memberschema is in use in production in at least one site. I know there are some issues with the example schemata, because they try to mimic portal_memberdata and it has very strange ideas about how to store things. We'd need to look at that, and provide some kind of migration. We'd also need to hook up the forms, since p.a.m doesn't replace the default forms out of the box. But both of those things should be pretty easy.

Martin

comment:4 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:5 Changed 7 years ago by MatthewWilkes

This seems a generally good thing, but the profile customisation feels a bit too far for me. Tiles especially, are right out.

FWT Vote: -0

comment:6 Changed 7 years ago by rossp

FWT vote +1, so long as this either leaves the profile implementation as is.

comment:7 Changed 7 years ago by davisagli

FWT vote: +1. I feel better about the minor cleanup tasks here than I do about rewriting the preference forms, but I'm willing to let you have a crack at it. In particular, I think rewriting the preference forms to be based on a form library instead of CMFFormController is a step backward from the perspective of integrators, unless there's also a reasonably easy way to wire in a schema with additional member properties, as in optilude's plone.app.memberschema (see also related discussion of that in #9310)

comment:8 Changed 7 years ago by raphael

FWT vote: +1 if you can get away without tiles

comment:9 Changed 7 years ago by calvinhp

FWT Vote: -0 I'd be more in favor of this if it didn't include the profile bit based on tiles and I'm also not in favor of the start page preference to keep things simple.

comment:10 Changed 7 years ago by esteele

Approved by FWT vote.

comment:11 Changed 7 years ago by esteele

  • Owner set to dokter

comment:12 Changed 7 years ago by dokter

  • Status changed from new to assigned

comment:13 Changed 7 years ago by dokter

  • Description modified (diff)

comment:14 Changed 7 years ago by grahamperrin

  • Cc grahamperrin@… added

comment:15 Changed 7 years ago by dokter

Ready for review.

comment:16 Changed 7 years ago by robgietema

Added review in [29333].

comment:17 Changed 7 years ago by cjohansen

Tested with FAE ( http://fae.cita.uiuc.edu/). Accessibility of Add Portlets control poor. The problem is the use of the onChange JavaScript event trigger in the <select /> element:

<select name=":action" onchange="this.form.submit()">

To make applications accessible, they must be navigable by keyboard alone. Using the keyboard to navigate this select element fires the onChange trigger when using the arrow keys. I effect, the user can never get past the first choice in an option list. A fix is to remove the onChange event trigger and add a button to execute the selected option.

comment:18 Changed 7 years ago by esteele

Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.

comment:20 Changed 6 years ago by rossp

Seems incomplete as is.

FWT vote: -1 for merging

comment:21 Changed 6 years ago by esteele

  • Status changed from assigned to closed
  • Resolution set to wontfix

This PLIP has been rejected for merging into Plone 4.0

The final vote was: Alec Mitchell 0 David Glick 0 Erik Rose -1 Laurence Rowe - Matthew Wilkes - Ross Patterson -1

The Framework Team felt that the product was not finished enough to be merged at this time. I'd encourage you to resubmit this PLIP for a 4.x branch if you feel it appropriate. Thank you for your hard work.

Note: See TracTickets for help on using tickets.