Unfortunately I don't have "best" solution in mind and would like to discuss possible approaches here.
Historically OM has 2 types of hashes 1) securityHash 2) invitationHash security hashes are created by OM plugins (for ex.) and allows users of 3rd party system to login to OM. On securityHash generation Sessiondata object with created in DB with userdata stored as XML (in Sessiondata.sessionXml field) User object will be created as soon as user will use the securityHash (the user created will be marked as external and will be unable to login since it has no password) on invitationHash creation the record is added to the invitation table and then get used. So right now we have 2 types of hashes and 3 types of users: 1) OM user 2) external OM users 3) "invitation" users I always thought all these things need to be generalized. (I really would like have only 1 hash and user) pros: 1) user invited once can be added to the users contacts and then selected from contacts while reinviting 2) every participant of conference will be user To implement this I would propose to even 1) add type and TTL to the user 2) add special user level 3) maybe anything else I would vote for adding type, TTL and hash to the user and remove SessionData and various types of hashes. Or maybe you have better solution On Mon, Mar 11, 2013 at 4:03 PM, Кочура Иван <kiv.i...@gmail.com> wrote: > Thank you for your patience and explanation. > > As I understand it, I have to create a new user along with creating the > invitation. The value for the field externalId will be the id invitation. > > When the user login on the invitation, we get the user id by externalType > and externalId. > > > 2013/3/7 Alexei Fedotov <alexei.fedo...@gmail.com> > > > Afaiu: > > > > Allowing others to vote can lead to improper results - someone can vote > > several times using hashes > > 07.03.2013 18:59 пользователь "Maxim Solodovnik" <solomax...@gmail.com> > > написал: > > > > > Hello Ivan, > > > > > > I believe that the only "being" able to participate in conference in OM > > > room is "*user". > > > This concept is true for links created for "external users" during > > > integration with various 3rd party CMS systems. > > > So, as I said before: the best short term solution would be to disable > > > voting for "non-users" > > > and the best long term solution would be to disable "non-users" in > rooms > > in > > > favor of users with special external type > > > or something like this. > > > > > > On Thu, Mar 7, 2013 at 3:43 PM, Кочура Иван <kiv.i...@gmail.com> > wrote: > > > > > > > Hello Maxim, > > > > > > > > As I said, > > > > " > > > > Creation ExternalUser for invited guests is redundant. It will not be > > > used > > > > anywhere else. > > > > In the case of my implementation, we have only one additional field > by > > > > which we can determine whether the user is a permanent or external. > > > > " > > > > > > > > Any problem can be solved in several ways. > > > > Explain to me, the inability to use my solution, please. It is > contrary > > > to > > > > anything? > > > > > > > > > > > > > > > > -- > > > WBR > > > Maxim aka solomax > > > > > > -- WBR Maxim aka solomax
