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 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/timezonepicker<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<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 another approach. >>>>>>>>>>>>>>>>>> So you are saying we get rid of the Entity OmTimeZone in >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> total? >>>>>>>>>>> >>>>>>>>>>>> Even if we have the timezone in the each of those object,I >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> think >>>>>>>>>>> >>>>>>>>>>>> there >>>>>>>>>>>>>> >>>>>>>>>>>>>>> should be a fallback mechanism. Cause with every Java >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> update >>>>>>>>>> >>>>>>>>>>> (or I >>>>>>>>>>>> >>>>>>>>>>>>> think >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> you can even do it manually) you can get updates to the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> number/offset >>>>>>>>>>>>>> >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the timezones (appearently every year such and such >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> countries >>>>>>>>>> >>>>>>>>>>> for >>>>>>>>>>>> >>>>>>>>>>>>> instance >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> "decide" to switch to have not a Daylight saving time, et >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> cetera, >>>>>>>>>>>> >>>>>>>>>>>>> or >>>>>>>>>>>>> >>>>>>>>>>>>>> there >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> is even a brand new timezone). >>>>>>>>>>>>>>>>>> So it could happen one day that we have timezone string in >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> our >>>>>>>>>> >>>>>>>>>>> application >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> that is neither known to java.util.Timezone nor to >>>>>>>>>>>>>>>>>> net.fortuna.ical4j.model.**TimeZone. Or a timezone >>>>>>>>>>>>>>>>>> exists in >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>>> one >>>>>>>>>>>> >>>>>>>>>>>>> and >>>>>>>>>>>>>> >>>>>>>>>>>>>>> does >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> not exist in the other. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think we should go the extra mile and try to outline the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> technical >>>>>>>>>>>>> >>>>>>>>>>>>>> part >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> upfront doing anything concretly. It could save us a lot of >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> time. >>>>>>>>>>>> >>>>>>>>>>>>> Also it >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> might be good to discuss this publicly as more then one >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> person >>>>>>>>>> >>>>>>>>>>> can >>>>>>>>>>>> >>>>>>>>>>>>> then >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> work on it in parallel. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As far as I can judge you can't save the type >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> java.util.Timezone >>>>>>>>>>> >>>>>>>>>>>> in >>>>>>>>>>>>> >>>>>>>>>>>>>> a >>>>>>>>>>>>>> >>>>>>>>>>>>>>> database. >>>>>>>>>>>>>>>>>> So it has to be either a string or you store an Integer >>>>>>>>>>>>>>>>>> (utcTimeZoneOffset). But I really don't like the latter as >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> it >>>>>>>>>> >>>>>>>>>>> does >>>>>>>>>>>> >>>>>>>>>>>>> not >>>>>>>>>>>>>> >>>>>>>>>>>>>>> handle Daylight savings times. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So the Entities that hold an attribute "omTimeZone" that >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> would >>>>>>>>>> >>>>>>>>>>> need >>>>>>>>>>>>> >>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> changed: >>>>>>>>>>>>>>>>>> User >>>>>>>>>>>>>>>>>> Invitations >>>>>>>>>>>>>>>>>> MeetingMembers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> and they all get a new attribute "String tz" >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> How would we imagine could the export and import work if >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> you >>>>>>>>>> >>>>>>>>>>> import >>>>>>>>>>>>> >>>>>>>>>>>>>> an >>>>>>>>>>>>>> >>>>>>>>>>>>>>> old >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> backup where the OmTimeZone is set in the user? I guess we >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> need >>>>>>>>>>> >>>>>>>>>>>> a >>>>>>>>>>>> >>>>>>>>>>>>> converter >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> that can handle OmTimeZone to the new format. >>>>>>>>>>>>>>>>>> However would that even work currently with >>>>>>>>>>>>>>>>>> org.simpleframework.xml.**Element, when you have an >>>>>>>>>>>>>>>>>> attribute >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> that >>>>>>>>>>> >>>>>>>>>>>> does >>>>>>>>>>>>>> >>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> no more exist ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Any other considerations that are not yet covered? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2013/8/6 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I like the idea of having less custom issues >>>>>>>>>>>>>>>>>>> I believe TZ field in all our objects can easily be just >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> a >>>>>>>>>> >>>>>>>>>>> string >>>>>>>>>>>>> >>>>>>>>>>>>>> like: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "Europe/Berlin" >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik < >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> solomax...@gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> I have: It is impossible to get User timezone (you only >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> can >>>>>>>>>>> >>>>>>>>>>>> get >>>>>>>>>>>>> >>>>>>>>>>>>>> tz >>>>>>>>>>>>>> >>>>>>>>>>>>>>> shift >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> and/or dst shift and if dst is in effect) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> According to iCal4J time zone mapping I guess the name >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>> >>>>>>>>>>>>> be >>>>>>>>>>>>> >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com< >>>>>>>>>>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Okay, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> after a bit of back and forth using the >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> wicket-jquery-ui >>>>>>>>>> >>>>>>>>>>> library >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>> might be worth re-evaluating our timezone behaviour. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Basically it seems like the approach to show the UI >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> in a >>>>>>>>>> >>>>>>>>>>> timezone >>>>>>>>>>>>>> >>>>>>>>>>>>>>> different >>>>>>>>>>>>>>>>>>>>> from the users browser/os is a non common approach. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> And >>>>>>>>>> >>>>>>>>>>> eventually >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> directly migrate away from it. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So the proposal would be: >>>>>>>>>>>>>>>>>>>>> Show the calendar UI and any timezone relevant >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> information >>>>>>>>>>> >>>>>>>>>>>> in >>>>>>>>>>>> >>>>>>>>>>>>> the >>>>>>>>>>>>>> >>>>>>>>>>>>>>> browser's >>>>>>>>>>>>>>>>>>>>> timezone. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> To resolve the issues in the invitations I would >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> suggest >>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> changes: >>>>>>>>>>>>>>>>>>>>> - When the user signs up the timezone is no more >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> editable/not >>>>>>>>>>>>> >>>>>>>>>>>>>> even >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> shown >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> maybe or read only and taken from the browser/client >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> os >>>>>>>>>> >>>>>>>>>>> - Everytime the user logs in the timezone field in >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>>> users >>>>>>>>>>>> >>>>>>>>>>>>> profile >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> updated with the current timezone of the >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> browser/client >>>>>>>>>> >>>>>>>>>>> os. >>>>>>>>>>> >>>>>>>>>>>> The idea might be that we add a new entry in the >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> table >>>>>>>>>> >>>>>>>>>>> OmTimeZone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> whenever >>>>>>>>>>>>>>>>>>>>> we detect any user with a new timezone. >>>>>>>>>>>>>>>>>>>>> - Login view the Flash application will no more be >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>>> The >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Openlaszlo application will only be used for the >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> conference >>>>>>>>>>> >>>>>>>>>>>> room >>>>>>>>>>>>>> >>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> By doing that it should basically all just work fine. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> But now comes the elefant :) We need a mapping between >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> iCal4J >>>>>>>>>>>> >>>>>>>>>>>>> timezones >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> java.util.Timezone. >>>>>>>>>>>>>>>>>>>>> iCal4J is using net.fortuna.ical4j.model.**TimeZone >>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> we >>>>>>>>>> >>>>>>>>>>> only >>>>>>>>>>>> >>>>>>>>>>>>> have >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> java.util.TimeZones. This is the historical reason why >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>>> code >>>>>>>>>>>>> >>>>>>>>>>>>>> is a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> little >>>>>>>>>>>>>>>>>>>>> bit messed up with various timezone calculations and >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> fallbacks. >>>>>>>>>>>>> >>>>>>>>>>>>>> So it will be a major refactoring that should be >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> planned >>>>>>>>>> >>>>>>>>>>> and >>>>>>>>>>>> >>>>>>>>>>>>> broken >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> down >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>> several phases. >>>>>>>>>>>>>>>>>>>>> We will change and touch all and any kind of >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> functionality >>>>>>>>>>> >>>>>>>>>>>> in >>>>>>>>>>>> >>>>>>>>>>>>> OpenMeetings. >>>>>>>>>>>>>>>>>>>>> It will require quite a bit of regression testing to >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> check >>>>>>>>>>> >>>>>>>>>>>> if >>>>>>>>>>>> >>>>>>>>>>>>> nothing >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> broken. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We generall said refactorings like this are not part >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> of >>>>>>>>>> >>>>>>>>>>> OpenMeetings >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3.0. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> And once we start this there is no way back. It will >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> delay >>>>>>>>>>> >>>>>>>>>>>> any >>>>>>>>>>>>> >>>>>>>>>>>>>> potential >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> release by 1 - 2 months. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> What is the general opinion about this ? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> WBR >>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> WBR >>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Sebastian Wagner >>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> WBR >>>>>>>>>> Maxim aka solomax >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sebastian Wagner >>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>> http://www.webbase-design.de >>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>> seba.wag...@gmail.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> http://www.webbase-design.de >>>>> http://www.wagner-sebastian.com >>>>> seba.wag...@gmail.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Sebastian Wagner >>>> https://twitter.com/#!/dead_lock >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.com >>>> seba.wag...@gmail.com >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> seba.wag...@gmail.com >>> >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> seba.wag...@gmail.com >> > > > > -- > WBR > Maxim aka solomax > -- WBR Maxim aka solomax
