Forgot your password?
New user?
Document Actions
#47: Disentangling User Name from Member Content Folder Id
- Contents
- Proposed by
- pupq
- Proposal type
- State
- rejected
Motivation
Common cases for this are:
- Use of an email address as a username. This is allowed by most user folder implementations, but disallowed as a Zope ID. Therefore, the user can be created (if done by hand), but the member folder and portrait cannot.
- Selective creation of member areas. The new API will be hookable to allow member creation for certain members.
- Disentangled member names and user names. The system may require a username in a certain, ugly format (ie, my username might have to be something awful like "BURTOJ", but my membername could be "burton_joel". This is what would be used for portraits, member folders, etc.
Proposal
Currently, when a member's standard content is created, it uses the member's userid as the id for several things, most obviously the member folder. This makes Plone inflexible for cases where the usernames follow a strange or ugly format, or contain symbols not allowed in Zope ids. This PLIP proposes changes to Plone that allow for the separation the naming of member content (the member's folder, the member's portrait, etc.) from the username, and also allows flexibility in only certain users have member areas created for themselves.
Implementation
Definitions:
- username. Name of the user in the user folder (e.g, "joel" or "joel@joelburton.com".)
- member content id. ID used for member content objects (the member folder being the most important). This must be a valid Zope ID.
There are two different possibilities for the conversion of username -> member_content_id:
- A rule-based-transformation. For example, username.replace('@','_at_'), so that usernames would be email addresses (user@foo.com), and member_content_ids would be transformed from this (user_at_foo.com). In this case, the member_content_id wouldn't have to be stored anyway, as it could be easily calculated from the username.
- A complex or arbitrary transformation. For example, the username being "BURTOJ" and the member_content_id being "burton_joel". There's no way to simple transform the first to the second. Here, the member_content_id would be stored.
Implementation
Hook every place where the Plone API looks for a username as 'members_folder[userid]', and replace with 'members_folder[mtool.getMemberContentId(userid)]'.
getMemberContentId
Create the method 'getMemberContentId(userid)' on the membership tool. This method simply returns the transformed/found member_content_id as a string; it does not actually verify that there is a home folder with this name, etc. The default method would be a stub that just returns the userid, giving us the same behavior as Plone normally does.
However, two common overrides would be:
- perform the textual transformation on the member id here.
- lookup other things (such as member first and last name) and perform a transformation on that to get the member_content_id.
- lookup the member_content_id itself, which might be an attribute on the user object itself, or stored on the member object.
In addition, if this method returns None, it signifies that this user id should get no member content. So, no member folder should be created, etc. This could be used to allow some members to get member folders, but not others, based on anything we could discover in this method.
createMemberArea
This method would be changed to look up the member_content_id using the API, above, and selectively create the member content area as needed and named.
In addition, it would call out to 'storeMemberContentId(user_id, member_content_id)'.
storeMemberContentId
This method would normally be an empty stub; however, it could be overridden or patched to store the member_content_id. This would be used in those cases where this must be later looked up in getMemberContentId.
isMemberIdAllowed
This will be changed by this PLIP, so that allowed member id pattern no longer has a private name, changing from '__ALLOWED_MEMBER_ID_PATTERN' to ALLOWED_MEMBER_ID_PATTERN. Therefore, to configure things, this attribute can be changed without having to patch or subclass this method. However, for complicated patterns, it may be desirable for some configurators to subclass this method.
Status
I'd love help building this! I've written a test-implementation, and it passes Plone tests and seems to work functionally, but it needs some cleaning up, and I've love feedback on how to polish the API.
