[VOTE] Discussing changes of Desing/Architecture of timezone implementation

So probably we can put this up for a vote? The only alternative I see as a short term fix is to overwrite the users "OmTimeZone" with the current timezone of the browser. Alternative 1: Short term fix, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estima

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

I don't really like the idea of having setting in the options which is overwritten on every login (silently) My vote is for Alternative 2. @Sebastian I guess Alternative 2 is for 3.1.0? I can try to perform refactoring faster. Then you can handle "fine tuning" of this issue and I can handle Impor

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Basically the calendar is not timezone safe as it is now. There is no option 3 to just leave it as is from my point of view. So something has to happen. Sebastian On 9 Aug 2013 20:19, "Maxim Solodovnik" wrote: > I don't really like the idea of having setting in the options which is > overwritten

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

OK let's wait for the VOTE results then start the refactoring :) On Fri, Aug 9, 2013 at 3:31 PM, seba.wag...@gmail.com wrote: > Basically the calendar is not timezone safe as it is now. There is no > option 3 to just leave it as is from my point of view. So something has to > happen. > > Sebast

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

My vote is for Alternative 2. Vasiliy On 09.08.2013 14:24, seba.wag...@gmail.com wrote: So probably we can put this up for a vote? The only alternative I see as a short term fix is to overwrite the users "OmTimeZone" with the current timezone of the browser. Alternative 1: Short term fix, de

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

My vote is also 2. I will create a couple of jiras later today. We can create a feature branch based on trunk and do the work inside that. Sebastian On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" wrote: > My vote is for Alternative 2. > > Vasiliy > > > On 09.08.2013 14:24, seba.wag...@gmail.com wr

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Maxim, just one thing: The "new" implemention will of course also "silently" overwrite the timezone string with every login. Otherwise we would send invitations to that user in a potentially wrong configured timezone. 2013/8/10 seba.wag...@gmail.com > My vote is also 2. I will create a coupl

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

https://issues.apache.org/jira/browse/OPENMEETINGS-745 is a summary jira, actual work is broken down in sub issues. Sebastian 2013/8/10 seba.wag...@gmail.com > Maxim, > > just one thing: The "new" implemention will of course also "silently" > overwrite the timezone string with every login. >

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

New Branch: http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/ based on trunk r1512224 Jenkins Job is at: https://builds.apache.org/job/OPENMEETIN

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

I have basically done the first task and replaced the OmTimeZone from the Invitations entity. I tried to keep any kind of functionality for matching the TimeZone in the TimezoneUtil. The String that I stored in the Invitations Entity is basically the result of java.util.TimeZone.getId(). http://sv

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Thanks for the updates. I'll try to investigate all use cases and try to create proposal of how to make user tz consistent, if it is impossible it make sense to make this setting unchangeable by the user. On Sat, Aug 10, 2013 at 10:41 AM, seba.wag...@gmail.com < seba.wag...@gmail.com> wrote: > I

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Hello Sebastian, I would like to discuss the modification of MeetingMember entity. IMHO this entity should contain only the following fields: private long id; private User user; private Appointment appointment; //!!! MAYBE it should be enum private String status; //status of the appointment denia

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

If you are only an attendee of a meeting and an internal OpenMeetings user, will you link it to the same event or have two events for every user? How is it currently? Sebastian On 15 Aug 2013 15:24, "Maxim Solodovnik" wrote: > Hello Sebastian, > > I would like to discuss the modification of Meet

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

And for the rest of the changes (modification of MeetingMember), I am fine with that, under the assumption: - All this data is stored now in the user entity - The field "type" in the user entity becomes editable in the user administration just like any other field - User of type contacts are sav

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Hello Sebastian, I believe there is no need to add Appointment owner to the Appointment attendees since: 1) it can't be changed/deleted 2) owner status is nothing but accepted (I guess) So every attendee of the Appointment is: 1) OM User (internal/external/contact) 2) has MeetingMember record con

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

I just rethink it. Admin in our system can see all objects, so all users are editable by admin. I'm not sure it is good idea to be able to change user type :( On Fri, Aug 16, 2013 at 10:19 AM, Maxim Solodovnik wrote: > Hello Sebastian, > > I believe there is no need to add Appointment owner to t

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

An admin should always be able to edit all fields from my point of view. And also appointments need an owner from my point of view. Cause only the owner/organiser of a calendar event can edit or delete an event. Other users can't. They see it in the calendar, the can click on it, see the details,