[Zope-CMF] CMF 1.4 Roadmap

[Mark McEahern]

[Andy McKay]
> You could do it, but its always annoyed me in the past because: people
> may want to hide their email, which can be a little harder if its your
> id, what if you change email?
>
> It could be done, dont know if anyone wants to propose it or take it on.
> Would you be willing to make it an option?

Just for grins, I modified CMFCore/RegistrationTool.py/isMemberIdAllowed()
to just return 1 (skip checking).

Then, I modified CMFCore/MembershipTool.py/wrapUser() to raise errors
instead of suppressing them.

I got this traceback:

<traceback>
Module ZPublisher.Publish, line 98, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Products.CMFCore.FSPythonScript, line 90, in __call__
Module Shared.DC.Scripts.Bindings, line 252, in __call__
Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec
Module Products.CMFCore.FSPythonScript, line 124, in _exec
__traceback_info__: ({'script': <FSPythonScript at /MIPSPortal/register>,
'context': <MIPSSite instance at 018B2638>, 'container': <MIPSSite instance
at 018B2638>, 'traverse_subpath': []}, (), {}, None)
Module Script (Python), line 23, in register
Module Products.CMFCore.RegistrationTool, line 130, in addMember
Module Products.CMFCore.MembershipTool, line 407, in addMember
Module Products.CMFCore.MembershipTool, line 307, in getMemberById
Module Products.CMFCore.MembershipTool, line 136, in wrapUser
Module Products.CMFDefault.MembershipTool, line 155, in createMemberarea
Module Products.CMFCore.PortalFolder, line 136, in manage_addPortalFolder
Module OFS.ObjectManager, line 244, in _setObject
Module Products.CMFCore.PortalFolder, line 383, in _checkId
Module OFS.ObjectManager, line 60, in checkValidId
Bad Request: The id "mark@mceahern.com" contains characters illegal in URLs.
</traceback>

So, from my neanderthal way of thinking, allowing emails as usernames means
we have to distinguish between the portal username and the member's id.

Which means either: 1) the system autogenerates an id for the user; or 2)
the system converts the email address into a member id (e.g.,
mark@mceahern.com --> markATmceahernDOTcom); or 3) the user has to pick a
member id.

3 defeats the purpose of doing this.  2 seems dumb.  And 1 means the URLs
aren't going to be easy to remember (imagine if we used GUIDs).

Since the member's id is part of URLs, it should probably be friendly (easy
to remember).

And, as you pointed out, some folks wouldn't want their email to be visible
like that.

Hmm, I think I've just shot my idea in the foot.

:(

It does seem like there's a conflation of several things going on here, but
I'm not sure how to untangle them:

1) What the user uses to login and retrieve forgotten passwords (to me,
email is the natural candidate).

2) How the URLs of the user's member space look.

3) The underlying id used by the system.  From my relational database days,
I always thought it made sense to use IDs that purposely were stripped of
all possible meaning--that way, there's no itchin' to change them.

I think making this change in CMF is going to be a lot harder than I
thought.

// m

-