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 11:35:05 GMT
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
>

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