-----Original Message----- From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of Guillaume Lerouge Sent: Monday, August 09, 2010 11:25 AM To: XWiki Developers Subject: Re: [xwiki-devs] [Proposal] Introduce user management configuration in virtual mode Hi, sounds good to me. Forcing only global users is a frequent use case,

for intranets. OTOH forcing only local users can be useful for farms of

or separate websites (I'm thinking of websites such as myxwiki.orgfor instance). Guillaume On Wed, Aug 4, 2010 at 11:30, Jean-Vincent Drean <jean- vincent(a)drean.org&gt;wroteote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

+1 Jerome On Fri, Sep 17, 2010 at 11:39 AM, Jean-Vincent Drean &lt;jean-vincent(a)drean.org&gt; wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Up! I could commit the code I have if we agree that it is going in the good direction. I'm thinking about the component implementation proposal in particular: http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule#HUsersComponent Thanks, JV. On Wed, Aug 4, 2010 at 11:30 AM, Jean-Vincent Drean &lt;jean-vincent(a)drean.org&gt; wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi JV, Sorry for being late. Some quick comments: 1) your mail wasn't really about the new users module but about a specific question... I was expecting a general architecture discussion about a users module.

2) I read http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule and when I read it I miss the feeling that the architecture is sound and all-encompassing. It would be good to know the extent to which this module will go and what it'll do exactly, to be sure we're not missing things and that it's not overstepping in some other module's area. Will it do user registration? Will it allow to add/remove/modify users? What about Groups?

3) Would it be possible to not have the number and offset params and instead return a ResultSet<User> object that you could query to get the data with a cursor (same as the JDBC api basically). It makes the API better IMO.

4) I don't like the "String match" parameter. It's very restrictive. What if I want to search on the phone number of a user? Or simply on its first name only? Also this should probably just call a more generic search module that does search on objects.

5) "Define at which level users and groups should be handled in the farm". Not sure what this affects. For example if I want  to get all local users, what API do I use?

Thanks -Vincent On Sep 17, 2010, at 11:39 AM, Jean-Vincent Drean wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Sep 23, 2010, at 6:14 PM, Jean-Vincent Drean wrote: Then DocumentReference in the User object is not correct... ;)

No it's not. It's about anything that returns more than 1 page of data. It's very generic. It allows to have a clean api that doesn't add non business parameters.

I'm very serious. Any design proposal that focus on a specific aspect without allowing more complex use cases it completely flawed to me.

errr? We're talking about APIs here.... why would I? Simply because there's a notion of local and global users so we need an api to return local users, global users, all users, etc.

Whenever you talk specific without being able to do something generic you can be sure your API is flawed and this is my main concern with the proposal: I see it very focused on a single need and IMO it hasn't been thought to be generic. While I'm fine with this we need to know it's going to have to be broken very soon and thus it's not really an API and should be internal instead.

It's ok to be minimalistic but it's not ok not to prepare for all the use cases because you'll have to break the api later on. Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Sep 23, 2010 at 21:23, Jean-Vincent Drean &lt;jean-vincent(a)drean.org&gt; wrote: Actually I think an important part of complex rightsmanager filtering capabilities are currently used by rights/users/groups UI.

-- Thomas Mortagne

Here is a proposal: ResultSet concept is a good idea but we can't use it as it IMO because it's way to SQL oriented. We could define some kind typed Query/Resultset couple for users: UserQuery very minimalistic for now (that we would extends latter with more supported fields and custom fields) - setLimit() - setOffset()

- something like setNameMatching(String valueToMatch) that does not block the possibility to add latter support for other fields when we will add more fields in User itself without generating any deprecation, typed make it safer and it's always possible to add setMacthing(String field, Object valueToMatch) latter when we will add support for custom fields in User

UserResultSet (to be safe): - same next/previous and close based system than ResultSet - User getUser()

and: UserResultSet UserManager#getUsers(UserCriteria criteria)

Maybe put the DocumentReference in a bridge like proposed to not constrain User API to be linked to a wiki page to avoid the pain of removing it latter when user manager will contains all user related tasks and will allow us to link it directly to the real user directory like LDAP etc.

