openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Кочура Иван <kiv.i...@gmail.com>
Subject Re: bugfix_513
Date Tue, 19 Mar 2013 15:52:38 GMT
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 <solomax666@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 Кочура Иван <kiv.ivan@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 <solomax666@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 <solomax666@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 <alexei.fedotov@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message