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,
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
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
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
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
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
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
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,
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,
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
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:
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().
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_
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
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
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
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.comwrote:
I have: It is impossible to get User timezone (you only can get tz shift
and/or dst
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
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
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
The correct URL is http://timezonepicker.com/
On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.comwrote:
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
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 ?
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
23 matches
Mail list logo
