24 Sep
2010
24 Sep
'10
8:40 a.m.
On Thu, Sep 23, 2010 at 21:51, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
There's a notion of local and global wiki pages, but should it matter
for user management ?
--
Thomas Mortagne
--
Thomas Mortagne
On Thu, Sep 23, 2010 at 21:23, Jean-Vincent Drean
<jean-vincent(a)drean.org> wrote:
But now only for first and last name actually, pretty sure there used
to be some more columns at first.
On Thu, Sep 23, 2010 at 6:27 PM, Vincent Massol
<vincent(a)massol.net> wrote:
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 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.
On Sep 23, 2010, at 6:14 PM, Jean-Vincent Drean wrote:
Indeed :)
> 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... ;) 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
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. 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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> 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
>> <jean-vincent(a)drean.org> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs