+1 Thanks, Florin Ciubotaru

-----Original Message----- From: [email protected] [mailto:[email protected]] 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, notably for intranets. OTOH forcing only local users can be useful for farms of public 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- [email protected]>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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

+1, but I think we should also discuss how this could or will interact with LDAP authentication and/or with rights checking. Denis On Fri, Sep 17, 2010 at 12:58, Jerome Velociter <[email protected]> wrote:

+1

Jerome

On Fri, Sep 17, 2010 at 11:39 AM, Jean-Vincent Drean <[email protected]> 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 <[email protected]> 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.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

+1 Thanks, Marius On 09/17/2010 12:39 PM, 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 <[email protected]> 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.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Sep 23, 2010 at 5:34 PM, Vincent Massol <[email protected]> wrote:

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.

Since the thread wasn't clear enough I've pinged people individually.

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?

There are many open questions, I've kept the proposal minimalistic on purpose, it's only a starting point. Now from my PoV this module should not handle user management (CRUD), it should be a very generic proxy, for example we can imagine (long-term) an implementation using LDAP that doesn't even create a profile page within the wiki (thus avoiding sync problems). About groups, I think they should be handled by the user module since they are just sets of users.

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.

ResultSet sounds very RDBM oriented IMHO, I'm thinking about the users module as a very minimalistic proxy, a name, a pointer to the user profile (wherever it is, possibly external), possibly a method that allows to authenticate the user in the future.

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.

Come on Vincent :) do you really search persons by phone number or first name only ? I think mobile phones do a great job at helping to find persons: first name + last name with filtering and a good default ordering (it'd nice to order by last name). I like the approach for its simplicity. I wonder what the others think about this. About the generic search on objects it only fits with users stored in the wiki.

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?

Why would you ? If it is for maintenance the XWiki.XWikiUsers class page should provide the list but if you're looking for a user profile does it matter that it is stored in the local or the global wiki ?

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 <[email protected]> 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.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Sep 23, 2010 at 6:27 PM, Vincent Massol <[email protected]> wrote:

On Sep 23, 2010, at 6:14 PM, Jean-Vincent Drean wrote:

...

...

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?

There are many open questions, I've kept the proposal minimalistic on purpose, it's only a starting point. Now from my PoV this module should not handle user management (CRUD), it should be a very generic proxy, for example we can imagine (long-term) an implementation using LDAP that doesn't even create a profile page within the wiki (thus avoiding sync problems).

Then DocumentReference in the User object is not correct... ;)

Indeed :)

...

About groups, I think they should be handled by the user module since they are just sets of users.

...

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.

ResultSet sounds very RDBM oriented IMHO,

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 not -1 about this, I just find it a bit overkill. It'd also make it a bit more difficult to use from velocity (but may be the script service could hide the complexity).

...

I'm thinking about the users module as a very minimalistic proxy, a name, a pointer to the user profile (wherever it is, possibly external), possibly a method that allows to authenticate the user in the future.

...

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.

Come on Vincent :) do you really search persons by phone number or first name only ? I think mobile phones do a great job at helping to find persons: first name + last name with filtering and a good default ordering (it'd nice to order by last name). I like the approach for its simplicity. I wonder what the others think about this.

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

I understand that we need to be able to handle custom and complex use cases but I think the XObjects model is here for that. We need a module allowing to retrieve XObjects with matching/filtering on any field, I agree. I think we know enough what we need to manage our users to define a specific API, the rightsmanager API was allowing much more complex things but those capabilities haven't been used (Thomas stop me if I'm wrong). The current proposal will need additions but I don't think it is flawed by design, I'd say it is based on known needs.

...

About the generic search on objects it only fits with users stored in the wiki.

...

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?

Why would you ? If it is for maintenance the XWiki.XWikiUsers class page should provide the list but if you're looking for a user profile does it matter that it is stored in the local or the global wiki ?

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 <[email protected]> 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.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Sep 23, 2010 at 21:51, Thomas Mortagne <[email protected]> wrote:

On Thu, Sep 23, 2010 at 21:23, Jean-Vincent Drean <[email protected]> wrote:

...

On Thu, Sep 23, 2010 at 6:27 PM, Vincent Massol <[email protected]> wrote:

...

On Sep 23, 2010, at 6:14 PM, Jean-Vincent Drean wrote:

...

...

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?

