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
