PhilipAchenbach at web
Sep 20, 2011, 8:39 AM
Post #2 of 6
(719 views)
Permalink
|
|
Re: [Davical-general] 0.9.9.5 regressions
[In reply to]
|
|
Hello Andrew,
Am 20.09.2011 um 12:22 schrieb Andrew McMillan:
> On Mon, 2011-09-19 at 21:02 +0200, Philip Achenbach wrote:
>>
>> I have updated my installation of DAViCal to 0.9.9.5 a few days ago
>> and have since encountered a few regressions. My setup is based on
>> Debian 5 (Lenny) and uses an Active Directory via LDAP as the user
>> provider. The users mainly use Apple devices (iOS 4.3, Mac OS X 10.6 +
>> 10.7), one uses Evoultion.
>>
>> Since the update, some of the user-records in the database have been
>> updated to become invalid: The fields "active" and "email" in the
>> table "usr" has been set to NULL (Should the "active" field really be
>> NULLable?). Additionally, the fields "displayname" and
>> "default_privileges" of the "principal"-table have been set to NULL.
>> Afterwards, those users did neither appear under active nor under
>> inactive users in the administration interface. A synchronization of
>> the LDAP tree with DAViCal (via the administration interface) did not
>> help here. So i modified the "active"-field manually to restore the
>> users. I have not yet found out which action triggered this update.
>> In a short test, the LDAP-related fix from git (Bug #3409180) did not
>> help here, and the problems don't sound exactly related, but if you
>> think this fixes the problem I might test it once again.
> [...]
> Unfortunately I don't have an LDAP server myself and nobody has asked me
> to provide support for any LDAP-based installations. I've had a few
> post-release fixes for LDAP things which were broken in 0.9.9.5 and was
> planning to release a 0.9.9.6 with the fixes that have been sent to me
> so far, but what you're saying here suggests that there might still be a
> few regressions nobody has told me about.
Possibly a first step could be to change the field "usr.active" to not allow NULL values. Then, there should at least be an error indicating when exactly this field is updated like this. This is just a guess, as I did not have a look at the code, yet.
> From one problem that was discussed on IRC earlier today it seems like
> the 'active/email/???' issue you see might occur in relation to changing
> details on the LDAP server, which suggests to me that the
> sync-during-logon might be at fault here. It would be good to get
> confirmation of that.
Sorry, but I did not change something on the LDAP server in the last few days. It also only appeared twice since the update (once affecting two users, once affecting only one), so I really don't have any idea what triggers this.
>> An other major problem I have is that the synchronization with the
>> iPhone does not work properly anymore: Changes made to existing events
>> are synchronized properly, but new events created with Apple iCal are
>> not synchronized to an iPhone. Another instance of iCal does receive
>> these new events, though. Events added with an iPhone are synchronized
>> to the server and appear on instances of iCal, but disappear from the
>> iPhone with the next synchronization. Any help appreciated!
>
> Do you have the iPhone set to "Sync All Events"? That seems to be the
> current working setting, which is changed from what once used to work
> best.
Thank you! That did the trick. Is there anything one can do to help you locating the problem with the other settings?
> I was recently contacted by an Apple developer and have fixed a bug
> (post 0.9.9.5) which he advised me of. That fix will be included in
> 0.9.9.6 that I was hoping to release this week, but it would also be
> good to receive some fixes to the LDAP bugs you're talking about here.
Maybe you could release 0.9.9.6 with the small database changes I pointed out above. If the problem would reoccur one would at least have an error message.
>> During my testing, the following errors appeared in the error-log
>> (don't know if they are related):
>>> davical: ***: ERROR:Could not recognize timezone "GMT +0100
>> (Standard) / GMT +0200 (Daylight)" - will use floating time
>> This error appeared quite often. I think it only appeared since the
>> update.
>
> This is more of a warning than an error. DAViCal doesn't really care
> about the timezone of an event, passing the event unmodified to the
> client. It's more to point out that you have something somewhere
> creating odd timezones.
Okay, that sounds possible as I have tested several clients over the last few years.
> I expect timezone handling to be assisted greatly over the next few
> versions by the timezone server implementation which will land in
> 0.9.9.6 (mostly done now) as we will have a full timezone definitions in
> place at that time, including database mechanisms for aliasing and
> localisation of timezones.
>
> The next version also adds a simple configuration setting which will let
> you manually alias an odd timezone like the one above to a more standard
> name like "Europe/Berlin" or something, but I'll try and make that
> better in future versions by moving it to a database, and (perhaps) even
> providing a centralised point where we can maintain aliases / localised
> zone names for everyone.
Yes, I have seen this in git. Thanks for your hard work with DAViCal!
Philip
_______________________________________________
DAViCal-dev mailing list
DAViCal-dev [at] lists
http://lists.davical.org/listinfo/davical-dev
|
signature.asc
