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, use the link from the calendar ui to the linked conference room for that meeting but: They can't add or remove attendee's, edit the time or any other field and they cannot change the time or duration of the meeting. This functionality was already present in Openmeetings 2.x Sebastian On 17 Aug 2013 03:14, Maxim Solodovnik solomax...@gmail.com wrote: 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 solomax...@gmail.comwrote: 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 connecting User with Appointment and storing attendee status not sure how is it currently (need to double-check) According to your assumptions: 1) I'm not sure it is good idea if Admin will be able to edit contact of the user 2) Current code should be modified to: a) check different users can have contacts with same email address and with other fields differs (same check should be performed for the external users) -- I believe this can be done by Unit tests b) check contact of different users are not accessible by others 3) The field of type enum is savable as String in all databases. I'll try to add these tests/logic in nearest week(s) Hopefully will have time for that On Fri, Aug 16, 2013 at 6:53 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: 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 saveble in the user administration - The field type enum is supported by OpenJPA and all major database vendors Cheers, Sebastian 2013/8/16 seba.wag...@gmail.com seba.wag...@gmail.com 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 solomax...@gmail.com wrote: 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 denial, acceptance, wait. private Date updatetime; private Invitations invitation; //not null in case Invitation was sent to the external attendee private boolean isConnectedEvent; //for the contact requests all other fields should be removed. I also would vote for renaming Appointment.userId field to Appointment.owner And I would change Long and Boolean fields to long and boolean where possible What do you think about it? On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik solomax...@gmail.com wrote: 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 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://svn.apache.org/r1512557 Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com New Branch: http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/ based on trunk r1512224 https://issues.apache.org/jira/browse/OPENMEETINGS-752# https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/ Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com 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 seba.wag...@gmail.com Maxim, just one thing: The new implemention will of course also silently overwrite the timezone string with every login. Otherwise we would send invitations
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 solomax...@gmail.com wrote: 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 denial, acceptance, wait. private Date updatetime; private Invitations invitation; //not null in case Invitation was sent to the external attendee private boolean isConnectedEvent; //for the contact requests all other fields should be removed. I also would vote for renaming Appointment.userId field to Appointment.owner And I would change Long and Boolean fields to long and boolean where possible What do you think about it? On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik solomax...@gmail.comwrote: 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 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://svn.apache.org/r1512557 Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com New Branch: http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/ based on trunk r1512224 https://issues.apache.org/jira/browse/OPENMEETINGS-752# https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/ Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 va...@unipro.ru wrote: 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/** rem2snf74srvftnt http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone
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 saveble in the user administration - The field type enum is supported by OpenJPA and all major database vendors Cheers, Sebastian 2013/8/16 seba.wag...@gmail.com seba.wag...@gmail.com 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 solomax...@gmail.com wrote: 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 denial, acceptance, wait. private Date updatetime; private Invitations invitation; //not null in case Invitation was sent to the external attendee private boolean isConnectedEvent; //for the contact requests all other fields should be removed. I also would vote for renaming Appointment.userId field to Appointment.owner And I would change Long and Boolean fields to long and boolean where possible What do you think about it? On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik solomax...@gmail.comwrote: 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 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://svn.apache.org/r1512557 Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com New Branch: http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/ based on trunk r1512224 https://issues.apache.org/jira/browse/OPENMEETINGS-752# https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/ Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 va...@unipro.ru wrote: 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/** rem2snf74srvftnt http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or
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 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://svn.apache.org/r1512557 Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com New Branch: http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/ based on trunk r1512224 https://issues.apache.org/jira/browse/OPENMEETINGS-752# https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/ Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 va...@unipro.ru wrote: 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/** rem2snf74srvftnt http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an
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 solomax...@gmail.com wrote: 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 Import/Export (might be tricky) On Fri, Aug 9, 2013 at 2:24 PM, seba.wag...@gmail.com 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/quicksketch/timezonepicker/issues/2) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone
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 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. Sebastian On 9 Aug 2013 20:19, Maxim Solodovnik solomax...@gmail.com wrote: 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 Import/Export (might be tricky) On Fri, Aug 9, 2013 at 2:24 PM, seba.wag...@gmail.com 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment (
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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/quicksketch/timezonepicker/issues/2) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1) Where do we populate the timezones from in that list, displaying 650 timezones of java.util.Timezone is not practical 2) If we default that timezone to some value, what shall it be? The timezone of the server or the timezone of the client browser? = In theory this default timezone is used whenever we can't find a suitable timezone. So potentially we can default it to the browsers timezone that is currently installing OpenMeetings. This default timzeone will be used whenever there is no timezone available for a user or if the timezone of the user is corrupted. Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com Additionally Appointment, I guess. Non-existent XML attribute will be ignored by simpleframework. I believe we can let timezones.xml live in our sources and convert backups based on it On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: That might be
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 va...@unipro.ru wrote: 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/** rem2snf74srvftnt http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/**quicksketch/timezonepickerhttps://github.com/quicksketch/timezonepicker ) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/**quicksketch/timezonepicker/**issues/2https://github.com/quicksketch/timezonepicker/issues/2 ) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1) Where do we populate the timezones from in that list, displaying 650 timezones of java.util.Timezone is not practical 2) If we default that timezone to some value, what shall it be? The timezone of the server or the timezone of the client browser? = In theory this default timezone is used whenever we can't find a suitable timezone. So potentially we can default it to the browsers timezone that is currently installing OpenMeetings. This
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 seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 va...@unipro.ru wrote: 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/** rem2snf74srvftnt http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/**quicksketch/timezonepickerhttps://github.com/quicksketch/timezonepicker ) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/**quicksketch/timezonepicker/**issues/2https://github.com/quicksketch/timezonepicker/issues/2 ) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1)
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 https://issues.apache.org/jira/browse/OPENMEETINGS-752# https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/ Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 va...@unipro.ru wrote: 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/** rem2snf74srvftnt http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/**quicksketch/timezonepickerhttps://github.com/quicksketch/timezonepicker ) The only issues I can see right now: 1) it has no License set in the moment (
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://svn.apache.org/r1512557 Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com New Branch: http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/ based on trunk r1512224 https://issues.apache.org/jira/browse/OPENMEETINGS-752# https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/ Sebastian 2013/8/10 seba.wag...@gmail.com seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 seba.wag...@gmail.com 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 va...@unipro.ru wrote: 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, default OmTimeZone to current timezone in browser, overwrite everytime the user logs in (Estimated 1-2 weeks of work) Alternative 2: Rewrite and refactor to get rid of entire OmTimeZone (as described in attached discussion or thread: http://markmail.org/message/** rem2snf74srvftnt http://markmail.org/message/rem2snf74srvftnt) (Estimated 1-2 months of work) The effort estimates are including time that is needed for fixing bugs and do the testing. Vote for 1 if you like to see this implemented as part of OpenMeetings 3.0.0, vote for Alternative 2 if you want to see this implemented as part of OpenMeetings 3.0.0. Thanks, Sebastian 2013/8/8 seba.wag...@gmail.com seba.wag...@gmail.com That is the major question. Basically status now is that the Calendar UI is not ready to be released. The UI is simply not working when your browser timezone is different from the timezone in your OpenMeetings profile. So either we can do the proposed fixes around getting rid of the OmTimeZone completely or we try to do some kind of workaround in OpenMeetings 3.0.0 and do the refactoring later. Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim
