I see, I think I have bit of an idea of what you try to do. So actually when a user adds a new *contact* by adding for example an external invitee to a meeting that he creates through the calendar, you would add a new entry to the table *users* ? Is that right ? So there would be no more table *user_contacts* as every contact is internal / a record in the user table in the future ?
I think in theory the idea is right. Practically I have done something like that in other projects, the basic complexity here is around duplicates. How do you make sure that the same user is really the linked everywhere. Or what happens if two users add the same contact, but one user decides that this contact now has another firstname. If they all reference the same user-record the other users that have this contact might not like that change. But I am still not really sure what your changes will really mean practically. For example what do you mean by: *"user related" objects to rely on user_id only* => Which user related object currently don't rely on the user_id ? Seb 2013/5/29 Maxim Solodovnik <[email protected]> > Hello Sebastian, > > Actually adding this one field and make all "user related" objects to rely > on user_id only will do a lot. > > copy: > 1) Invitations: invitedname, invitedEMail, omTimeZone > 2) MeetingMember: firstname, lastname, email, phone, omTimeZone > 3) ChatMessage: fromEmail, fromName, toEmail, toName > 4) RemoteSessionObject: all fields //most probably should not be changed > .... maybe more > > 2) Currently there is no place to store "contacts". Only OM users are > searchable. Users would like to have sort of Address Book with both OM > users and "externals" > > 3) I mean something like following: (currently implemented in Gmail) > user starts typing name/email -> system proposes autocompletion > user selects from the list -> system draws "dragable address" > user double-click "dragable address" -> system allows user to modify > fields: first/last/display name/email > > so it is not necessary to "Create contact" for the user, it is created as > soon as email address is entered and it is editable inline (quick and > easy). > > I believe all this dialogs and multistep wizards should be used only if > there is no way to avoid it .... > > > > On Wed, May 29, 2013 at 11:19 AM, [email protected] < > [email protected]> wrote: > > > 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 <[email protected]> > > > > > 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 > > [email protected] > > > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
