You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Maxim Solodovnik <so...@gmail.com> on 2013/06/01 18:42:24 UTC
Re: [DISCUSS] OM user architectural changes
Sorry I seems to miss the major questions :(
I'm currently implementing PrivateMessages, and I need these changes to be
able to implement Calendar appointment attendees more straightforward way.
I would like to avoid creating 2 types of attendees as well as simplify
work with chat messages.
I'm not sure if these changes should be backported to flash version :(
I would prefer to disable all flash functionality (except for room)
not sure if it is possible since we currently have login type "dashboard"
I'll try to finish Calendar and Private Messages before 2013.06.12.
Current issues are:
1) minor: room invitation link is wrong (probably calendar link also wrong)
2) Calendar Appointment attendees (not yet implemented)
3) Messages and Contacts area (currently implemented)
4) WYSIWYG editor for the calendar and chat (is on its way)
Open questions:
1) should we rewrite our hashes to use HTML5 or let it be handled by Flash
until 3.1?
?????
On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik <so...@gmail.com>wrote:
> 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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 <so...@gmail.com>
>>
>> > 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, seba.wagner@gmail.com <
>> > seba.wagner@gmail.com> 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 <so...@gmail.com>
>> > >
>> > > > >> 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, seba.wagner@gmail.com <
>> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
>> > > > >
>> > > > > > 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, seba.wagner@gmail.com <
>> > > > > > seba.wagner@gmail.com> 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 <so...@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.wagner@gmail.com
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > WBR
>> > > > > > Maxim aka solomax
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Sebastian Wagner
>> > > > > https://twitter.com/#!/dead_lock
>> > > > > http://www.webbase-design.de
>> > > > > http://www.wagner-sebastian.com
>> > > > > seba.wagner@gmail.com
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > WBR
>> > > > Maxim aka solomax
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Sebastian Wagner
>> > > https://twitter.com/#!/dead_lock
>> > > http://www.webbase-design.de
>> > > http://www.wagner-sebastian.com
>> > > seba.wagner@gmail.com
>> > >
>> >
>> >
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>> >
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: [DISCUSS] OM user architectural changes
Posted by Maxim Solodovnik <so...@gmail.com>.
Wicket have modules to auth via 3rd party services shouldn't be a problem
On Mon, Jun 3, 2013 at 9:48 PM, Alexei Fedotov <al...@gmail.com>wrote:
> Maxim,
> this don't seem a big architectural change for me, and I see no concerns. I
> may be mistaken. And of course we should have a linkedin/twitter/facebook
> user at some point.
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
>
> On Sun, Jun 2, 2013 at 4:30 PM, Maxim Solodovnik <solomax666@gmail.com
> >wrote:
>
> > OK :)
> > I would vote for unifing hash, but this can be postponed :)
> > On Jun 2, 2013 3:26 PM, "seba.wagner@gmail.com" <se...@gmail.com>
> > wrote:
> >
> > > Yes we might transfer the hash from the client to the server.
> > > But this is really not doing anything with the hash, its just proxying
> > data
> > > ... for whatever reasons. It could be refactored so that the servlet
> > takes
> > > the hash direclty. But the business logic that calculates if the hash
> is
> > > valid, invalides it et cetera, this entire logic is already on Server
> > side
> > > in Java. I guess we can re-use that all, just the input and output of
> > those
> > > methods might be different for Wicket.
> > >
> > > Sebastian
> > >
> > >
> > > 2013/6/2 Maxim Solodovnik <so...@gmail.com>
> > >
> > > > Currently we get hash in flash client, then pass it to server.
> > > > I believe in later versions it should be changed to be handled by
> > wicket
> > > > (3.1+)
> > > > On Jun 2, 2013 2:02 PM, "seba.wagner@gmail.com" <
> seba.wagner@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Maxim,
> > > > >
> > > > > I will try to answer your points more detailed,
> > > > > But just about the Hash thing:
> > > > > I think the Hash is mainly handled on server side and that logic is
> > > > pretty
> > > > > fine as it is.
> > > > > The question is just how much of it needs to be implemented in
> Wicket
> > > for
> > > > > the Html5 client.
> > > > >
> > > > > Seb
> > > > > Am 02.06.2013 04:42 schrieb "Maxim Solodovnik" <
> solomax666@gmail.com
> > >:
> > > > >
> > > > > > Sorry I seems to miss the major questions :(
> > > > > >
> > > > > > I'm currently implementing PrivateMessages, and I need these
> > changes
> > > to
> > > > > be
> > > > > > able to implement Calendar appointment attendees more
> > straightforward
> > > > > way.
> > > > > > I would like to avoid creating 2 types of attendees as well as
> > > simplify
> > > > > > work with chat messages.
> > > > > >
> > > > > > I'm not sure if these changes should be backported to flash
> version
> > > :(
> > > > > > I would prefer to disable all flash functionality (except for
> room)
> > > > > > not sure if it is possible since we currently have login type
> > > > "dashboard"
> > > > > >
> > > > > > I'll try to finish Calendar and Private Messages before
> 2013.06.12.
> > > > > >
> > > > > > Current issues are:
> > > > > > 1) minor: room invitation link is wrong (probably calendar link
> > also
> > > > > wrong)
> > > > > > 2) Calendar Appointment attendees (not yet implemented)
> > > > > > 3) Messages and Contacts area (currently implemented)
> > > > > > 4) WYSIWYG editor for the calendar and chat (is on its way)
> > > > > >
> > > > > > Open questions:
> > > > > > 1) should we rewrite our hashes to use HTML5 or let it be handled
> > by
> > > > > Flash
> > > > > > until 3.1?
> > > > > > ?????
> > > > > >
> > > > > >
> > > > > > On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik <
> > > > solomax666@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > 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, seba.wagner@gmail.com <
> > > > > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > > > >>
> > > > > > >> > 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, seba.wagner@gmail.com <
> > > > > > >> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > > > >> > >
> > > > > > >> > > > >> 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, seba.wagner@gmail.com<
> > > > > > >> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > > > >> > > > >
> > > > > > >> > > > > > 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,
> > seba.wagner@gmail.com<
> > > > > > >> > > > > > seba.wagner@gmail.com> 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 <so...@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.wagner@gmail.com
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > --
> > > > > > >> > > > > > WBR
> > > > > > >> > > > > > Maxim aka solomax
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > > > --
> > > > > > >> > > > > Sebastian Wagner
> > > > > > >> > > > > https://twitter.com/#!/dead_lock
> > > > > > >> > > > > http://www.webbase-design.de
> > > > > > >> > > > > http://www.wagner-sebastian.com
> > > > > > >> > > > > seba.wagner@gmail.com
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > --
> > > > > > >> > > > WBR
> > > > > > >> > > > Maxim aka solomax
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > --
> > > > > > >> > > Sebastian Wagner
> > > > > > >> > > https://twitter.com/#!/dead_lock
> > > > > > >> > > http://www.webbase-design.de
> > > > > > >> > > http://www.wagner-sebastian.com
> > > > > > >> > > seba.wagner@gmail.com
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > --
> > > > > > >> > WBR
> > > > > > >> > Maxim aka solomax
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Sebastian Wagner
> > > > > > >> https://twitter.com/#!/dead_lock
> > > > > > >> http://www.webbase-design.de
> > > > > > >> http://www.wagner-sebastian.com
> > > > > > >> seba.wagner@gmail.com
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > WBR
> > > > > > > Maxim aka solomax
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > WBR
> > > > > > Maxim aka solomax
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sebastian Wagner
> > > https://twitter.com/#!/dead_lock
> > > http://www.webbase-design.de
> > > http://www.wagner-sebastian.com
> > > seba.wagner@gmail.com
> > >
> >
>
--
WBR
Maxim aka solomax
Re: [DISCUSS] OM user architectural changes
Posted by Alexei Fedotov <al...@gmail.com>.
Maxim,
this don't seem a big architectural change for me, and I see no concerns. I
may be mistaken. And of course we should have a linkedin/twitter/facebook
user at some point.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Sun, Jun 2, 2013 at 4:30 PM, Maxim Solodovnik <so...@gmail.com>wrote:
> OK :)
> I would vote for unifing hash, but this can be postponed :)
> On Jun 2, 2013 3:26 PM, "seba.wagner@gmail.com" <se...@gmail.com>
> wrote:
>
> > Yes we might transfer the hash from the client to the server.
> > But this is really not doing anything with the hash, its just proxying
> data
> > ... for whatever reasons. It could be refactored so that the servlet
> takes
> > the hash direclty. But the business logic that calculates if the hash is
> > valid, invalides it et cetera, this entire logic is already on Server
> side
> > in Java. I guess we can re-use that all, just the input and output of
> those
> > methods might be different for Wicket.
> >
> > Sebastian
> >
> >
> > 2013/6/2 Maxim Solodovnik <so...@gmail.com>
> >
> > > Currently we get hash in flash client, then pass it to server.
> > > I believe in later versions it should be changed to be handled by
> wicket
> > > (3.1+)
> > > On Jun 2, 2013 2:02 PM, "seba.wagner@gmail.com" <seba.wagner@gmail.com
> >
> > > wrote:
> > >
> > > > Hi Maxim,
> > > >
> > > > I will try to answer your points more detailed,
> > > > But just about the Hash thing:
> > > > I think the Hash is mainly handled on server side and that logic is
> > > pretty
> > > > fine as it is.
> > > > The question is just how much of it needs to be implemented in Wicket
> > for
> > > > the Html5 client.
> > > >
> > > > Seb
> > > > Am 02.06.2013 04:42 schrieb "Maxim Solodovnik" <solomax666@gmail.com
> >:
> > > >
> > > > > Sorry I seems to miss the major questions :(
> > > > >
> > > > > I'm currently implementing PrivateMessages, and I need these
> changes
> > to
> > > > be
> > > > > able to implement Calendar appointment attendees more
> straightforward
> > > > way.
> > > > > I would like to avoid creating 2 types of attendees as well as
> > simplify
> > > > > work with chat messages.
> > > > >
> > > > > I'm not sure if these changes should be backported to flash version
> > :(
> > > > > I would prefer to disable all flash functionality (except for room)
> > > > > not sure if it is possible since we currently have login type
> > > "dashboard"
> > > > >
> > > > > I'll try to finish Calendar and Private Messages before 2013.06.12.
> > > > >
> > > > > Current issues are:
> > > > > 1) minor: room invitation link is wrong (probably calendar link
> also
> > > > wrong)
> > > > > 2) Calendar Appointment attendees (not yet implemented)
> > > > > 3) Messages and Contacts area (currently implemented)
> > > > > 4) WYSIWYG editor for the calendar and chat (is on its way)
> > > > >
> > > > > Open questions:
> > > > > 1) should we rewrite our hashes to use HTML5 or let it be handled
> by
> > > > Flash
> > > > > until 3.1?
> > > > > ?????
> > > > >
> > > > >
> > > > > On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik <
> > > solomax666@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > 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, seba.wagner@gmail.com <
> > > > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > > >>
> > > > > >> > 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, seba.wagner@gmail.com <
> > > > > >> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > > >> > >
> > > > > >> > > > >> 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, seba.wagner@gmail.com <
> > > > > >> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > > >> > > > >
> > > > > >> > > > > > 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,
> seba.wagner@gmail.com<
> > > > > >> > > > > > seba.wagner@gmail.com> 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 <so...@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.wagner@gmail.com
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > --
> > > > > >> > > > > > WBR
> > > > > >> > > > > > Maxim aka solomax
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > --
> > > > > >> > > > > Sebastian Wagner
> > > > > >> > > > > https://twitter.com/#!/dead_lock
> > > > > >> > > > > http://www.webbase-design.de
> > > > > >> > > > > http://www.wagner-sebastian.com
> > > > > >> > > > > seba.wagner@gmail.com
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > --
> > > > > >> > > > WBR
> > > > > >> > > > Maxim aka solomax
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > > Sebastian Wagner
> > > > > >> > > https://twitter.com/#!/dead_lock
> > > > > >> > > http://www.webbase-design.de
> > > > > >> > > http://www.wagner-sebastian.com
> > > > > >> > > seba.wagner@gmail.com
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > WBR
> > > > > >> > Maxim aka solomax
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Sebastian Wagner
> > > > > >> https://twitter.com/#!/dead_lock
> > > > > >> http://www.webbase-design.de
> > > > > >> http://www.wagner-sebastian.com
> > > > > >> seba.wagner@gmail.com
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > WBR
> > > > > > Maxim aka solomax
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > WBR
> > > > > Maxim aka solomax
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
> >
>
Re: [DISCUSS] OM user architectural changes
Posted by Maxim Solodovnik <so...@gmail.com>.
OK :)
I would vote for unifing hash, but this can be postponed :)
On Jun 2, 2013 3:26 PM, "seba.wagner@gmail.com" <se...@gmail.com>
wrote:
> Yes we might transfer the hash from the client to the server.
> But this is really not doing anything with the hash, its just proxying data
> ... for whatever reasons. It could be refactored so that the servlet takes
> the hash direclty. But the business logic that calculates if the hash is
> valid, invalides it et cetera, this entire logic is already on Server side
> in Java. I guess we can re-use that all, just the input and output of those
> methods might be different for Wicket.
>
> Sebastian
>
>
> 2013/6/2 Maxim Solodovnik <so...@gmail.com>
>
> > Currently we get hash in flash client, then pass it to server.
> > I believe in later versions it should be changed to be handled by wicket
> > (3.1+)
> > On Jun 2, 2013 2:02 PM, "seba.wagner@gmail.com" <se...@gmail.com>
> > wrote:
> >
> > > Hi Maxim,
> > >
> > > I will try to answer your points more detailed,
> > > But just about the Hash thing:
> > > I think the Hash is mainly handled on server side and that logic is
> > pretty
> > > fine as it is.
> > > The question is just how much of it needs to be implemented in Wicket
> for
> > > the Html5 client.
> > >
> > > Seb
> > > Am 02.06.2013 04:42 schrieb "Maxim Solodovnik" <so...@gmail.com>:
> > >
> > > > Sorry I seems to miss the major questions :(
> > > >
> > > > I'm currently implementing PrivateMessages, and I need these changes
> to
> > > be
> > > > able to implement Calendar appointment attendees more straightforward
> > > way.
> > > > I would like to avoid creating 2 types of attendees as well as
> simplify
> > > > work with chat messages.
> > > >
> > > > I'm not sure if these changes should be backported to flash version
> :(
> > > > I would prefer to disable all flash functionality (except for room)
> > > > not sure if it is possible since we currently have login type
> > "dashboard"
> > > >
> > > > I'll try to finish Calendar and Private Messages before 2013.06.12.
> > > >
> > > > Current issues are:
> > > > 1) minor: room invitation link is wrong (probably calendar link also
> > > wrong)
> > > > 2) Calendar Appointment attendees (not yet implemented)
> > > > 3) Messages and Contacts area (currently implemented)
> > > > 4) WYSIWYG editor for the calendar and chat (is on its way)
> > > >
> > > > Open questions:
> > > > 1) should we rewrite our hashes to use HTML5 or let it be handled by
> > > Flash
> > > > until 3.1?
> > > > ?????
> > > >
> > > >
> > > > On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik <
> > solomax666@gmail.com
> > > > >wrote:
> > > >
> > > > > 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, seba.wagner@gmail.com <
> > > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > >>
> > > > >> > 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, seba.wagner@gmail.com <
> > > > >> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > >> > >
> > > > >> > > > >> 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, seba.wagner@gmail.com <
> > > > >> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > > >> > > > >
> > > > >> > > > > > 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, seba.wagner@gmail.com<
> > > > >> > > > > > seba.wagner@gmail.com> 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 <so...@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.wagner@gmail.com
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > --
> > > > >> > > > > > WBR
> > > > >> > > > > > Maxim aka solomax
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > --
> > > > >> > > > > Sebastian Wagner
> > > > >> > > > > https://twitter.com/#!/dead_lock
> > > > >> > > > > http://www.webbase-design.de
> > > > >> > > > > http://www.wagner-sebastian.com
> > > > >> > > > > seba.wagner@gmail.com
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > --
> > > > >> > > > WBR
> > > > >> > > > Maxim aka solomax
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > > Sebastian Wagner
> > > > >> > > https://twitter.com/#!/dead_lock
> > > > >> > > http://www.webbase-design.de
> > > > >> > > http://www.wagner-sebastian.com
> > > > >> > > seba.wagner@gmail.com
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > WBR
> > > > >> > Maxim aka solomax
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Sebastian Wagner
> > > > >> https://twitter.com/#!/dead_lock
> > > > >> http://www.webbase-design.de
> > > > >> http://www.wagner-sebastian.com
> > > > >> seba.wagner@gmail.com
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > WBR
> > > > > Maxim aka solomax
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
> >
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
Re: [DISCUSS] OM user architectural changes
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Yes we might transfer the hash from the client to the server.
But this is really not doing anything with the hash, its just proxying data
... for whatever reasons. It could be refactored so that the servlet takes
the hash direclty. But the business logic that calculates if the hash is
valid, invalides it et cetera, this entire logic is already on Server side
in Java. I guess we can re-use that all, just the input and output of those
methods might be different for Wicket.
Sebastian
2013/6/2 Maxim Solodovnik <so...@gmail.com>
> Currently we get hash in flash client, then pass it to server.
> I believe in later versions it should be changed to be handled by wicket
> (3.1+)
> On Jun 2, 2013 2:02 PM, "seba.wagner@gmail.com" <se...@gmail.com>
> wrote:
>
> > Hi Maxim,
> >
> > I will try to answer your points more detailed,
> > But just about the Hash thing:
> > I think the Hash is mainly handled on server side and that logic is
> pretty
> > fine as it is.
> > The question is just how much of it needs to be implemented in Wicket for
> > the Html5 client.
> >
> > Seb
> > Am 02.06.2013 04:42 schrieb "Maxim Solodovnik" <so...@gmail.com>:
> >
> > > Sorry I seems to miss the major questions :(
> > >
> > > I'm currently implementing PrivateMessages, and I need these changes to
> > be
> > > able to implement Calendar appointment attendees more straightforward
> > way.
> > > I would like to avoid creating 2 types of attendees as well as simplify
> > > work with chat messages.
> > >
> > > I'm not sure if these changes should be backported to flash version :(
> > > I would prefer to disable all flash functionality (except for room)
> > > not sure if it is possible since we currently have login type
> "dashboard"
> > >
> > > I'll try to finish Calendar and Private Messages before 2013.06.12.
> > >
> > > Current issues are:
> > > 1) minor: room invitation link is wrong (probably calendar link also
> > wrong)
> > > 2) Calendar Appointment attendees (not yet implemented)
> > > 3) Messages and Contacts area (currently implemented)
> > > 4) WYSIWYG editor for the calendar and chat (is on its way)
> > >
> > > Open questions:
> > > 1) should we rewrite our hashes to use HTML5 or let it be handled by
> > Flash
> > > until 3.1?
> > > ?????
> > >
> > >
> > > On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik <
> solomax666@gmail.com
> > > >wrote:
> > >
> > > > 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, seba.wagner@gmail.com <
> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > >>
> > > >> > 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, seba.wagner@gmail.com <
> > > >> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > >> > >
> > > >> > > > >> 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, seba.wagner@gmail.com <
> > > >> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > > >> > > > >
> > > >> > > > > > 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, seba.wagner@gmail.com <
> > > >> > > > > > seba.wagner@gmail.com> 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 <so...@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.wagner@gmail.com
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > --
> > > >> > > > > > WBR
> > > >> > > > > > Maxim aka solomax
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > --
> > > >> > > > > Sebastian Wagner
> > > >> > > > > https://twitter.com/#!/dead_lock
> > > >> > > > > http://www.webbase-design.de
> > > >> > > > > http://www.wagner-sebastian.com
> > > >> > > > > seba.wagner@gmail.com
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > WBR
> > > >> > > > Maxim aka solomax
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Sebastian Wagner
> > > >> > > https://twitter.com/#!/dead_lock
> > > >> > > http://www.webbase-design.de
> > > >> > > http://www.wagner-sebastian.com
> > > >> > > seba.wagner@gmail.com
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > WBR
> > > >> > Maxim aka solomax
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Sebastian Wagner
> > > >> https://twitter.com/#!/dead_lock
> > > >> http://www.webbase-design.de
> > > >> http://www.wagner-sebastian.com
> > > >> seba.wagner@gmail.com
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: [DISCUSS] OM user architectural changes
Posted by Maxim Solodovnik <so...@gmail.com>.
Currently we get hash in flash client, then pass it to server.
I believe in later versions it should be changed to be handled by wicket
(3.1+)
On Jun 2, 2013 2:02 PM, "seba.wagner@gmail.com" <se...@gmail.com>
wrote:
> Hi Maxim,
>
> I will try to answer your points more detailed,
> But just about the Hash thing:
> I think the Hash is mainly handled on server side and that logic is pretty
> fine as it is.
> The question is just how much of it needs to be implemented in Wicket for
> the Html5 client.
>
> Seb
> Am 02.06.2013 04:42 schrieb "Maxim Solodovnik" <so...@gmail.com>:
>
> > Sorry I seems to miss the major questions :(
> >
> > I'm currently implementing PrivateMessages, and I need these changes to
> be
> > able to implement Calendar appointment attendees more straightforward
> way.
> > I would like to avoid creating 2 types of attendees as well as simplify
> > work with chat messages.
> >
> > I'm not sure if these changes should be backported to flash version :(
> > I would prefer to disable all flash functionality (except for room)
> > not sure if it is possible since we currently have login type "dashboard"
> >
> > I'll try to finish Calendar and Private Messages before 2013.06.12.
> >
> > Current issues are:
> > 1) minor: room invitation link is wrong (probably calendar link also
> wrong)
> > 2) Calendar Appointment attendees (not yet implemented)
> > 3) Messages and Contacts area (currently implemented)
> > 4) WYSIWYG editor for the calendar and chat (is on its way)
> >
> > Open questions:
> > 1) should we rewrite our hashes to use HTML5 or let it be handled by
> Flash
> > until 3.1?
> > ?????
> >
> >
> > On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik <solomax666@gmail.com
> > >wrote:
> >
> > > 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, seba.wagner@gmail.com <
> > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > >>
> > >> > 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, seba.wagner@gmail.com <
> > >> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > >> > >
> > >> > > > >> 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, seba.wagner@gmail.com <
> > >> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> > >> > > > >
> > >> > > > > > 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, seba.wagner@gmail.com <
> > >> > > > > > seba.wagner@gmail.com> 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 <so...@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.wagner@gmail.com
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > --
> > >> > > > > > WBR
> > >> > > > > > Maxim aka solomax
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > --
> > >> > > > > Sebastian Wagner
> > >> > > > > https://twitter.com/#!/dead_lock
> > >> > > > > http://www.webbase-design.de
> > >> > > > > http://www.wagner-sebastian.com
> > >> > > > > seba.wagner@gmail.com
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > WBR
> > >> > > > Maxim aka solomax
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Sebastian Wagner
> > >> > > https://twitter.com/#!/dead_lock
> > >> > > http://www.webbase-design.de
> > >> > > http://www.wagner-sebastian.com
> > >> > > seba.wagner@gmail.com
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > WBR
> > >> > Maxim aka solomax
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Sebastian Wagner
> > >> https://twitter.com/#!/dead_lock
> > >> http://www.webbase-design.de
> > >> http://www.wagner-sebastian.com
> > >> seba.wagner@gmail.com
> > >>
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
Re: [DISCUSS] OM user architectural changes
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Hi Maxim,
I will try to answer your points more detailed,
But just about the Hash thing:
I think the Hash is mainly handled on server side and that logic is pretty
fine as it is.
The question is just how much of it needs to be implemented in Wicket for
the Html5 client.
Seb
Am 02.06.2013 04:42 schrieb "Maxim Solodovnik" <so...@gmail.com>:
> Sorry I seems to miss the major questions :(
>
> I'm currently implementing PrivateMessages, and I need these changes to be
> able to implement Calendar appointment attendees more straightforward way.
> I would like to avoid creating 2 types of attendees as well as simplify
> work with chat messages.
>
> I'm not sure if these changes should be backported to flash version :(
> I would prefer to disable all flash functionality (except for room)
> not sure if it is possible since we currently have login type "dashboard"
>
> I'll try to finish Calendar and Private Messages before 2013.06.12.
>
> Current issues are:
> 1) minor: room invitation link is wrong (probably calendar link also wrong)
> 2) Calendar Appointment attendees (not yet implemented)
> 3) Messages and Contacts area (currently implemented)
> 4) WYSIWYG editor for the calendar and chat (is on its way)
>
> Open questions:
> 1) should we rewrite our hashes to use HTML5 or let it be handled by Flash
> until 3.1?
> ?????
>
>
> On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik <solomax666@gmail.com
> >wrote:
>
> > 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, seba.wagner@gmail.com <
> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> >>
> >> > 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, seba.wagner@gmail.com <
> >> > seba.wagner@gmail.com> 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 <so...@gmail.com>
> >> > >
> >> > > > >> 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, seba.wagner@gmail.com <
> >> > > > seba.wagner@gmail.com> 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 <so...@gmail.com>
> >> > > > >
> >> > > > > > 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, seba.wagner@gmail.com <
> >> > > > > > seba.wagner@gmail.com> 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 <so...@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.wagner@gmail.com
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > WBR
> >> > > > > > Maxim aka solomax
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Sebastian Wagner
> >> > > > > https://twitter.com/#!/dead_lock
> >> > > > > http://www.webbase-design.de
> >> > > > > http://www.wagner-sebastian.com
> >> > > > > seba.wagner@gmail.com
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > WBR
> >> > > > Maxim aka solomax
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Sebastian Wagner
> >> > > https://twitter.com/#!/dead_lock
> >> > > http://www.webbase-design.de
> >> > > http://www.wagner-sebastian.com
> >> > > seba.wagner@gmail.com
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > WBR
> >> > Maxim aka solomax
> >> >
> >>
> >>
> >>
> >> --
> >> Sebastian Wagner
> >> https://twitter.com/#!/dead_lock
> >> http://www.webbase-design.de
> >> http://www.wagner-sebastian.com
> >> seba.wagner@gmail.com
> >>
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>