You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Кочура Иван <ki...@gmail.com> on 2013/03/07 09:43:06 UTC
bugfix_513
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?
Re: bugfix_513
Posted by Кочура Иван <ki...@gmail.com>.
1) completed
2) completed
2013/3/19 Кочура Иван <ki...@gmail.com>
> 1) Ok. I disabled vote for invited guests.
> 2) I'll look
>
>
> 2013/3/19 Maxim Solodovnik <so...@gmail.com>
>
>> @Ivan
>>
>> 1) I would disable vote for invited guests (not OM external or internal
>> users)
>> 2) "572" is related to the flash client only, wicket is not affected.
>>
>>
>> On Tue, Mar 19, 2013 at 10:52 PM, Кочура Иван <ki...@gmail.com> wrote:
>>
>> > To Artyom: We are not looking for easy ways.
>> >
>> > To Maxim: Perhaps, indeed, we should now turn off the vote for the
>> > invited? And
>> > it will be the best temporary solution.
>> >
>> > Values in the fields set through org.apache.wicket.*
>> > We can not catch the moment of assigning a value to the field, but we
>> > can do validation
>> > when "onSaveSubmit". Or we can perform validation during import /
>> export.
>> >
>> > My preferable area is: server, converters. I can perform more complex
>> > tasks, if they will have applied character.
>> >
>> > Later, I can take the task
>> > OPENMEETINGS-407<https://issues.apache.org/jira/browse/OPENMEETINGS-407
>> >
>> > .
>> >
>> >
>> > 2013/3/19 Maxim Solodovnik <so...@gmail.com>
>> >
>> > > You can try OPENMEETINGS-572<
>> > > https://issues.apache.org/jira/browse/OPENMEETINGS-572>
>> > > I think you should add checks to User Admin and "Profile edit"
>> (something
>> > > like if (val != null) textfield.setAttribute("value", val); or similar
>> > >
>> > > Please let me know if you need more complicated task
>> > > and what is your preferable area: client, server, protocols,
>> converters
>> > > etc.
>> > >
>> > >
>> > >
>> > > On Tue, Mar 19, 2013 at 6:38 PM, Artyom Horuzhenko <
>> akhor666@gmail.com
>> > > >wrote:
>> > >
>> > > > As Maxim wrote before you could just deny invited users vote.
>> > > >
>> > > > 2013/3/19 Кочура Иван <ki...@gmail.com>:
>> > > > > Of course, I'm sorry, but this is not an appropriate task for the
>> > > initial
>> > > > > phase of familiarity with the system. To implement it, I need to
>> know
>> > > all
>> > > > > the details of the requirements described by you. Otherwise, we
>> risk
>> > > > getting a
>> > > > > bad product.
>> > > > >
>> > > > > In any case, my efforts were not in vain. But maybe we should
>> choose
>> > > > another
>> > > > > task that is not related to global changes in the system?
>> > > > >
>> > > > >
>> > > > > 2013/3/13 Maxim Solodovnik <so...@gmail.com>
>> > > > >
>> > > > >> To save your efforts I would like to propose you to create sort
>> of
>> > > > >> simplified DB schema (User object with id+columns you going to
>> add)
>> > > > >> new user object should fit following use cases:
>> > > > >> it should be suitable for
>> > > > >> 1) login as normal OM user
>> > > > >> 2) login as LDAP user
>> > > > >> 3) login as user of 3rd party CMS (moodle, joomla, etc.)
>> > > > >> 4) invitation to the room
>> > > > >> 5) invitation from the calendar
>> > > > >>
>> > > > >> please NOTE currently invitations has following capabilities:
>> > > > >> 1) unlimited
>> > > > >> 2) one time
>> > > > >> 3) period of time
>> > > > >>
>> > > > >> I feel this feature should be well designed and discussed couple
>> of
>> > > more
>> > > > >> times before you can create a patch.
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <
>> kiv.ivan@gmail.com>
>> > > > wrote:
>> > > > >>
>> > > > >> > I support the solution on creation only one type of user, and
>> > > cache.
>> > > > For
>> > > > >> > the user, we need to add the lifetime account (time period or
>> an
>> > > > >> unlimited.
>> > > > >> > Use a one-time authorization can bring some problems when
>> required
>> > > to
>> > > > >> > reload the page)
>> > > > >> >
>> > > > >> > The task turns into something more than a bug fix.
>> > > > >> >
>> > > > >> > Unfortunately, I have little experience with the OM. That will
>> > lead
>> > > > to a
>> > > > >> > major increase development time.
>> > > > >> >
>> > > > >> >
>> > > > >> > 2013/3/11 Maxim Solodovnik <so...@gmail.com>
>> > > > >> >
>> > > > >> > > 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.ivan@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 <al...@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" <
>> > > > >> > solomax666@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.ivan@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
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >> WBR
>> > > > >> Maxim aka solomax
>> > > > >>
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > WBR
>> > > Maxim aka solomax
>> > >
>> >
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
Re: bugfix_513
Posted by Кочура Иван <ki...@gmail.com>.
1) Ok. I disabled vote for invited guests.
2) I'll look
2013/3/19 Maxim Solodovnik <so...@gmail.com>
> @Ivan
>
> 1) I would disable vote for invited guests (not OM external or internal
> users)
> 2) "572" is related to the flash client only, wicket is not affected.
>
>
> On Tue, Mar 19, 2013 at 10:52 PM, Кочура Иван <ki...@gmail.com> wrote:
>
> > To Artyom: We are not looking for easy ways.
> >
> > To Maxim: Perhaps, indeed, we should now turn off the vote for the
> > invited? And
> > it will be the best temporary solution.
> >
> > Values in the fields set through org.apache.wicket.*
> > We can not catch the moment of assigning a value to the field, but we
> > can do validation
> > when "onSaveSubmit". Or we can perform validation during import / export.
> >
> > My preferable area is: server, converters. I can perform more complex
> > tasks, if they will have applied character.
> >
> > Later, I can take the task
> > OPENMEETINGS-407<https://issues.apache.org/jira/browse/OPENMEETINGS-407>
> > .
> >
> >
> > 2013/3/19 Maxim Solodovnik <so...@gmail.com>
> >
> > > You can try OPENMEETINGS-572<
> > > https://issues.apache.org/jira/browse/OPENMEETINGS-572>
> > > I think you should add checks to User Admin and "Profile edit"
> (something
> > > like if (val != null) textfield.setAttribute("value", val); or similar
> > >
> > > Please let me know if you need more complicated task
> > > and what is your preferable area: client, server, protocols, converters
> > > etc.
> > >
> > >
> > >
> > > On Tue, Mar 19, 2013 at 6:38 PM, Artyom Horuzhenko <akhor666@gmail.com
> > > >wrote:
> > >
> > > > As Maxim wrote before you could just deny invited users vote.
> > > >
> > > > 2013/3/19 Кочура Иван <ki...@gmail.com>:
> > > > > Of course, I'm sorry, but this is not an appropriate task for the
> > > initial
> > > > > phase of familiarity with the system. To implement it, I need to
> know
> > > all
> > > > > the details of the requirements described by you. Otherwise, we
> risk
> > > > getting a
> > > > > bad product.
> > > > >
> > > > > In any case, my efforts were not in vain. But maybe we should
> choose
> > > > another
> > > > > task that is not related to global changes in the system?
> > > > >
> > > > >
> > > > > 2013/3/13 Maxim Solodovnik <so...@gmail.com>
> > > > >
> > > > >> To save your efforts I would like to propose you to create sort of
> > > > >> simplified DB schema (User object with id+columns you going to
> add)
> > > > >> new user object should fit following use cases:
> > > > >> it should be suitable for
> > > > >> 1) login as normal OM user
> > > > >> 2) login as LDAP user
> > > > >> 3) login as user of 3rd party CMS (moodle, joomla, etc.)
> > > > >> 4) invitation to the room
> > > > >> 5) invitation from the calendar
> > > > >>
> > > > >> please NOTE currently invitations has following capabilities:
> > > > >> 1) unlimited
> > > > >> 2) one time
> > > > >> 3) period of time
> > > > >>
> > > > >> I feel this feature should be well designed and discussed couple
> of
> > > more
> > > > >> times before you can create a patch.
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <kiv.ivan@gmail.com
> >
> > > > wrote:
> > > > >>
> > > > >> > I support the solution on creation only one type of user, and
> > > cache.
> > > > For
> > > > >> > the user, we need to add the lifetime account (time period or an
> > > > >> unlimited.
> > > > >> > Use a one-time authorization can bring some problems when
> required
> > > to
> > > > >> > reload the page)
> > > > >> >
> > > > >> > The task turns into something more than a bug fix.
> > > > >> >
> > > > >> > Unfortunately, I have little experience with the OM. That will
> > lead
> > > > to a
> > > > >> > major increase development time.
> > > > >> >
> > > > >> >
> > > > >> > 2013/3/11 Maxim Solodovnik <so...@gmail.com>
> > > > >> >
> > > > >> > > 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.ivan@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 <al...@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" <
> > > > >> > solomax666@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.ivan@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
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> WBR
> > > > >> Maxim aka solomax
> > > > >>
> > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: bugfix_513
Posted by Maxim Solodovnik <so...@gmail.com>.
@Ivan
1) I would disable vote for invited guests (not OM external or internal
users)
2) "572" is related to the flash client only, wicket is not affected.
On Tue, Mar 19, 2013 at 10:52 PM, Кочура Иван <ki...@gmail.com> wrote:
> To Artyom: We are not looking for easy ways.
>
> To Maxim: Perhaps, indeed, we should now turn off the vote for the
> invited? And
> it will be the best temporary solution.
>
> Values in the fields set through org.apache.wicket.*
> We can not catch the moment of assigning a value to the field, but we
> can do validation
> when "onSaveSubmit". Or we can perform validation during import / export.
>
> My preferable area is: server, converters. I can perform more complex
> tasks, if they will have applied character.
>
> Later, I can take the task
> OPENMEETINGS-407<https://issues.apache.org/jira/browse/OPENMEETINGS-407>
> .
>
>
> 2013/3/19 Maxim Solodovnik <so...@gmail.com>
>
> > You can try OPENMEETINGS-572<
> > https://issues.apache.org/jira/browse/OPENMEETINGS-572>
> > I think you should add checks to User Admin and "Profile edit" (something
> > like if (val != null) textfield.setAttribute("value", val); or similar
> >
> > Please let me know if you need more complicated task
> > and what is your preferable area: client, server, protocols, converters
> > etc.
> >
> >
> >
> > On Tue, Mar 19, 2013 at 6:38 PM, Artyom Horuzhenko <akhor666@gmail.com
> > >wrote:
> >
> > > As Maxim wrote before you could just deny invited users vote.
> > >
> > > 2013/3/19 Кочура Иван <ki...@gmail.com>:
> > > > Of course, I'm sorry, but this is not an appropriate task for the
> > initial
> > > > phase of familiarity with the system. To implement it, I need to know
> > all
> > > > the details of the requirements described by you. Otherwise, we risk
> > > getting a
> > > > bad product.
> > > >
> > > > In any case, my efforts were not in vain. But maybe we should choose
> > > another
> > > > task that is not related to global changes in the system?
> > > >
> > > >
> > > > 2013/3/13 Maxim Solodovnik <so...@gmail.com>
> > > >
> > > >> To save your efforts I would like to propose you to create sort of
> > > >> simplified DB schema (User object with id+columns you going to add)
> > > >> new user object should fit following use cases:
> > > >> it should be suitable for
> > > >> 1) login as normal OM user
> > > >> 2) login as LDAP user
> > > >> 3) login as user of 3rd party CMS (moodle, joomla, etc.)
> > > >> 4) invitation to the room
> > > >> 5) invitation from the calendar
> > > >>
> > > >> please NOTE currently invitations has following capabilities:
> > > >> 1) unlimited
> > > >> 2) one time
> > > >> 3) period of time
> > > >>
> > > >> I feel this feature should be well designed and discussed couple of
> > more
> > > >> times before you can create a patch.
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <ki...@gmail.com>
> > > wrote:
> > > >>
> > > >> > I support the solution on creation only one type of user, and
> > cache.
> > > For
> > > >> > the user, we need to add the lifetime account (time period or an
> > > >> unlimited.
> > > >> > Use a one-time authorization can bring some problems when required
> > to
> > > >> > reload the page)
> > > >> >
> > > >> > The task turns into something more than a bug fix.
> > > >> >
> > > >> > Unfortunately, I have little experience with the OM. That will
> lead
> > > to a
> > > >> > major increase development time.
> > > >> >
> > > >> >
> > > >> > 2013/3/11 Maxim Solodovnik <so...@gmail.com>
> > > >> >
> > > >> > > 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.ivan@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 <al...@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" <
> > > >> > solomax666@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.ivan@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
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> WBR
> > > >> Maxim aka solomax
> > > >>
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
--
WBR
Maxim aka solomax
Re: bugfix_513
Posted by Кочура Иван <ki...@gmail.com>.
To Artyom: We are not looking for easy ways.
To Maxim: Perhaps, indeed, we should now turn off the vote for the invited? And
it will be the best temporary solution.
Values in the fields set through org.apache.wicket.*
We can not catch the moment of assigning a value to the field, but we
can do validation
when "onSaveSubmit". Or we can perform validation during import / export.
My preferable area is: server, converters. I can perform more complex
tasks, if they will have applied character.
Later, I can take the task
OPENMEETINGS-407<https://issues.apache.org/jira/browse/OPENMEETINGS-407>
.
2013/3/19 Maxim Solodovnik <so...@gmail.com>
> You can try OPENMEETINGS-572<
> https://issues.apache.org/jira/browse/OPENMEETINGS-572>
> I think you should add checks to User Admin and "Profile edit" (something
> like if (val != null) textfield.setAttribute("value", val); or similar
>
> Please let me know if you need more complicated task
> and what is your preferable area: client, server, protocols, converters
> etc.
>
>
>
> On Tue, Mar 19, 2013 at 6:38 PM, Artyom Horuzhenko <akhor666@gmail.com
> >wrote:
>
> > As Maxim wrote before you could just deny invited users vote.
> >
> > 2013/3/19 Кочура Иван <ki...@gmail.com>:
> > > Of course, I'm sorry, but this is not an appropriate task for the
> initial
> > > phase of familiarity with the system. To implement it, I need to know
> all
> > > the details of the requirements described by you. Otherwise, we risk
> > getting a
> > > bad product.
> > >
> > > In any case, my efforts were not in vain. But maybe we should choose
> > another
> > > task that is not related to global changes in the system?
> > >
> > >
> > > 2013/3/13 Maxim Solodovnik <so...@gmail.com>
> > >
> > >> To save your efforts I would like to propose you to create sort of
> > >> simplified DB schema (User object with id+columns you going to add)
> > >> new user object should fit following use cases:
> > >> it should be suitable for
> > >> 1) login as normal OM user
> > >> 2) login as LDAP user
> > >> 3) login as user of 3rd party CMS (moodle, joomla, etc.)
> > >> 4) invitation to the room
> > >> 5) invitation from the calendar
> > >>
> > >> please NOTE currently invitations has following capabilities:
> > >> 1) unlimited
> > >> 2) one time
> > >> 3) period of time
> > >>
> > >> I feel this feature should be well designed and discussed couple of
> more
> > >> times before you can create a patch.
> > >>
> > >>
> > >>
> > >> On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <ki...@gmail.com>
> > wrote:
> > >>
> > >> > I support the solution on creation only one type of user, and
> cache.
> > For
> > >> > the user, we need to add the lifetime account (time period or an
> > >> unlimited.
> > >> > Use a one-time authorization can bring some problems when required
> to
> > >> > reload the page)
> > >> >
> > >> > The task turns into something more than a bug fix.
> > >> >
> > >> > Unfortunately, I have little experience with the OM. That will lead
> > to a
> > >> > major increase development time.
> > >> >
> > >> >
> > >> > 2013/3/11 Maxim Solodovnik <so...@gmail.com>
> > >> >
> > >> > > 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, Кочура Иван <ki...@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 <al...@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" <
> > >> > solomax666@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.ivan@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
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> WBR
> > >> Maxim aka solomax
> > >>
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: bugfix_513
Posted by Maxim Solodovnik <so...@gmail.com>.
You can try OPENMEETINGS-572<https://issues.apache.org/jira/browse/OPENMEETINGS-572>
I think you should add checks to User Admin and "Profile edit" (something
like if (val != null) textfield.setAttribute("value", val); or similar
Please let me know if you need more complicated task
and what is your preferable area: client, server, protocols, converters etc.
On Tue, Mar 19, 2013 at 6:38 PM, Artyom Horuzhenko <ak...@gmail.com>wrote:
> As Maxim wrote before you could just deny invited users vote.
>
> 2013/3/19 Кочура Иван <ki...@gmail.com>:
> > Of course, I'm sorry, but this is not an appropriate task for the initial
> > phase of familiarity with the system. To implement it, I need to know all
> > the details of the requirements described by you. Otherwise, we risk
> getting a
> > bad product.
> >
> > In any case, my efforts were not in vain. But maybe we should choose
> another
> > task that is not related to global changes in the system?
> >
> >
> > 2013/3/13 Maxim Solodovnik <so...@gmail.com>
> >
> >> To save your efforts I would like to propose you to create sort of
> >> simplified DB schema (User object with id+columns you going to add)
> >> new user object should fit following use cases:
> >> it should be suitable for
> >> 1) login as normal OM user
> >> 2) login as LDAP user
> >> 3) login as user of 3rd party CMS (moodle, joomla, etc.)
> >> 4) invitation to the room
> >> 5) invitation from the calendar
> >>
> >> please NOTE currently invitations has following capabilities:
> >> 1) unlimited
> >> 2) one time
> >> 3) period of time
> >>
> >> I feel this feature should be well designed and discussed couple of more
> >> times before you can create a patch.
> >>
> >>
> >>
> >> On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <ki...@gmail.com>
> wrote:
> >>
> >> > I support the solution on creation only one type of user, and cache.
> For
> >> > the user, we need to add the lifetime account (time period or an
> >> unlimited.
> >> > Use a one-time authorization can bring some problems when required to
> >> > reload the page)
> >> >
> >> > The task turns into something more than a bug fix.
> >> >
> >> > Unfortunately, I have little experience with the OM. That will lead
> to a
> >> > major increase development time.
> >> >
> >> >
> >> > 2013/3/11 Maxim Solodovnik <so...@gmail.com>
> >> >
> >> > > 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, Кочура Иван <ki...@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 <al...@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" <
> >> > solomax666@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.ivan@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
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> WBR
> >> Maxim aka solomax
> >>
>
--
WBR
Maxim aka solomax
Re: bugfix_513
Posted by Artyom Horuzhenko <ak...@gmail.com>.
As Maxim wrote before you could just deny invited users vote.
2013/3/19 Кочура Иван <ki...@gmail.com>:
> Of course, I'm sorry, but this is not an appropriate task for the initial
> phase of familiarity with the system. To implement it, I need to know all
> the details of the requirements described by you. Otherwise, we risk getting a
> bad product.
>
> In any case, my efforts were not in vain. But maybe we should choose another
> task that is not related to global changes in the system?
>
>
> 2013/3/13 Maxim Solodovnik <so...@gmail.com>
>
>> To save your efforts I would like to propose you to create sort of
>> simplified DB schema (User object with id+columns you going to add)
>> new user object should fit following use cases:
>> it should be suitable for
>> 1) login as normal OM user
>> 2) login as LDAP user
>> 3) login as user of 3rd party CMS (moodle, joomla, etc.)
>> 4) invitation to the room
>> 5) invitation from the calendar
>>
>> please NOTE currently invitations has following capabilities:
>> 1) unlimited
>> 2) one time
>> 3) period of time
>>
>> I feel this feature should be well designed and discussed couple of more
>> times before you can create a patch.
>>
>>
>>
>> On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <ki...@gmail.com> wrote:
>>
>> > I support the solution on creation only one type of user, and cache. For
>> > the user, we need to add the lifetime account (time period or an
>> unlimited.
>> > Use a one-time authorization can bring some problems when required to
>> > reload the page)
>> >
>> > The task turns into something more than a bug fix.
>> >
>> > Unfortunately, I have little experience with the OM. That will lead to a
>> > major increase development time.
>> >
>> >
>> > 2013/3/11 Maxim Solodovnik <so...@gmail.com>
>> >
>> > > 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, Кочура Иван <ki...@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 <al...@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" <
>> > solomax666@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, Кочура Иван <ki...@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
>> > >
>> >
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
Re: bugfix_513
Posted by Кочура Иван <ki...@gmail.com>.
Of course, I'm sorry, but this is not an appropriate task for the initial
phase of familiarity with the system. To implement it, I need to know all
the details of the requirements described by you. Otherwise, we risk getting a
bad product.
In any case, my efforts were not in vain. But maybe we should choose another
task that is not related to global changes in the system?
2013/3/13 Maxim Solodovnik <so...@gmail.com>
> To save your efforts I would like to propose you to create sort of
> simplified DB schema (User object with id+columns you going to add)
> new user object should fit following use cases:
> it should be suitable for
> 1) login as normal OM user
> 2) login as LDAP user
> 3) login as user of 3rd party CMS (moodle, joomla, etc.)
> 4) invitation to the room
> 5) invitation from the calendar
>
> please NOTE currently invitations has following capabilities:
> 1) unlimited
> 2) one time
> 3) period of time
>
> I feel this feature should be well designed and discussed couple of more
> times before you can create a patch.
>
>
>
> On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <ki...@gmail.com> wrote:
>
> > I support the solution on creation only one type of user, and cache. For
> > the user, we need to add the lifetime account (time period or an
> unlimited.
> > Use a one-time authorization can bring some problems when required to
> > reload the page)
> >
> > The task turns into something more than a bug fix.
> >
> > Unfortunately, I have little experience with the OM. That will lead to a
> > major increase development time.
> >
> >
> > 2013/3/11 Maxim Solodovnik <so...@gmail.com>
> >
> > > 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, Кочура Иван <ki...@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 <al...@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" <
> > solomax666@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, Кочура Иван <ki...@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
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: bugfix_513
Posted by Maxim Solodovnik <so...@gmail.com>.
To save your efforts I would like to propose you to create sort of
simplified DB schema (User object with id+columns you going to add)
new user object should fit following use cases:
it should be suitable for
1) login as normal OM user
2) login as LDAP user
3) login as user of 3rd party CMS (moodle, joomla, etc.)
4) invitation to the room
5) invitation from the calendar
please NOTE currently invitations has following capabilities:
1) unlimited
2) one time
3) period of time
I feel this feature should be well designed and discussed couple of more
times before you can create a patch.
On Wed, Mar 13, 2013 at 10:01 PM, Кочура Иван <ki...@gmail.com> wrote:
> I support the solution on creation only one type of user, and cache. For
> the user, we need to add the lifetime account (time period or an unlimited.
> Use a one-time authorization can bring some problems when required to
> reload the page)
>
> The task turns into something more than a bug fix.
>
> Unfortunately, I have little experience with the OM. That will lead to a
> major increase development time.
>
>
> 2013/3/11 Maxim Solodovnik <so...@gmail.com>
>
> > 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, Кочура Иван <ki...@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 <al...@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" <
> solomax666@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, Кочура Иван <ki...@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
> >
>
--
WBR
Maxim aka solomax
Re: bugfix_513
Posted by Кочура Иван <ki...@gmail.com>.
I support the solution on creation only one type of user, and cache. For
the user, we need to add the lifetime account (time period or an unlimited.
Use a one-time authorization can bring some problems when required to
reload the page)
The task turns into something more than a bug fix.
Unfortunately, I have little experience with the OM. That will lead to a
major increase development time.
2013/3/11 Maxim Solodovnik <so...@gmail.com>
> 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, Кочура Иван <ki...@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 <al...@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" <solomax666@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, Кочура Иван <ki...@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
>
Re: bugfix_513
Posted by Maxim Solodovnik <so...@gmail.com>.
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, Кочура Иван <ki...@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 <al...@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" <so...@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, Кочура Иван <ki...@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
Re: bugfix_513
Posted by Кочура Иван <ki...@gmail.com>.
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 <al...@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" <so...@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, Кочура Иван <ki...@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
> >
>
Re: bugfix_513
Posted by Alexei Fedotov <al...@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" <so...@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, Кочура Иван <ki...@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
>
Re: bugfix_513
Posted by Maxim Solodovnik <so...@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, Кочура Иван <ki...@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