Re: bugfix_513

1) completed 2) completed 2013/3/19 Кочура Иван > 1) Ok. I disabled vote for invited guests. > 2) I'll look > > > 2013/3/19 Maxim Solodovnik > >> @Ivan >> >> 1) I would disable vote for invited guests (not OM external or internal >> users) >> 2) "572" is related to the flash client only, wicke

Re: bugfix_513

1) Ok. I disabled vote for invited guests. 2) I'll look 2013/3/19 Maxim Solodovnik > @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, Кочура

Re: bugfix_513

@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, Кочура Иван wrote: > To Artyom: We are not looking for easy ways. > > To Maxim: Perhaps, indeed, we shoul

Re: bugfix_513

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 va

Re: bugfix_513

You can try 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 yo

Re: bugfix_513

As Maxim wrote before you could just deny invited users vote. 2013/3/19 Кочура Иван : > 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. Otherwis

Re: bugfix_513

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 sho

Re: bugfix_513

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

Re: bugfix_513

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. Unfortuna

Re: bugfix_513

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 g

Re: bugfix_513

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 Alexe

Re: bugfix_513

Afaiu: Allowing others to vote can lead to improper results - someone can vote several times using hashes 07.03.2013 18:59 пользователь "Maxim Solodovnik" написал: > Hello Ivan, > > I believe that the only "being" able to participate in conference in OM > room is "*user". > This concept is true

Re: bugfix_513

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