There are many open questions, I've kept the proposal minimalistic on purpose, it's only a starting point. Now from my PoV this module should not handle user management (CRUD), it should be a very generic proxy, for example we can imagine (long-term) an implementation using LDAP that doesn't even create a profile page within the wiki (thus avoiding sync problems).

Then DocumentReference in the User object is not correct... ;)

Indeed :)

...

...

About groups, I think they should be handled by the user module since they are just sets of users.

...

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.

ResultSet sounds very RDBM oriented IMHO,

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 not -1 about this, I just find it a bit overkill. It'd also make it a bit more difficult to use from velocity (but may be the script service could hide the complexity).

...

...

I'm thinking about the users module as a very minimalistic proxy, a name, a pointer to the user profile (wherever it is, possibly external), possibly a method that allows to authenticate the user in the future.

...

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.

Come on Vincent :) do you really search persons by phone number or first name only ? I think mobile phones do a great job at helping to find persons: first name + last name with filtering and a good default ordering (it'd nice to order by last name). I like the approach for its simplicity. I wonder what the others think about this.

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

I understand that we need to be able to handle custom and complex use cases but I think the XObjects model is here for that. We need a module allowing to retrieve XObjects with matching/filtering on any field, I agree. I think we know enough what we need to manage our users to define a specific API, the rightsmanager API was allowing much more complex things but those capabilities haven't been used (Thomas stop me if I'm wrong). The current proposal will need additions but I don't think it is flawed by design, I'd say it is based on known needs.

Actually I think an important part of complex rightsmanager filtering capabilities are currently used by rights/users/groups UI.

But now only for first and last name actually, pretty sure there used to be some more columns at first.

...

...

...

About the generic search on objects it only fits with users stored in the wiki.

...

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?

Why would you ? If it is for maintenance the XWiki.XWikiUsers class page should provide the list but if you're looking for a user profile does it matter that it is stored in the local or the global wiki ?

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 <[email protected]> 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.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

-- Thomas Mortagne

On Fri, Sep 24, 2010 at 12:11 PM, Thomas Mortagne <[email protected]> wrote:

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()

I'd prefer to have this kind of API: UserResultSet getUsers(UserCriteria criteria, Range range) I'd prefer using the criterion terminology and even if limit and offset are criteria I think they don't fit very well in a UserCriteria. Related: our generic criteria could be moved to a component (xwiki-commons?).

- 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

Sounds good.

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

Well, it feels a bit to much to me to restrict the number of results in the request + allow streaming on the results. I'm not -1 though, it'd for sure be safe.

and: UserResultSet UserManager#getUsers(UserCriteria criteria)

See above.

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.

On Sep 24, 2010, at 5:01 PM, Anca Luca wrote:

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:

...

On Thu, Sep 23, 2010 at 6:27 PM, Vincent Massol<[email protected]> wrote:

...

On Sep 23, 2010, at 6:14 PM, Jean-Vincent Drean wrote:

...

...

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?

There are many open questions, I've kept the proposal minimalistic on purpose, it's only a starting point. Now from my PoV this module should not handle user management (CRUD), it should be a very generic proxy, for example we can imagine (long-term) an implementation using LDAP that doesn't even create a profile page within the wiki (thus avoiding sync problems).

Then DocumentReference in the User object is not correct... ;)

Indeed :)

+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).

...

...

...

About groups, I think they should be handled by the user module since they are just sets of users.

...

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.

ResultSet sounds very RDBM oriented IMHO,

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 not -1 about this, I just find it a bit overkill. It'd also make it a bit more difficult to use from velocity (but may be the script service could hide the complexity).

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.

...

...

...

I'm thinking about the users module as a very minimalistic proxy, a name, a pointer to the user profile (wherever it is, possibly external), possibly a method that allows to authenticate the user in the future.

...

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.

Come on Vincent :) do you really search persons by phone number or first name only ? I think mobile phones do a great job at helping to find persons: first name + last name with filtering and a good default ordering (it'd nice to order by last name). I like the approach for its simplicity. I wonder what the others think about this.

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.

...

...

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

I understand that we need to be able to handle custom and complex use cases but I think the XObjects model is here for that. We need a module allowing to retrieve XObjects with matching/filtering on any field, I agree. I think we know enough what we need to manage our users to define a specific API, the rightsmanager API was allowing much more complex things but those capabilities haven't been used (Thomas stop me if I'm wrong). The current proposal will need additions but I don't think it is flawed by design, I'd say it is based on known needs.

