[Zope-CMF] Re: What is a member?

[Florent Guillaume]

Yuppie wrote:
> Florent Guillaume wrote:
> 
>> What is it really to be a member of a portal ?
>>
>> 1) we have the Member role, but nowhere is it enforced that members 
>> must be Member.
> 
> members represent users that are allowed to login to the portal and use 
> features of the site that are not public. They might have different 
> global or local Roles.
> 
> The 'Member' Role represents a basic set of Permissions common members 
> have for the site. Sometimes this Role represents the least common 
> denominator and all members have the 'Member' Role. In other cases 
> members with Roles like 'Reviewer' or 'Manager' don't have a 'Member' 
> Role. I would not enforce one policy.

Really ? I think Reviewers and Managers should also be Member. But 
obviously not everyone does that...


>> 2) the membership tool sometimes returns info (in searches for 
>> instance) about the members it has seen before but without consulting 
>> the underlying acl_users at all.
> 
> That could make sense if there is a user source with thousands of users 
> and only some of them use the portal. In this case you can think of 
> members as users that did login at least once. (Maybe a distinction 
> sleeping vs. active members makes sense.)

Yes. But I'd like it made explicit somewhere...


>> 3) in some cases members may have been created by joining (thus 
>> passing through registration) but sometimes they come from an external 
>> user source updated beyond the knowledge of Zope.
>>
>> Note that for example the LDAPUserFolder has chosen to only return 
>> "cached" users when one calls listMembers. I understand the reasons 
>> but I consider it a big problem.
> 
> Would be nice if all these external user sources would
> - store the member properties
> - implement a search that returns Batch-like results

That's what I'm doing right now. But we cannot assume that all member 
properties will be stored by the external user source, I think we'll 
always have to deal with properties that we want to let the MemberData 
store (think login_time and read-only LDAP user sources).

So any batch search will first do the search using the userfolder API 
(that I'm adding), and then if there remains internal properties, on 
those. But if we search the fullname all users that have login_time > 
somedate, I see no way to make it efficient (LDAP search will return all 
users, and then MemberData will filter on the login_time property it 
knows). [Note I have no plan to implement '>' searches for now.]


>> In refactoring this stuff, I'd like to know who I should consider a 
>> member for purposes of info returned by listMemberIds, listMembers, 
>> searchMembers for instance.
> 
> I didn't close <http://zope.org/Collectors/CMF/189> because I'm not 
> happy with the current state of searchMembers. searchMembers is only 
> protected by 'List portal members' so it should not return a list of 
> members without 'listed' flag true. For privacy as well as for 
> performance reasons we should not return the whole list if no search 
> string is specified. People should know pretty well what they are 
> looking for. Maybe the search string should contain at least 4 
> characters or something like that.
> 
> listMemberIds and listMembers are only useful for small sites or rare 
> cases like sending newsletters to each member. In all other cases a 
> Batch mode would be useful that returns only the members and the 
> properties that should be displayed on the current page.

Yes. But that's a different problem, and I still don't know how to 
answer my question above...

I'm beginning to think that I'll have to add a configuration choice to 
portal_membership:
- all acl_users users are members
- or only acl_users users that have logged in (are cached in MemberData) 
are members
Plus a checkbox:
- only those with Member role (or Manager) are members.

But man, that's a lot of complexity...

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg at nuxeo.com