[PLIP-Advisories] Re: [Plone] #9310: User registration process more flexible
#9310: User registration process more flexible -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Description changed by dokter: Old description: '''Proposer:''' Duco Dokter [[BR]] '''Seconder:''' Alexander Limi, David Convent [[BR]] [[BR]] == Motivation == Registration of new users in Plone is very restricted in functionality: the registration fields are a fixed set. Adding extra fields to the form implies manually changing the HTML of the form, and customizing the registration_form template and process. == Assumptions == There is a need for more flexibility in the registration fields: one would like to be able to ask for a phonenumber, or company name, for instance. == Proposal Implementation == Add configlet for registration fields. Allow admin users to determine what fields need to be filled in upon registration. These fields will be required on the registration form. Change the join form into a dynamic form that will use the configuration settings to display the fields to the user to be able to register. == Deliverables == * New configlet in site setup for registration providing two settings: - join fields * Dynamic form for join process * Unit tests * Localization * Documentation == Risks == Default behavior will be same as current situation. When migration from an older Plone version si performed, the issue with join_form adaptations needs to be addressed. Most probably a warning is enough for a detected join_form customization. == Participants == * Duco Dokter, dokter * Kim Chee Leong, kcleong * Kees Hink, khink * David Convent, davconvent == Progress == Some of the work has been done at the Baarn 2009 sprint. New description: '''Proposer:''' Duco Dokter [[BR]] '''Seconder:''' Alexander Limi, David Convent [[BR]] [[BR]] == Motivation == Registration of new users in Plone is very restricted in functionality: the registration fields are a fixed set. Adding extra fields to the form implies manually changing the HTML of the form, and customizing the registration_form template and process. == Assumptions == There is a need for more flexibility in the registration fields: one would like to be able to ask for a phonenumber, or company name, for instance. == Proposal Implementation == Add configlet for registration fields. Allow admin users to determine what fields need to be filled in upon registration. These fields will be required on the registration form. Change the join form into a dynamic form that will use the configuration settings to display the fields to the user to be able to register. == Deliverables == * New configlet in site setup for registration providing two settings: - join fields * Dynamic form for join process * Unit tests * Localization * Documentation == Risks == Default behavior will be same as current situation. When migration from an older Plone version si performed, the issue with join_form adaptations needs to be addressed. Most probably a warning is enough for a detected join_form customization. == Participants == * Duco Dokter, dokter * Kees Hink, khink * David Convent, davconvent == Progress == Some of the work has been done at the Baarn 2009 sprint. -- -- Ticket URL: http://dev.plone.org/plone/ticket/9310#comment:21 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9311: Clean up of user related actions UI
#9311: Clean up of user related actions UI -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Description changed by dokter: Old description: '''Proposer:''' Duco Dokter[[BR]] '''Seconder:''' Alexander Limi, David Convent[[BR]] [[BR]] == 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 == Duco Dokter, dokter Kees Hink, khink Kim Chee Leong, kcleong David Convent, davconvent == Progress == Some of the work has been done at the Baarn 2009 sprint New description: '''Proposer:''' Duco Dokter[[BR]] '''Seconder:''' Alexander Limi, David Convent[[BR]] [[BR]] == 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
[PLIP-Advisories] Re: [Plone] #9347: registration policy
#9347: registration policy -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: closed Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: wontfix Keywords: | -+-- Changes (by esteele): * status: new = closed * resolution: = wontfix Comment: Rejected for 4.0 by FWT vote. -- Ticket URL: http://dev.plone.org/plone/ticket/9347#comment:7 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9315: New theme for Plone 4
#9315: New theme for Plone 4 ---+ Reporter: limi |Owner: limi Type: PLIP | Status: assigned Priority: n/a|Milestone: 4.0 Component: Templates/CSS | Resolution: Keywords: | ---+ Comment(by esteele): So I'm going to risk Limi never telling me his plans again and bring up some points he made during a recent chat... Basically there were several bits of his plans for the Plone-retheme that aren't included in the original proposal that, the more I consider them, I feel need to be further discussed with the wider group. 1. Writing the new theme in HTML 5. 2. Pull existing theme into a new package. 3. Removal of base_properties. 4. Inclusion of a change logo and insert CSS form. I'm +.5 on the first two, mainly because I would like some discussion of what, if any, theme migration challenges might be introduced. As far as 3 and 4... As much as I hate dtml-vars, I really like having the ability to make quick changes to site colors, font-sizes etc. I'm very much in favor of providing a simple theming story of some sort, but I want to make sure we do it correctly. While these two fields would cover some of the most common use cases, do they cover enough to warrant inclusion instead of just being a bit of duct tape? Can we update this to use a more modern approach, ie a utility/view that these stylesheets can pull variables out of or are we rejecting the use of variables in our CSS altogether? In the interest of full disclosure, we've put some time here at WebLion into building up CSSManager to do that sort of simple theming thing, so I may have a bias. I'd be remiss in my duties as release manager though if I let this slide by without us getting it right. -- Ticket URL: http://dev.plone.org/plone/ticket/9315#comment:20 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9315: New theme for Plone 4
#9315: New theme for Plone 4 ---+ Reporter: limi |Owner: limi Type: PLIP | Status: assigned Priority: n/a|Milestone: 4.0 Component: Templates/CSS | Resolution: Keywords: | ---+ Changes (by esteele): * cc: robzonenet (added) -- Ticket URL: http://dev.plone.org/plone/ticket/9315#comment:21 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9324: Use Amberjack to offer guided help for first-time users
#9324: Use Amberjack to offer guided help for first-time users ---+ Reporter: limi |Owner: sknox Type: PLIP | Status: assigned Priority: n/a|Milestone: 4.0 Component: Documentation | Resolution: Keywords: | ---+ Changes (by sknox): * status: new = assigned -- Ticket URL: http://dev.plone.org/plone/ticket/9324#comment:24 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9315: New theme for Plone 4
#9315: New theme for Plone 4 ---+ Reporter: limi |Owner: limi Type: PLIP | Status: assigned Priority: n/a|Milestone: 4.0 Component: Templates/CSS | Resolution: Keywords: | ---+ Comment(by MatthewWilkes): Eric: There are at least 3 FWT members who voted yes with the proviso that base_properties would still work. I will be -1 on any implementation that breaks this. A change logo and add CSS form would need their own PLIP, imho, so would be -1 on inclusion. This isn't intended to start a debate, Alex should implement what he's suggested and we've said we want, not something else. -- Ticket URL: http://dev.plone.org/plone/ticket/9315#comment:22 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9310: User registration process more flexible
#9310: User registration process more flexible -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by khink): (In [28069]) Create a branch of CMFPlone for work on PLIP #9310. refs #9310 -- Ticket URL: http://dev.plone.org/plone/ticket/9310#comment:22 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9310: User registration process more flexible
#9310: User registration process more flexible -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by khink): (In [28070]) Added plip config for #9310, refs #9310 -- Ticket URL: http://dev.plone.org/plone/ticket/9310#comment:23 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9310: User registration process more flexible
#9310: User registration process more flexible -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by khink): (In [28072]) refs #9310: PLIP work on plone.app.user for flexible member registration -- Ticket URL: http://dev.plone.org/plone/ticket/9310#comment:24 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9310: User registration process more flexible
#9310: User registration process more flexible -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by dokter): (In [28073]) Added plone.app.users to source for this config refs #9310 -- Ticket URL: http://dev.plone.org/plone/ticket/9310#comment:25 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9186: Set Image IDs from Title field
#9186: Set Image IDs from Title field +--- Reporter: erikrose|Owner: erikrose Type: PLIP| Status: assigned Priority: minor |Milestone: 4.0 Component: Archetypes | Resolution: Keywords: | +--- Changes (by erikrose): * status: new = assigned -- Ticket URL: http://dev.plone.org/plone/ticket/9186#comment:30 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #8901: Deleting a user should revoke roles
#8901: Deleting a user should revoke roles +--- Reporter: erikrose|Owner: erikrose Type: PLIP| Status: assigned Priority: major |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Changes (by erikrose): * status: new = assigned -- Ticket URL: http://dev.plone.org/plone/ticket/8901#comment:28 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9310: User registration process more flexible
#9310: User registration process more flexible -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by dokter): (In [28081]) Added configlet for registration refs #9310 -- Ticket URL: http://dev.plone.org/plone/ticket/9310#comment:26 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9310: User registration process more flexible
#9310: User registration process more flexible -+-- Reporter: dokter |Owner: dokter Type: PLIP | Status: assigned Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by dokter): (In [28083]) Added registration configlet refs #9310 -- Ticket URL: http://dev.plone.org/plone/ticket/9310#comment:27 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