...

...

About the generic search on objects it only fits with users stored in the wiki.

...

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?

Why would you ? If it is for maintenance the XWiki.XWikiUsers class page should provide the list but if you're looking for a user profile does it matter that it is stored in the local or the global wiki ?

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).

I don't agreel with this approach. It's really bad from an architecture point of view for a lot of reasons. Let me just point out 2: 1) If the module is named xwiki-users then it's obvious it's about user mgmt in xwiki and not just handling a specific use case and letting other parts of xwiki handle other parts of xwiki user mgmt 2) if you expose the XWikiUsers class elsewhere then you're forbidding from introducing a different implementation and you're exposing internal details of implementation. I'm not questioning that JV wants something for his very specific use case. This is fine. I'm questioning JV's need with the introduction of what was presented as the XWiki Users management module. If it's just some "shortcuts" as you say then stuff it in xwiki-core with the user mgmt api there. If the xwiki users module is meant to be the XWiki Users Mgmt module then it needs more thoughts IMO. I'm again fine with a first impl like this one BUT it's definitely not good from an architecture POV and will be broken completely as soon as we start thinking globally about the architecture of such a module. If we agree with this I'm fine. Users should be warned to not use this api or risk being broken. Last comment: I don't have the feeling this user module proposal was thought out of the box, by going back to business needs. It seems it was thought out from a very specific use case POV. Thus it won't be able to address the general needs for sure and will need to evolve a lot in the future. Thanks -Vincent PS: I've not answered the other points above because I don't agree with them and I'm not sure what we are discussing here. It seems we're discussing 2 things mixed: - a temporary api just to satisfy one specific use case - a general xwiki users architecture

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 <[email protected]> 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 Mon, Sep 27, 2010 at 3:04 PM, Jean-Vincent Drean <[email protected]> wrote:

On Fri, Sep 24, 2010 at 5:37 PM, Vincent Massol <[email protected]> wrote:

...

1) If the module is named xwiki-users then it's obvious it's about user mgmt in xwiki and not just handling a specific use case and letting other parts of xwiki handle other parts of xwiki user mgmt 2) if you expose the XWikiUsers class elsewhere then you're forbidding from introducing a different implementation and you're exposing internal details of implementation.

I'm not questioning that JV wants something for his very specific use case. This is fine. I'm questioning JV's need with the introduction of what was presented as the XWiki Users management module. If it's just some "shortcuts"  as you say then stuff it in xwiki-core with the user mgmt api there.

If the xwiki users module is meant to be the XWiki Users Mgmt module then it needs more thoughts IMO. I'm again fine with a first impl like this one BUT it's definitely not good from an architecture POV and will be broken completely as soon as we start thinking globally about the architecture of such a module. If we agree with this I'm fine. Users should be warned to not use this api or risk being broken.

Last comment: I don't have the feeling this user module proposal was thought out of the box, by going back to business needs. It seems it was thought out from a very specific use case POV. Thus it won't be able to address the general needs for sure and will need to evolve a lot in the future.

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 ?

Update: http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule#HAPIproposal2

...

Thanks -Vincent

PS: I've not answered the other points above because I don't agree with them and I'm not sure what we are discussing here. It seems we're discussing 2 things mixed: - a temporary api just to satisfy one specific use case - a general xwiki users architecture

...

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 >> <[email protected]>  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.

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Tue, Sep 28, 2010 at 1:47 PM, Sergiu Dumitriu <[email protected]> wrote:

On 09/27/2010 05:14 PM, Jean-Vincent Drean wrote:

...

On Mon, Sep 27, 2010 at 3:04 PM, Jean-Vincent Drean <[email protected]>  wrote:

...

On Fri, Sep 24, 2010 at 5:37 PM, Vincent Massol<[email protected]>  wrote:

...

1) If the module is named xwiki-users then it's obvious it's about user mgmt in xwiki and not just handling a specific use case and letting other parts of xwiki handle other parts of xwiki user mgmt 2) if you expose the XWikiUsers class elsewhere then you're forbidding from introducing a different implementation and you're exposing internal details of implementation.

I'm not questioning that JV wants something for his very specific use case. This is fine. I'm questioning JV's need with the introduction of what was presented as the XWiki Users management module. If it's just some "shortcuts"  as you say then stuff it in xwiki-core with the user mgmt api there.

