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 19:29:14 GMT
1) Ok. I disabled vote for invited guests.
2) I'll look


2013/3/19 Maxim Solodovnik <solomax666@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, Кочура Иван <kiv.ivan@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 <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
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

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