Hello Sebastian, sorry for the late reply (been busy)
I'm afraid UserContact entity should not be removed since currently it is used for implementing "in-system" messages My idea was: 1) add "type" to the user table 2) remove copied fields from MeetingMember, ChatMessage and later from Invitations I currently need to implement calendar appointment attendees list and improve chat messages structure I'll double check backup import after these changes will be implemented. On Wed, May 29, 2013 at 5:03 PM, [email protected] < [email protected]> wrote: > Hm, > > the backup should be always backwards compatible. I would rather prefer to > really convert the old schema to the new one. > It might be possible to include in the XML file of the export a version > attribute. > > Depending on what version the XML has you can either do the one style of > import (3.0 and later) or the other (2.x and older). > From an end user perspective this change is actually internal and > architectural. > And just because of such a change having no support for an export/import is > rather drastic. > And I think there should be a technical solution of solving this rather > then removing some feature. > > So to sum those changes up: > - Entity UserContact will be deleted and instead for each record of the > UserContact there will be a record in the user table with type=contact > - users with type=contact cannot login to the frontend > - Exports from now one have not user contacts anymore and there is some > kind of mechanism to make sure that the old backups that have such a record > are successfully merged to the new design. > > (Btw: As far as I can see the Backup currently throws and exceptions with > 3.0: > DEBUG 05-29 22:00:31.680 RequestCycle.java 418245 216 > org.apache.wicket.request.cycle.RequestCycle [http-bio-0.0.0.0-5080-exec-4] > - No suitable handler found for URL > > BackupExport?moduleName=backup&sid=9a196aa0fc9459ffcf028fdbb5751e67&includeFileOption=no, > falling back to container to process this request > ) > > I think the entire Invitation thing should go into a second discussion / > later phase. It will be simply to complex now. And with all the changes > planned to HTML5 the entire effort of reworking the Flash application to > this new design might be done a second time again. Cause linking the > invitationHash to a user record and correctly login in that user everytime > is not something that can be done on Java side only. > > We could discuss if those changes will be incorporated in the Flash part. > Cause if we decide to do all changes only in the HTML5 Calendar and > PrivateMessages ... there is no complete package of Openmeetings 3.0 unless > those parts are refactored to HTML5. > What is the planning for those components? Is it realistic that we will be > able to do those changes _and_ do a HTML5 refactoring at the same time? > What is your motivation for doing that change now? > > Sebastian > > > > > > > > > > 2013/5/29 Maxim Solodovnik <[email protected]> > > > good questions :) > > > > Backup should be handled somehow ... (As intermediate solutions we can do > > the following: leave old fields+getters/setters for 1-2 next versions and > > handle *contacts* creation while import, then remove it completely with > > declaring minimum import version like 3.0.0) > > According to the invitations: I was thinking of the following process: > > 1) user sending invitation (in 3.1.0 most probably) to the email first > time > > 2) this email is searched in *users* db and not found, new user of type > > "contact" is created > > 3) user sending invitation to the same email > > 4) this email is searched in *users* db and found, user get autocomplete > > option, no new "contact" is created, user gets the ability to add > > first/lastname etc. to the contact > > > > > > On Wed, May 29, 2013 at 3:24 PM, [email protected] < > > [email protected]> wrote: > > > > > Hm, > > > > > > yes I think it makes sense, the user contacts could be really a user > > record > > > instead of a record in the user_contacts table. > > > > > > *Currently it is impossible, from my point of view, to create address > > > book.* > > > Well you can simply write a native SQL query that maps those tables and > > > read the results into a generic SearchResult object. > > > However, you are right, if you say that there is no way you could do > that > > > with JPQL. > > > > > > What exactly is affected by the change of the user_contacts to user > > > records? > > > Calendar and private messages? Is that all? > > > Have you thought about how old backups will convert to this new design > > > their data (I think there will be multiple ways to do this, but it > might > > be > > > easier to design the solution if we discuss it upfront)? > > > > > > What other changes, apart from the user_contacts to user record are > > planned > > > as part of this change? > > > Will a new invitation also create a new user for every invitation? Is > > that > > > user created when the invitation hash is created on when the user > enters > > > the room? What happens if you send multiple invitations to the same > > email, > > > will there be a new user for every of those invitations or will they be > > > mapped to the same? > > > > > > Sebastian > > > > > > > > > 2013/5/29 Maxim Solodovnik <[email protected]> > > > > > > > >> 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 > > > > > > > > > > > > > > > > -- > > > 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