Hi all, I just had a discussion with JV about this, and my initial opinion is something like this: On 09/23/2010 09:23 PM, Jean-Vincent Drean wrote: +1, not correct but we need a method to relate a User instance with its details (the XWikiUsers object in the document, if it's a wiki implementation, etc). I agree here, it just makes it complicated for API (well, temporary API or however it should be called) users to operate with, I don't think one should know what a result set is in order to be able to get the next 25 users starting from the 20th user. Not -1, is just feels more friendly with primitives instead of classes. Although it makes a lot of sense to filter by various values of fields (as a general approach), if filtering is allowed by other fields, then these fields need to be also returned in the User class (to be completely coherent). If the fields are also stored in the User class, then basically we just endup copying data from XObjects to User objects. Although possible, because of cache size and synchronization it doesn't seem as a very good idea. I think the path to go is minimalistic User implementation (some sort of a 'pointer' to a user) which can be connected with the actual implementation for the user (in this proposal, it's the DocumentReference) but in general it could be the user id (which in the case of wiki users it's the serialized document reference of the user document but it can have any other form for other user implementation). If this is achieved, then we could do anything with the returned users (because we can find the full, original data) and this component meets its purpose (of handling users retrieval (global - local)) with a very light implementation. this would solve the situation when you don't know exactly what are these users and where do they come from, you just want all the users on the farm (for rights, or for listing available users). If you know there is the notion of local users and that you want only those, you go to XObject level, as JV said. In my view, this API should not completely replace all users management everywhere, XWiki.XWikiUsers class should still be used for specific cases, it's just there to save a few ifs that you'd do everytime you handle users, it's like a shortcut for frequent cases (even the proposed "local", "global", "mixed" scopes have the same flavour of frequently used cases) and make sure there's an easy way to deal all the situations when listing users are needed in an unified way (JV please correct me if I'm wrong on this one).

Thanks, Anca >> >> errr? We're talking about APIs here.... why would I? Simply because there's a notion of local and global users so we need an api to return local users, global users, all users, etc. > > There's a notion of local and global wiki pages, but should it matter > for user management ? > >> >> Whenever you talk specific without being able to do something generic you can be sure your API is flawed and this is my main concern with the proposal: I see it very focused on a single need and IMO it hasn't been thought to be generic. While I'm fine with this we need to know it's going to have to be broken very soon and thus it's not really an API and should be internal instead. >> > > I think we know enough our needs to be able to define a specific API > that won't have to be broken. > > Thanks, > JV. > >> It's ok to be minimalistic but it's not ok not to prepare for all the use cases because you'll have to break the api later on. >> >> Thanks >> -Vincent >> >>> >>>> Thanks >>>> -Vincent >>>> >>>> On Sep 17, 2010, at 11:39 AM, Jean-Vincent Drean wrote: >>>> >>>>> Up! >>>>> >>>>> I could commit the code I have if we agree that it is going in the >>>>> good direction. >>>>> I'm thinking about the component implementation proposal in particular: >>>>> http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule#HUsersComponent >>>>> >>>>> Thanks, >>>>> JV. >>>>> >>>>> On Wed, Aug 4, 2010 at 11:30 AM, Jean-Vincent Drean >>>>> &lt;jean-vincent(a)drean.org&gt; wrote: >>>>>> Hi Devs, >>>>>> >>>>>> I'd like to introduce a new configuration property that would define >>>>>> at which level users should be handled in a farm. >>>>>> See the proposition about the new entry in xwiki.properties, it should >>>>>> be self-explanatory: >>>>>> >>>>>> --------------------------------8<-------------------------------- >>>>>> #-# [Since 2.5M1] >>>>>> #-# Define at which level users and groups should be handled in the >>>>>> farm. Available modes: >>>>>> #-# >>>>>> #-# mixed (default): >>>>>> #-# - user registration available in the main wiki and local wikis >>>>>> #-# - users from the current wiki and the main wiki will be displayed >>>>>> in the rights interface and user suggests >>>>>> #-# - user administration is present in all the wikis >>>>>> #-# >>>>>> #-# local: >>>>>> #-# - user registration available in the main wiki and local wikis >>>>>> #-# - only users from the current wiki will be displayed in the rights >>>>>> interface and user suggests >>>>>> #-# - user administration is present in all the wikis >>>>>> #-# >>>>>> #-# global: >>>>>> #-# - user registration available in the main wiki only, the register >>>>>> link in local wikis will point to the main wiki >>>>>> #-# - only users from the main wiki will be displayed in the rights >>>>>> interface and user suggests >>>>>> #-# - user administration is present in the main wiki only >>>>>> core.virtual.users=mixed >>>>>> -------------------------------->8-------------------------------- >>>>>> >>>>>> More details are available here: >>>>>> http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule >>>>>> >>>>>> WDYT ? >>>>>> >>>>>> Thanks, >>>>>> JV.

On Fri, Sep 24, 2010 at 5:37 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: The current module covers 3 needs: display users in the user directory, display users in the administration, display users in the rights UI. Those are specific use cases and I understand your concerns about the search/matching not being extensible enough, wdyt about the user criterion proposal from Thomas ?

On 09/27/2010 05:14 PM, Jean-Vincent Drean wrote: What about free-form filters in the UserCriteria: public void addFilter(String property, String filter) This would allow filtering by custom fields, like Country, Description, Office...

One thing which isn't clear is what exactly is filter? Is it supposed to be a plain string which is extended by the class with %...%, or is it supposed to be a complete thing to send to the storage, including the eventual %? Is it applied on both fname and lname, or on their concatenation?

On 09/28/2010 02:11 PM, Jean-Vincent Drean wrote: Still one unanswered question: what does it match on? doc.fullName, fname || lname, fname + " " + lname, all of them?

Still one unanswered question: what does it match on? doc.fullName, fname || lname, fname + " " + lname, all of them?

I needed something to represent users and groups in the new rights management implementation, so I just committed a different proposal for users and user management. My implementation is centered on individual users, not on their management, so I removed the count and retrieve all users methods. So, the core is the User interface, which represents an (abstract) user. IMO, this interface allows to have users coming from different authentication systems, not just wiki users with a profile object in a document. There are two methods to get to the underlying entity, getProfileDocument and getProfileURI, both optional. It has a generic getAttribute method, which allows to retrieve all/any information associated with a user, with no other metadata important enough to have its own method, except the user full name, which I considered to be one of the identifiers, not metadata. The UserManager allows, for the moment, just to retrieve a user from an identifier. The default user manager is actually a meta manager, which asks other UserManager implementations to resolve an identifier into a proper user object, allowing to have a mix of users coming from different sources in the wiki. I kept in the implementation a way to achieve what JV needed in the first place, a way to force users to be defined in local wikis, or only in the global wiki, or just in a specific wiki (for example, all users are to be defined in the "users" wiki, so they are global, but they can't accidentally get Programming Rights). I added a few remarks and questions on the commit (comments welcome) at https://github.com/xwiki/xwiki-platform/commit/34a0f83c354ac68eca75c7141133… Note that this is just a PoC, waiting for validation that it's the right approach. I have something similar in mind for Groups as well, but I'd like to keep groups and users separate (two different modules), with no connection from users to groups, only the other way around. On 08/04/2010 11:30 AM, Jean-Vincent Drean wrote: