Hi Maxim,
I am not sure if I do understand that proposal.
In what sense does this affect what we currently have? From what I
understood this is only one more additional column in the user table that
does indicate how this user was created.
But for instance users that enter a conference room via a invitations link
(hash method) still don't get an entry in the users table, right?
So in what sense does this affect anything that exists so far?
*pros:
1) everything working with "user" can rely on user_id only, no need to copy
any data fields *
=> Where do we currently copy any fields ?
*2) all fields requires entering of user can be enhanced with autocomplete
and inline edit (so user can enter as much info as he/she is ready at the
moment)*
=> What prevents you from doing this currently ?
*3) add/edit user of type contact anytime user enters email not-registered
in the system*
=> Sorry I don't understand this at all. A user of type contact ... how is
that user to be logged in in at all? In your description you write that
only users of type "user" can login.
Thanks,
Sebastian
2013/5/29 Maxim Solodovnik <solomax...@gmail.com>
> Hello All,
>
> I would like to propose to change the way OM works with users.
> Currently we have 3 entities acts like "User":
> 1) OM user (the entity created using OM Admin)
> 2) External user (the entity created via SOAP/REST call, actually it is
> normal user with externalType/externalId set)
> 3) "hash" user ("something" created while sending invitation hash or
> inviting external user via calendar)
>
> What I would like to propose:
> 1) add `type` column to the User table (see [1])
> 2) allow front-end login for *type == user* only (ldap users will be
> allowed to login only id LDAP is selected)
> 3) add/edit user of type contact anytime user enters email not-registered
> in the system
> 4) add user created to one of the groups of the user created this contact
>
> pros:
> 1) everything working with "user" can rely on user_id only, no need to copy
> any data fields
> 2) all fields requires entering of user can be enhanced with autocomplete
> and inline edit (so user can enter as much info as he/she is ready at the
> moment)
> 3) drag-n-drop should be added to various OM components to be able to
> implement address book
> 4) Single component acting as address book can easily be added
>
>
> cons:
> 1) to avoid naming conflicts and personal contact lists sharing
> searching/autocompleting of the contacts should be done with strict
> filtering by creator/owner id
>
> [1] enum Type {
> user
> , ldap //should we add it???
> , external
> , contact
> }
>
> Please let me know if you have any concerns regarding this
>
> --
> WBR
> Maxim aka solomax
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
