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 21:27:32 GMT
1) completed
2) completed


2013/3/19 Кочура Иван <kiv.ivan@gmail.com>

> 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