>> external invitee to a meeting that he creates through the calendar, you >> would add a new entry to the table *users* ? >> Is that right ? Yes this was my idea :)
I believe user_contacts might be necessary if we would like to have "request contact" feature (might be useful to see contact details hidden by default) >> How do you make sure that the same user is really the linked everywhere. What I actually want is to have user_id in _ALL_ places where I need user (for ex. Invitations, MeetingMember, ChatMessage etc.) >> what happens if two users add the same contact, but one user decides that this contact now has another firstname In case "contact" added is internal user editing of first/lastnam will not be available In case "contact" added is external email address Every user will actually create its own record in *users* table. They will differs by pair (email, creator_id) >> Which user related object currently don't rely on the user_id ? at least Invitations, MeetingMember, ChatMessage. Additionally: While creating Appointment in calendar we should choose from 2 different lists. Currently it is impossible, from my point of view, to create address book. On Wed, May 29, 2013 at 1:41 PM, [email protected] < [email protected]> wrote: > 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] > -- WBR Maxim aka solomax
