Fri, 10 Apr 2026 09:35:39 +0000 https://bugs.horde.org/ticket/3032 WebDAV / iCal support for Kronolith This patch adds support for using a Kronolith calendar over WebDAV. It simply combines the existing features such as import/export of iCalendar files and the Horde WebDAV server. Currently it only supports GET and PUT, I've tried to create a simple PROPFIND but wasn't yet succesfull. It is however already usable in it's current state. I'm using it for my own calendar in combination with Sunbird on different Horde installations. Thu, 24 Nov 2005 10:16:12 +0000 https://bugs.horde.org/ticket/3032#t14016 I forgot to add some usage data :) - You have to make sure Kronolith is working properly (first adding / deleting e.d. should work through the web interface) - Make sure Pear's HTTP_WebDAV_Server is installed. The latest version has a bug which gives a parsing error on line 132, there is a trailing " there that should be removed. - The url to use is the following: (http/https)::/example.com/horde/kronolith/webdav.php/ Mark the trailing / after webdav.php. This is necessary if you use the latest version of HTTP_WebDAV_Server (how annoying). With version 0.99.1 it works also without the trailing / - If you wish to access a other calendar than the default (with the same name as your username), you can give this as a parameter: (http/https)::/example.com/horde/kronolith/webdav.php/calendar_name Thu, 24 Nov 2005 10:41:51 +0000 https://bugs.horde.org/ticket/3032#t14017 Just tested it in SunBird and everything seems to be working great. Migrated my own calendar from www.icalx.com to my own server running kronolith and it worked without any trouble. It would like to see that extra calenders could be given a name a bit nicer then display_cal=38a74970ff911afbc6bdada650df1d29 or something like that. But that is probably more a kronolith issue. Thu, 24 Nov 2005 10:55:09 +0000 https://bugs.horde.org/ticket/3032#t14021 I wasn't able to take an in-depth look yet, but I have a few comments already: 1) Great! 2) You should reuse the already existing ics.php. 2) You should include files where you need them, i.e. not in webdav.php/ics.php, BUT 3) You should already check there if RPC/webdav.php exists at all for BC reasons, because it has only been added in Horde 3.1. Thu, 24 Nov 2005 11:08:16 +0000 https://bugs.horde.org/ticket/3032#t14028 2) You should reuse the already existing ics.php. I don't see how this is possible... Currently this file does nothing more that download the calendar in the iCal format, the only possible solution would be to implement the webdav object in this file, but that's not really a good solution. Also in ics.php there is exactly the same code as in the api.php. I choose to only include the code from api.php to minimize redundancy of the code. If you mean that I should have named webdav.php ics.php, I didn't do that because I didn't want to overwrite existing code. If this is committed into CVS, I also don't see the use of the ics.php anymore, because the WebDAV module can do exactly the same and more... 3) You should already check there if RPC/webdav.php exists at all for BC reasons, because it has only been added in Horde 3.1. I don't really understand what you mean, I've written this patch using the latest CVS from Kronolith, but with the existing stable Horde 3.0.6/3.0.7. This RPC / webdav is already present there, however, I haven't seen any component yet that uses it. Thu, 24 Nov 2005 11:25:50 +0000 https://bugs.horde.org/ticket/3032#t14029 > If you mean that I should have named webdav.php ics.php, I didn't do > that because I didn't want to overwrite existing code. If this is > committed into CVS, I also don't see the use of the ics.php anymore, > because the WebDAV module can do exactly the same and more... Exactly, that's what I was talking about. There is no need to keep the current ics.php if webdav.php provides the same features, but we also don't want another script. > 3) You should already check there if RPC/webdav.php exists at all for > BC reasons, because it has only been added in Horde 3.1. > > I don't really understand what you mean, I've written this patch > using the latest CVS from Kronolith, but with the existing stable > Horde 3.0.6/3.0.7. This RPC / webdav is already present there, > however, I haven't seen any component yet that uses it. My fault, I thought I only added the webdav driver in 3.1. But it still doesn't make sense to make this work with Horde 3.0, because the 3.1 driver already implements PROPFIND for example. So you should rely on Horde 3.1, reuse what's there, detect it, and simply send an HTTP error to the client if you recognized an older version. Thu, 24 Nov 2005 11:39:54 +0000 https://bugs.horde.org/ticket/3032#t14030 >My fault, I thought I only added the webdav driver in 3.1. But it still doesn't make > sense to make this work with Horde 3.0, because the 3.1 driver already > implements PROPFIND for example. So you should rely on Horde 3.1, reuse > what's there, detect it, and simply send an HTTP error to the client if you > recognized an older version. Hmm, I've looked into this and I see how PROPFIND could be handled better :). I'll try to create a new version somewhere in the next week or two, I'm really busy so I hope I have some time for it. I'll also make it dependant on Horde 3.1 and use ics.php as the filename for the interface. Thu, 24 Nov 2005 11:58:58 +0000 https://bugs.horde.org/ticket/3032#t14031 > Hmm, I've looked into this and I see how PROPFIND could be handled > better :). I'll try to create a new version somewhere in the next Great, patches are welcome. The webdav support is still incomplete, so any help to finalize this would be awesome. Please note that whatever you change must not break "regular" webdav access through /horde/rpc.php. I'm also curious how you solve the problem that clients provide there own "file names" when PUTting data to the webdav server that we can't use internally in Kronolith. But I'll probably find out if I actually look at your code. ;) Thu, 24 Nov 2005 12:06:18 +0000 https://bugs.horde.org/ticket/3032#t14032 > Great, patches are welcome. The webdav support is still incomplete, so > any help to finalize this would be awesome. Please note that whatever you > change must not break "regular" webdav access through /horde/rpc.php. I'm wondering whether it would be possible to also model this in the generic webdav access. Essentialy it is nothing more that a list of file that are icalendar files. Problem only is that which files will be there should be dependant on the authentification, don't think it would be really nice to be able to see other people's calendars, albeit only the file/calendar name. I also don't know what the policy is here, so whether this is even wanted or that a seperate interface file is a better solution. > I'm also curious how you solve the problem that clients provide there own > "file names" when PUTting data to the webdav server that we can't use > internally in Kronolith. But I'll probably find out if I actually look at your code. ;) Currenty nothing really happens ;) This patch is really something to get it to work, I was really getting frustrated with the fact that these solutions where not really available. I've tried Open-Xchange, but here the calendar didn't let me delete events over iCal/WebDAV and their webmail interface is really crap. I then saw the ics.php file in the latest cvs and saw how easy it wat, so I made this thing quickly so I can use it for my personal use and the study association where I'm a member of. The main reason I committed it, is because I saw more people having the same problem, I also noticed similar requests on the Horde mailing lists. Thu, 24 Nov 2005 12:21:33 +0000 https://bugs.horde.org/ticket/3032#t14033 > I'm wondering whether it would be possible to also model this in the > generic webdav access. Essentialy it is nothing more that a list of That should be the final goal. > file that are icalendar files. Problem only is that which files will > be there should be dependant on the authentification, don't think it > would be really nice to be able to see other people's calendars, > albeit only the file/calendar name. I also don't know what the policy > is here, so whether this is even wanted or that a seperate interface > file is a better solution. Just take a look at how webdav browsing works in HEAD currently. It shows you the calendars and events depending on the permissions you have, exactly like the regular UI, or the API (which is actually used to build the listings). > Currenty nothing really happens ;) This patch is really something to > get it to work, I was really getting frustrated with the fact that > these solutions where not really available. I've tried Open-Xchange, > but here the calendar didn't let me delete events over iCal/WebDAV > and their webmail interface is really crap. This might be much easier if using CalDAV or GroupDAV which is supported by at least KDE's and Gnome's calendar clients, unfortunately not yet by Sunbird. Thu, 24 Nov 2005 12:51:03 +0000 https://bugs.horde.org/ticket/3032#t14035 > Just take a look at how webdav browsing works in HEAD currently. It shows > you the calendars and events depending on the permissions you have, > exactly like the regular UI, or the API (which is actually used to build the > listings). I wonder whether it would be possible to simply change this behaviour... Meaning that beneath the kronolith directory through webdav there are only iCal files instead of directories with events. This means only changing the _kronolith_browse function in the api. Using the registry to also call specific methods in the Kronolith api when GET and PUT are used, much in the same way as PROPFIND now (using the browse function). Changing my patch to do this would probably be not very hard, i've allready written the api functions there. This entire idea is ofcourse not very useful if the webdav implementation in it's current state is already used for other purposes, but I think most people would like this new behaviour. It also is very integrated in the current structure :) Thu, 24 Nov 2005 22:31:24 +0000 https://bugs.horde.org/ticket/3032#t14067 > 1) Great! I just want to echo this. I'm really looking forward to seeing this get into CVS. Thu, 24 Nov 2005 22:32:27 +0000 https://bugs.horde.org/ticket/3032#t14068 Hmm, some things might not be very clear form my last comment :) What I mean is that it might be a good idea to change the PUT and GET functions in HTTP_WebDAV_Server_Horde, so it is possible to also call a function through the registry. This way, it's possible to implement the PUT and GET functionality for the iCal calendars. Thu, 24 Nov 2005 22:36:36 +0000 https://bugs.horde.org/ticket/3032#t14071 Regarding PUT/GET: GET is already implemented and works fine. Go with any webdav browser (cadaver, konqueror, etc) to /horde/rpc.php. PUT is missing yet, mostly because the reasons I mentioned (having to map PUTted file names to object IDs in Horde). If is going to be added, it should use the APIs' import() methods. Regarding directories: why do you want to have a flat webdav directory structure? How do you want to specify which calender PUTted events should go to? Fri, 25 Nov 2005 00:22:33 +0000 https://bugs.horde.org/ticket/3032#t14085 I saw that GET is already implemented, however, it just gives empty files if I download a calendar event. On the second issue: iCal over WebDAV works very simple, with a GET you retrieve a single iCal file which represents the entire calendar. With a PUT you upload the same sort of file. There is no really advanced handling of single events e.d. That is the reason I would then like to change the behaviour of the kronolith webdav browser, so it only gives you these single files for each calendar instead of a directory with events beneath it. Because of this change, it would also be necessary to change the GET and PUT function for kronolith, because those function should then export en import the iCal data. That's the reason behind the idea of using different function for this trough the registry... Fri, 25 Nov 2005 09:58:49 +0000 https://bugs.horde.org/ticket/3032#t14093 Maybe it is a better idea to keep my current patch pretty much as is, and use the current WebDAV implementation as a basis for CalDAV support, where a calendar is a collection and events are single resources. This would make it possible to use both clients that only support iCal over WebDAV and not (yet) CalDAV. Fri, 25 Nov 2005 10:07:25 +0000 https://bugs.horde.org/ticket/3032#t14094 > I saw that GET is already implemented, however, it just gives empty > files if I download a calendar event. Hm, works fine here. Did you try with Horde from HEAD? > On the second issue: iCal over WebDAV works very simple, with a GET > you retrieve a single iCal file which represents the entire calendar. > With a PUT you upload the same sort of file. There is no really > advanced handling of single events e.d. That is the reason I would > then like to change the behaviour of the kronolith webdav browser, so > it only gives you these single files for each calendar instead of a > directory with events beneath it. Ah, I didn't know that. I only worked with GroupDAV/CalDAV so far and didn't notice that WebDAV calendar clients only work with a single iCal file. It makes sense then to keep two separate entry points, just like they are now and only try to share as much code as possible. > Because of this change, it would also be necessary to change the GET > and PUT function for kronolith, because those function should then > export en import the iCal data. That's the reason behind the idea of > using different function for this trough the registry... As import() already deals with single as well as multiple events in one iCal file, we should be able to use only one PUT implementation for both scenarios. GET is already implemented in ics.php anyway. Fri, 25 Nov 2005 10:16:19 +0000 https://bugs.horde.org/ticket/3032#t14095 > Hm, works fine here. Did you try with Horde from HEAD? I've tested it with the HEAD snapshot from yesterday... I do see file sizes with each event, but I get zero bytes when I download it. I've looked into the code of the webdav server and I see no output being printed or echo'ed in the GET function, which is how de PEAR WebDAV implementation works from what I've seen. Fri, 25 Nov 2005 20:53:18 +0000 https://bugs.horde.org/ticket/3032#t14118 rpc.php and Horde_RPC_webdav are taking care of that. Fri, 25 Nov 2005 21:17:16 +0000 https://bugs.horde.org/ticket/3032#t14121 Well, I can't find it then... HTTP_WebDAV_Server_Horde extends HTTP_WebDAV_Server and in this class the GET method doesn't return anything, which it sould, because rpc.php simply calls Horde_RPC_webdav->getResponse(), which in it's turn uses ServeRequest() on the HTTP_WebDAV_Server... This last method is the default HTTP_WebDAV_Server method, which expects the GET function to return the content of the file. I also checked with the latest files on cvs.horde.org and they are the same (last change is from six weeks ago). I guess I'm then missing something somewhere. Fri, 25 Nov 2005 21:39:18 +0000 https://bugs.horde.org/ticket/3032#t14124 Because I was wrong. Due to the, *cough*, interesting implementation of HTTP_WebDAV_Server, http_GET() is actually echo'ing the output. Fri, 25 Nov 2005 21:48:31 +0000 https://bugs.horde.org/ticket/3032#t14125 I've found the problem... It was a stupid bug in the api.php from kronolith. On line 225 it said: $modified = _modified($event['uid']); instead of: $modified = _modified($event->getUID()); When I changed this, I can download the calendar events, pretty stupid it doesn't give any error message, it simply stops at the function call. I do have error_reporting on E_ALL, so why it doesn't complain about anything, I don't know... Fri, 25 Nov 2005 22:20:07 +0000 https://bugs.horde.org/ticket/3032#t14126 I wonder why it worked for me then... Anyway, fixed in CVS. Fri, 25 Nov 2005 22:32:41 +0000 https://bugs.horde.org/ticket/3032#t14127 Ah, that's nice :) Currently, I have two ideas for building the webdav/ical support into this. I can add files with the name calendar.ics in the listing of kronolith (so you get something like the following): calendar_name/ calendar_name.ics other_calendar/ other_calendar.ics Or another solution is seperating it into different parts of the tree structure: kronolith/webdav/calendar_name.ics kronolith/caldav/calendar_name/ I've also looked a bit more into to CalDAV, but the problem of putting events seems rather simple. First, you have to put it into a existing calendar directory. If you want to put it into a new calender, you first have to create a new calendar with MKCALENDAR (part of the CalDAV spec), and then put it into the folder which is created with the MKCALENDAR command. For adding calendar's with WebDAV, it should be simply creating a calendar with the (part of) the file name (so calendar_name for calendar_name.ics). After this, the data of the file can be imported (or does the import already create a new calendar if it doesn't exists?). I think it is still necessary that the Horde WebDAV class uses some registry function for PUT, so it is possible to call the import function with the necessary parameters. I don't see how this could really be solved using the current browse function. Just another question, how mature is the CalDAV support, or is it in it's current state nothing more that getting events? Fri, 25 Nov 2005 22:52:10 +0000 https://bugs.horde.org/ticket/3032#t14128 Today I've made some new changes, which implement the first solution I presented in my last comment. It adds in the file listings next to the directory representing a calendar, also a file with the same calendar name and the .ics extension. Currently it uses the exportCalendar api function which was already created for ics.php. For PUT it uses a system where the _kronolith_put function is called through the registry. This means that other applications, such as turba, can also use a _turba_put function in their api. The PUT function calles the import function in the api so the calendar data is imported. I've chosen not to directly call the input, mainly because it could work for kronolith, but I can imagine that other applications cannot work with the import directly. This is mainly because the totally different concepts that are used in the import and put. PUT is based on a path with some file content, which is radically different from importing a certain element in a application. For this reason, I think the usage of an extra function is legitimate. Although I use the import function directly now, I think it would be nicer to use a seperate function for importing a iCalendar file in total. This is because a PUT with a iCalendar file currently results in the entire calendar being deleted and afterwards the elements from the file are added again. This is because otherwise no elements can be deleted (import only allows for adding). Another disadvantage is that every entry is therefore seen as being modified on a PUT. A better solution would be a seperate function that check for each element if it has changed / added / deleted and modifies these entries accordingly. Sun, 27 Nov 2005 19:47:52 +0000 https://bugs.horde.org/ticket/3032#t14155 > this. I can add files with the name calendar.ics in the listing of > kronolith (so you get something like the following): That's my favourite solution too. > For adding calendar's with WebDAV, it should be simply creating a > calendar with the (part of) the file name (so calendar_name for > calendar_name.ics). After this, the data of the file can be imported > (or does the import already create a new calendar if it doesn't > exists?). No, I don't think we should support adding of calendars through WebDAV. It's not such a burden to request users to create calendars first before using them from an external client. > Just another question, how mature is the CalDAV support, or is it in > it's current state nothing more that getting events? It doesn't exist yet. It's based on WebDAV, that's why I started implementing that first. Next would have been GroupDAV, and CalDAV at the last because it's the most heavy-weight DAV solution. Mon, 28 Nov 2005 16:25:12 +0000 https://bugs.horde.org/ticket/3032#t14258 > The PUT function calles the import function in the api so the > calendar data is imported. I've chosen not to directly call the > input, mainly because it could work for kronolith, but I can imagine > that other applications cannot work with the import directly. This is > mainly because the totally different concepts that are used in the > import and put. PUT is based on a path with some file content, which > is radically different from importing a certain element in a > application. For this reason, I think the usage of an extra function > is legitimate. Makes sense. > Although I use the import function directly now, I think it would be > nicer to use a seperate function for importing a iCalendar file in > total. This is because a PUT with a iCalendar file currently results > in the entire calendar being deleted and afterwards the elements from > the file are added again. This is because otherwise no elements can > be deleted (import only allows for adding). Another disadvantage is > that every entry is therefore seen as being modified on a PUT. A > better solution would be a seperate function that check for each > element if it has changed / added / deleted and modifies these > entries accordingly. I think we can live with this disadvantage. GroupDAV and CalDAV probably deal with that situation anyway. I added a PDF to http://wiki.horde.org/Doc/Dev/DAV with slides from a meeting with the GroupDAV guys on this year's LinuxTag, in case you're interested. Mon, 28 Nov 2005 16:39:43 +0000 https://bugs.horde.org/ticket/3032#t14262 Just to summarize what my current version does: - List a file named calendar_name.ics in the PROPFIND listing - Being able to fetch this file with a GET - There is automatically a file for a calendar created for that user with the same username if it doesn't exists yet. This is the same behaviour as the web interface. - Being able to PUT a file - When this file doesn't exists, a new calendar is created with the given name and datatree_name - The web interface for adding a calendar also allows for setting the datatree_name (I named it Identifier), zo pretty urls are possible (no long hex codes). This checks for double id's e.d. and only allows numbers, characters, '-' and '_'. The last two points are maybe not something that is appropriate for Kronolith. The main reason I made these changes is that I primairly use external application and only the web interface for when I'm not on a system where I work regurlarly. This is also the case for the study association, who will also be using this patch. I can seperate the functionality into two different patches against the latest cvs snapshot, where only the second provides the functionality mentioned above (the last two points). Mon, 28 Nov 2005 19:20:15 +0000 https://bugs.horde.org/ticket/3032#t14287 > I can seperate the functionality into two different patches against > the latest cvs snapshot, where only the second provides the > functionality mentioned above (the last two points). That would be great, because I'm indeed inclined to reject the two latter points. But I might get convinced. Thu, 01 Dec 2005 23:31:34 +0000 https://bugs.horde.org/ticket/3032#t14441 Hereby a number of patches against the CVS tree: horde_webdav_patches/framework_rpc.patch horde_webdav_patches/kronolith_api_put.patch horde_webdav_patches/horde_rpc.patch These three patches are for the basic iCal/WebDAV support. The first one patches the framework to include calling functions for PUTting files through the registry. The second one adds this function for Kronolith. The third patch is a patch for the rpc.php file. It changes the file so it doesn't read the input for webdav functions, this is handled through a stream in the PEAR HTTP_WebDAV_Server (this took me two hours before I found why it went wrong...). horde_webdav_patches/kronolith_api_put_with_new.patch horde_webdav_patches/kronolith_calendars_id.patch These two patches add some extra functionality. The first one creates a new calendar if a PUTted file has a name for which no calendar exists yet. The second patch allows for supplying an identifier for a new calendar. This identifier is used for naming the calendar file, I didn't like the hexadecimal filenames, therefore I created this. The first bunch of patches are really necessary, the second bunch is not really necessary, but I think they can be useful. Tue, 06 Dec 2005 11:27:46 +0000 https://bugs.horde.org/ticket/3032#t14557 Hereby a number of patches against the CVS tree: horde_webdav_patches/framework_rpc.patch horde_webdav_patches/kronolith_api_put.patch horde_webdav_patches/horde_rpc.patch These three patches are for the basic iCal/WebDAV support. The first one patches the framework to include calling functions for PUTting files through the registry. The second one adds this function for Kronolith. The third patch is a patch for the rpc.php file. It changes the file so it doesn't read the input for webdav functions, this is handled through a stream in the PEAR HTTP_WebDAV_Server (this took me two hours before I found why it went wrong...). horde_webdav_patches/kronolith_api_put_with_new.patch horde_webdav_patches/kronolith_calendars_id.patch These two patches add some extra functionality. The first one creates a new calendar if a PUTted file has a name for which no calendar exists yet. The second patch allows for supplying an identifier for a new calendar. This identifier is used for naming the calendar file, I didn't like the hexadecimal filenames, therefore I created this. The first bunch of patches are really necessary, the second bunch is not really necessary, but I think they can be useful. Tue, 06 Dec 2005 11:27:58 +0000 https://bugs.horde.org/ticket/3032#t14558 We will probably add another directory level with the share owners under kronolith/, the url for my birthday calendar would be rpc.php/kronolith/jan/birthdays.ics then. This allows to create new calendars through DAV without running out of unique share names because we could prefix the share name internally with the user/owner name then. E.g. if I create the calendar above its share name will be jan@birthday.ics or similar, and when showing the share through the DAV interface, jan@ will be removed again. A bit of black magic, but it allows to create calendars without risking name clashes and still having nice URLs. Thu, 06 Jul 2006 17:11:08 +0000 https://bugs.horde.org/ticket/3032#t21741 Finally committed, thanks a lot. The new paths still need to be done. Tue, 14 Nov 2006 18:30:21 +0000 https://bugs.horde.org/ticket/3032#t26058 Is there any body who have files webdav.php and webdavinc.php? I'm not find them on the CVS. Tue, 06 Feb 2007 19:28:24 +0000 https://bugs.horde.org/ticket/3032#t29217 > Finally committed, thanks a lot. Maybe I don't understand CVS (I use SVN for all my projects), but I can't seem to find these patches in CVS. For that matter, I can't find the 'webdav.php' I've seen mentioned as a basis for DAV ops in Horde. I just did a 'cvs co -r HEAD' on horde, kronolith, framework, etc. Do you have a separate repository where this has been committed? We're evaluation Horde vs. Zimbra, and I prefer Horde, but we really need remote (iCal or DAV) calendaring working. Sat, 31 Mar 2007 13:32:59 +0000 https://bugs.horde.org/ticket/3032#t31022 You can't be looking very hard, then :) framework/RPC/RPC/webdav.php http://cvs.horde.org/co.php?r=1.16&f=framework%2FRPC%2FRPC%2Fwebdav.php Graeme Sat, 31 Mar 2007 14:30:17 +0000 https://bugs.horde.org/ticket/3032#t31023 I have a simular situation. This function is really important to me. I am forced to run Thunderbird and Lightning is provides the ability to accept .ics meeting requests which then are added to Lightning. However, I have no way to MLSync my Treo Palm 700P. Horde / Kronolith provides this function. I have been searching to any documentation that would discribe how to setup Horde and Kronolith to be able to do this is. I have setup using CVS FRAMEWORK_3 branch and trying to apply these patches but the patches only partially succeed. I have set up CVS HEAD and thought from what I have been able to find to read that these functions have been added to HEAD. I am interested in understanding whether or not the patches are supposed to be applied to HEAD or not. Look in the patches it does not appear that the patches support the CVS HEAD. I would be happy to do a detail document if someone would be able to initially guide through. Thanks for all of the efforts being put in to this project. --Steve >> Finally committed, thanks a lot. > > Maybe I don't understand CVS (I use SVN for all my projects), but I > can't seem to find these patches in CVS. For that matter, I can't > find the 'webdav.php' I've seen mentioned as a basis for DAV ops in > Horde. I just did a 'cvs co -r HEAD' on horde, kronolith, framework, > etc. > > Do you have a separate repository where this has been committed? > We're evaluation Horde vs. Zimbra, and I prefer Horde, but we really > need remote (iCal or DAV) calendaring working. Sat, 31 Mar 2007 14:34:44 +0000 https://bugs.horde.org/ticket/3032#t31024 This is not a support forum. If you have questions, ask on the mailing list. If you want to sponsor development, go to the consulting or bounty pages. Sat, 31 Mar 2007 17:41:39 +0000 https://bugs.horde.org/ticket/3032#t31027 This is considered complete. The new path layout and whether it is really necessary has yet to be decided before the Horde 3.2 release. Tue, 26 Jun 2007 13:03:54 +0000 https://bugs.horde.org/ticket/3032#t34696 I decided to indeed add another directory level for the share owners. This is in line with the recent discussion about allowing users to specify their own share names, which has also been part of this request, see comment #28 and #30. This has to be applied to other share apps with webdav interfaces too. Wed, 09 Apr 2008 22:58:30 +0000 https://bugs.horde.org/ticket/3032#t44548 So with the new level for share owners, this can be closed, right? Fri, 11 Apr 2008 22:55:57 +0000 https://bugs.horde.org/ticket/3032#t44600 Saying yes. Please re-open if no, but for individual webdav bugs, please open new tickets. Tue, 15 Apr 2008 05:08:40 +0000 https://bugs.horde.org/ticket/3032#t44641 Yes, if this has been consistently applied to all share-apps in the meantime. Thu, 01 May 2008 17:30:25 +0000 https://bugs.horde.org/ticket/3032#t45027 there are open tickets for the other share apps with webdav support Thu, 01 May 2008 17:42:21 +0000 https://bugs.horde.org/ticket/3032#t45029