Ticket #13350 (confirmed PLIP)
Define extra member properties TTW
Reported by: | ebrehault | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | General | Version: | |
Keywords: | Cc: | interra |
Description (last modified by kiorky) (diff)
Motivation
Be able to define extra member properties is a very simple and
common need for a CMS.
In Plone, the current way to achieve that, described here
http://pypi.python.org/pypi/collective.examples.userdata, is
very complex.
Most part of time, newcomers will not able to do that.
Comparatively, they can very easily create a new content-type TTW
with Dexterity, but adding member properties is impossible.
We should provide a way to manage extra member properties TTW.
Assumptions
N/A
Proposal & Implementation
- Modify plone.app.users so its UserDataSchema can be edited with a Dexterity-like schema editor.
- Make sure this schema can be imported/exported via GenericSetup.
- The @@member-registration form could be removed, as the TTW schema editor will allow to define which fields must be part of the join form.
- Allow users to define valitor as a per field basis. We will rely on a queryAdapter call to grab those validators throught a schema.Set() field.
Deliverables
plone.app.users new version
Risks
N/A
Participants
Eric BREHAULT (ebrehault) Mathieu Le Marec - Pasquet (kiorky)
Change History
comment:2 Changed 3 years ago by ebrehault
- Component changed from Unknown to General
- Type changed from Bug to PLIP
- Milestone changed from 4.x to 4.4
comment:5 Changed 3 years ago by toutpt
Great Eric !
I'm about to start an addon to create a pas plugin which return global preferences to switch off "preferences" provided by portal_memberdata.
Keep in mind other plugins should be able to provide extra member data which is not possible at the moment without monkey patches or just switch off memberdata.
Example:
- provide portrait from gravatar.
- provide contact info from a CRM
- provide wysiwyg preference from default (not stored for each member).
comment:6 Changed 3 years ago by davisagli
Some thoughts re implementation:
- See https://github.com/davisagli/collective.pigeonhole for an example of an alternative "schema context" for plone.schemaeditor which loads and stores the serialized schema in a different location than on an FTI.
- GenericSetup import/export should be pretty easy to implement using plone.supermodel's serialization of schemas. But we should make sure there's a way to provide a real interface from filesystem code rather than the TTW one if necessary.
- Re toutpt's comment, other plugins should still be able to provide member properties because I presume that PAS property plugins will still be used to obtain property sheets when retrieving properties.
- Since this and #12253 both deal with the registration forms, please coordinate with the authors of that PLIP too.
- If the new registration forms are z3c.form-based, we can make it so that plugins can also provide additional fields by making the form extend AutoExtensibleForm from plone.autoform and implement additionalSchemata to look up additional schemas as adapters.
- We'll want some sort of migration of the current configuration from @@member-registration into the new schema.
comment:7 Changed 3 years ago by davisagli
Congratulations, the framework team has approved this proposal to be implemented for Plone 4.4. Please feel free to ask if you need help with the implementation or with figuring out the PLIP process. Once there is an implemenation ready to be reviewed, let me know where to find the review buildout.
comment:9 Changed 3 years ago by ebrehault
I think it is better to keep the @@member-registration tab unchanged. So the extra-fields are managed into a new tab (Member fields), and registration fields (which contain default fields and extra fields) are managed and ordered in the existing Registration tab.
Defining from the schema editor if a field belongs to the registration form is nice but as it might be effective on extra fields but also on default fields (which are not supposed to be editable through the schema editor) it is confusing. Moreover it allows to order differently the user info form fields and the registration form fields.
comment:10 Changed 3 years ago by timo
Does this PLIP include a new control panel or the refactoring of an existing control panel? If so I'd recommend that it should be plone.autoform/z3c.form-based in the first place, to avoid extra work once we move all control panels to use z3c.form: https://dev.plone.org/ticket/10359
comment:11 Changed 3 years ago by davisagli
Review of PLIP 13350: Define extra member properties TTW
Framework team review by David Glick, 2013-05-14
Review steps:
- Look over code changes: https://github.com/plone/plone.app.users/compare/master...plip13350-edit-member-schema-ttw
- Build coredev 4.4 using plips/plip13350-edit-member-schema-ttw.cfg, and try things TTW
Notes:
- This adds a "Member fields" tab to the users and groups area of the control panel, which exposes a Dexterity-style schema editor. Fields configured here show up on the personal information form, and are saved to the memberdata property sheet. The registration form may include some of these fields (as configured on the Member Registration tab) in addition to the normal registration form fields.
- There's GS handlers to export/import the schema, which is good.
- This implementation depends on the PLIP 12253 implementation.
- This currently depends on a fork of plone.schemaeditor to provide support for TTW ASCII fields, used by the email field. I would really prefer not to make TTW users understand the difference between text and ASCII. I would rather create an Email field. Franco Pellegrini already started one in plone.schema that we could use.
- Some of the forms in z3cpersonalpreferences.py are doing something really crazy and calling provideAdapter from their init methods. It would be a lot saner for the forms to implement getContent() and make it return an instance of the adapter after calling alsoProvides to make it provide the schema.
- Dynamically generating a schema instance for the registration form is also pretty insane. We need a solution that does this once each time the schema is edited, not once each time the form is viewed.
- In general it seems like there's a lot of complexity added by trying to merge fields from a base schema with fields edited TTW. The usability is also confusing because if I edit one of the predefined fields, then restart my instance, the change is lost. Is there a compelling reason not to just make everything editable TTW?
- There's a field added to configure validators for a field. It's a nice idea but I would like to find a good general way to solve this in plone.schemaeditor rather than creating a plone.app.users-specific solution.
- This disables the old IUserDataSchema adapter. We need documentation for integrators on how to update their custom member metadata.
- Why are all the tests in the package disabled? The new functionality also has no tests.
- The schema editor copies the 'Save Defaults' button from plone.schemaeditor. We determined this was bad UX and removed it in schema editor. We should do that here too (the defaults can now be set in the field overlay).
- We need to move the CSS from the schema listing template into a separate CSS file, so that we aren't including it in multiple places.
Conclusion:
This is an ambitious PLIP, and it makes for an impressive through-the-web demo. Good work! But the implementation scares me because of the excessive dynamic creation of new schema instances and adapter registrations and because nothing is tested. I'd like to see this feature in core at some point, but we need to do it in a way that has fewer moving parts and is easier to explain. I will try to take a look soon and see if I can prototype a better approach. I'm -1 on merging it as it exists at the moment.
comment:12 Changed 3 years ago by esteele
- Milestone changed from 4.4 to 5.0
The Framework Team has decided to move on to Plone 5. Updating milestones accordingly.
comment:14 Changed 2 years ago by ebrehault
As the master had change a lot since the PLIP development has started (and specifically the merging with the z3c.form branch), I have decided to create a fresh new branch based on the current master: https://github.com/plone/plone.app.users/tree/plip13350-edit-member-schema-ttw-post-z3cform-merge and merged what had been done up to now on this PLIP (including the cleanings and improvments proposed by Myroslav).
It does work and the existing tests pass successfully. Now I would like to add some robot tests about the TTW editing itself.
comment:15 Changed 18 months ago by ebrehault
I try it on Plone 5 and I give an estimate by next week.
comment:16 Changed 18 months ago by ebrehault
It works fine on Plone 5 with branch https://github.com/plone/plone.app.users/tree/plip13350-edit-member-schema-ttw-post-z3cform-merge (it does need https://github.com/plone/plone.app.controlpanel/tree/plip13350-edit-member-schema-ttw in order to display the right actions in control panel).
I have noticed that the original default fields have been restricted to fullname + email (so no description, no portait, no homepage, no biography anymore). It has been done by Ian Anderson here https://github.com/plone/plone.app.users/commit/1bb9bb089353c4f08a254888c40b795677b86a8f I think it makes sense (as we can easily add those fields with the editor if we need them), but it was not in the scope of the current PLIP. Shall we keep it that way ?
comment:17 Changed 18 months ago by frapell
Maybe we should ask Ian why he modified the default fields... As you mention, it doesn't appear to be part ofthis PLIP, and I don't know if it was discussed somewhere.
However I am +1 on simplifying these forms, as long as there's an easy way to manage fields (Maybe a GS step?)
comment:18 follow-up: ↓ 19 Changed 18 months ago by frapell
Also, putting this change on the default fields on the side, is this ready for merging? are tests passing, etc?
comment:19 in reply to: ↑ 18 ; follow-up: ↓ 20 Changed 18 months ago by ebrehault
Replying to frapell:
Also, putting this change on the default fields on the side, is this ready for merging? are tests passing, etc?
Yes, specific tests have been added regarding the schema edition, and all tests are passing. I consider it is ready for merging.
comment:20 in reply to: ↑ 19 Changed 14 months ago by frapell
Eric, I have added my review on this PLIP in https://github.com/plone/buildout.coredev/blob/5.0/plips/reviews/plip13350-review-frapell.rst
comment:21 Changed 13 months ago by ebrehault
I have made several changes:
- more tests (robot tests + GS import/export unit test)
- remove useless/meaningless field types, so now we only have: text, textline, richtext, boolean, integer, float, set, choice, date, image
- implement the upgrade step properly
- flake8 cleanning
I have also made some fixes in plone.schemaeditor:
- make fieldset creation optional
- fix the allowedFields mechanism
- add the CSRF protection for plone 5
There is one point which is a little bit annoying: the image field type.
We do need this field type, because people might want to have a portrait for portal members. But we have to store its value as 'portrait' (= what will be returned by portal_membership.getPersonalPortrait() method), because the rest of Plone expects it to be named that way. So what I did is that if there is an Image field (whatever is its name) in the TTW schema, we store its content in portal_membership as portrait.
It is probably not ideal, but I do not see any simple approach to solve that (it would imply to change the portal_membership tool, which out of scope I think).
Regarding your questions:
- creating ProtectedTextLine and ProtectedEmail seems to be the only way to set 'editable' to False, unless there is something easier in plone.schemaeditor I am not aware of.
- I do not think we can re-use directly what's doen in plone.supermodel because we need to read/write data into portal_membership