@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, Кочура Иван <kiv.i...@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 <solomax...@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 <akhor...@gmail.com > > >wrote: > > > > > As Maxim wrote before you could just deny invited users vote. > > > > > > 2013/3/19 Кочура Иван <kiv.i...@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 <solomax...@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.i...@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 <solomax...@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.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 > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> WBR > > > >> Maxim aka solomax > > > >> > > > > > > > > > > > -- > > WBR > > Maxim aka solomax > > > -- WBR Maxim aka solomax
