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]
