On Thu, 2009-10-15 at 09:09 +0200, Matthias Mohr wrote:
> Hi Andrew,
>
> > The problem was in release 0.9.7.2, and was (as Bruno Browning correctly
> > points out) due to my over-enthusiastic URL encoding causing Lightning
> > to discard the e-mail address for the principal as unusable.
> Well, I don't know if the calDAV RFC says anything about the encoding,
> but for me it's not unusual that the strings will be encoded and have to be
> decoded by the other side (Lighning).
> So I (now) unterstand that the problem started with the changes in 0.9.7.2
> - nevertheless I still think that Lightning could use some code which
> works with or without URL encoded strings...
No, it was definitely a bug in DAViCal. URL encoding should only encode
those parts of the URL which are not structural elements, so:
In
http://blah.blah.com/path/filename.ext you would only encode those
@, : and / characters that were (e.g.) part of the path or the
filename.ext.
So similarly in mailto:username at hostname.net I should only be encoding :
or @ if it occurs inside the username (and it can't occur inside the
domain name, by specification).
There were extensive URL encoding fixes in 0.9.7.2 which were correct -
I just got a little over-enthusiastic and did that one without thinking
it through like I have subsequently. This means that usernames with
spaces or @ characters will work now, for example, as well as similarly
complex calendar names, perhaps even containing a '/'.
> > This was fixed in 0.9.7.3, and a further fix for a problem maintaining
> > permissions was included in 0.9.7.4, both of which have now been
> > publicised further than IRC & twitter (which will inevitably be the
> > first to know).
> Thanks - I already found the 0.9.7.4 but did not have time to update my installation
> (I patched my installation a bit and I don't want to loose these changes - so I have
> to reintegrate them in the new version)
>
> BTW, are you interested in the patches?
> I don't know if they are relevant for somebody else, but they help here.
>
> One change is for treating all username case insensitive (including configuration
> parameter to switch this behaviour on or off)
> - this code works well (for our installation - getting the users by LDAP) and should also help others -
> but: I had to change one part in libawl which is hardcoded there, because libawl
> is unable to detect DAViCal settings...
> ... I'm not sure how to handle this, so I didn't provide it currently to the public.
I'm happy to take a look at it. There is also precedence for libawl
accessing the $c-> config object.
> Another change is (imho) totally needless for others.
> In my installation all group names start with ".Grp" to distinguish between users and groups.
> To make them always the first (or last), I changed the postgres sort order (I added a "USING ~<~")
I can understand the desire. Perhaps it would be useful to add a URL
parameter to restrict the list to only one type of user, and then this
might be less needed.
> The third change is/was for treating eMail addresses case insensitive.
> Most of that change is already present in DAViCal 0.9.7.2 - only one line was missing ;.-)
Well if there's a line I'm missing, please send it :-)
> And another change makes the GUI repsonses when "syncing with LDAP" a bit more logical (for me)
> - e.g. it doesn't tell you to deactivate already deactivated users...
I don't use LDAP myself so I have no idea whether the responses are
reasonable. If other LDAP users agree with your wording then I would be
only too happy to change it.
> My last change is that I totally rewrote the get_permissions PG/SQL method
> - I didn't understand the behaviour of the original one, so I defined the behaviour how I wanted it
> and the reprogrammed it.
> I also added some more convenience PG/SQL methods to query different things
> (and also to delete a user with all his resources)
> --> nothing special and mostly needless for others ;-)
Deleting a user is something that you can do through the Admin interface
from 0.9.7.3 onwards (though perhaps it might fail to work in some
circumstances I don't know about yet).
The permissions model is being completely rewritten now. This will mean
that your get_permissions will be entirely wrong for 0.9.8, and will
also very likely mean that the patch that attempts to translate
permissions from pre-0.9.8 version will not do the right thing. Such
are the perils of forking :-)
On the plus side the new permissions model lets you specify a default
access level, so that it is possible for users to declare that one
calendar is readable by any authenticated user, or that only freebusy is
available from there, etc.
> If you want, I could take some time and create patches for the above and send them to you....
Yes. I'm always interested in receiving clean, compartmentalised,
clearly explained patches. If they're really worthwhile I might
sometimes even relax my criteria in one of those dimensions :-)
Cheers,
Andrew.
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Does the turtle move for you? www.kame.net
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <
http://lists.morphoss.com/pipermail/davical-users/attachments/20091015/c01dca40/attachment.pgp>
-------------- next part --------------