publicSID is temporary (per session) variable, it is not a good idea to put it into invitations table. I believe the best short term solution would be to disable voting and the best long term solution would be to create "ExternalUser" entity and store references to it in various types of other tables (or maybe add additional type of user "external") something like this
On Mon, Feb 25, 2013 at 4:15 PM, Кочура Иван <[email protected]> wrote: > Using the publicSID is not enough, I checked it. > > When a user comes to the invitation, we can retain the publicSID of the > active user in the table "invitations". So that we can get a invatedHash > using the publicSID. > > Limit voting is not the best idea. In the future, this functionality can be > useful. > > ---------- Forwarded message ---------- > From: Artyom Horuzhenko <[email protected]> > Date: 2013/2/25 > Subject: Fwd: bug #513 > To: [email protected] > > > ---------- Forwarded message ---------- > From: Maxim Solodovnik <[email protected]> > Date: 2013/2/21 > Subject: Re: bug #513 > To: dev <[email protected]> > > > I'm afraid it is impossible to have invitation hash > You only can get publicSID (seems to be not enough, since the issue will > remain for infinite and time range invitations) > You can limit voting to the OM users (disable vote button for invited > guests) > > > On Thu, Feb 21, 2013 at 4:16 PM, Кочура Иван <[email protected]> wrote: > > > Hello. My name is Kochura Ivan. I'm going to fixed a bug https://issues. > > apache.org/jira/browse/OPENMEETINGS-513, using invatedHash. In addition > to > > the client id, we must preserve the InvitationHash in the > RoomPollAnswers. > > Based on the above, I have a question. How to get a InvitationHash if I > > have only streamid. (in class PollService) > > > > > > -- > WBR > Maxim aka solomax > -- WBR Maxim aka solomax