If the xwiki users module is meant to be the XWiki Users Mgmt module then it needs more thoughts IMO. I'm again fine with a first impl like this one BUT it's definitely not good from an architecture POV and will be broken completely as soon as we start thinking globally about the architecture of such a module. If we agree with this I'm fine. Users should be warned to not use this api or risk being broken.

Last comment: I don't have the feeling this user module proposal was thought out of the box, by going back to business needs. It seems it was thought out from a very specific use case POV. Thus it won't be able to address the general needs for sure and will need to evolve a lot in the future.

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 ?

Update: http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule#HAPIproposal2

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...

Quoting Thomas: "[snip] 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" I think the name field is a special field, I'd compare it to document display title, I also think that it is reasonable to have the ID and name fields in the User class. In the default implementation it is the concatenation of fname and lname (fallback on ID).

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?

The proposal is about providing a plain string (need more javadoc), then it's up to the implementation to decorate it if necessary. Side note: the current implementation handles a user cache, the db isn't queried directly, the module iterate over the list of users and perform the matching through String#contains.

On 09/28/2010 02:52 PM, Sergiu Dumitriu wrote:

On 09/28/2010 02:11 PM, Jean-Vincent Drean wrote:

...

On Tue, Sep 28, 2010 at 1:47 PM, Sergiu Dumitriu<[email protected]> wrote:

...

On 09/27/2010 05:14 PM, Jean-Vincent Drean wrote:

...

On Mon, Sep 27, 2010 at 3:04 PM, Jean-Vincent Drean <[email protected]> wrote:

...

On Fri, Sep 24, 2010 at 5:37 PM, Vincent Massol<[email protected]> wrote:

...

1) If the module is named xwiki-users then it's obvious it's about user mgmt in xwiki and not just handling a specific use case and letting other parts of xwiki handle other parts of xwiki user mgmt 2) if you expose the XWikiUsers class elsewhere then you're forbidding from introducing a different implementation and you're exposing internal details of implementation.

I'm not questioning that JV wants something for his very specific use case. This is fine. I'm questioning JV's need with the introduction of what was presented as the XWiki Users management module. If it's just some "shortcuts" as you say then stuff it in xwiki-core with the user mgmt api there.

If the xwiki users module is meant to be the XWiki Users Mgmt module then it needs more thoughts IMO. I'm again fine with a first impl like this one BUT it's definitely not good from an architecture POV and will be broken completely as soon as we start thinking globally about the architecture of such a module. If we agree with this I'm fine. Users should be warned to not use this api or risk being broken.

Last comment: I don't have the feeling this user module proposal was thought out of the box, by going back to business needs. It seems it was thought out from a very specific use case POV. Thus it won't be able to address the general needs for sure and will need to evolve a lot in the future.

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 ?

Update: http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule#HAPIproposal2

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...

Quoting Thomas: "[snip] 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"

I think the name field is a special field, I'd compare it to document display title, I also think that it is reasonable to have the ID and name fields in the User class. In the default implementation it is the concatenation of fname and lname (fallback on ID).

...

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?

The proposal is about providing a plain string (need more javadoc), then it's up to the implementation to decorate it if necessary. Side note: the current implementation handles a user cache, the db isn't queried directly, the module iterate over the list of users and perform the matching through String#contains.

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

Another one: order by? -- Sergiu Dumitriu http://purl.org/net/sergiu/

On Tue, Sep 28, 2010 at 2:52 PM, Sergiu Dumitriu <[email protected]> wrote:

...

I think the name field is a special field, I'd compare it to document display title, I also think that it is reasonable to have the ID and name fields in the User class. In the default implementation it is the concatenation of fname and lname (fallback on ID).

...

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?

The proposal is about providing a plain string (need more javadoc), then it's up to the implementation to decorate it if necessary. Side note: the current implementation handles a user cache, the db isn't queried directly, the module iterate over the list of users and perform the matching through String#contains.

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

It filters on "name", it's up to the implementation to fill that one. In the default implementation it is the concatenation of fname and lname (fallback on ID, which is the document fully qualified named, if none filled). Thanks, JV.

http://dev.xwiki.org/xwiki/bin/view/Design/UserModuleRequirements On 05/02/2011 01:00 AM, Sergiu Dumitriu wrote:

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/34a0f83c354ac68eca75c7141133f...

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:

...

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 ?

-- Sergiu Dumitriu http://purl.org/net/sergiu/