Hi Ralf, Peter. On Friday 07 December 2007, Peter Eisentraut wrote: > Am Montag, 3. Dezember 2007 schrieb Ralf Becker: > > The releasenotes (www.egroupware.org/wiki/releasenotes1.4) contain a > > link describing the changes in addressbook > > (www.egroupware.org/wiki/AddresbookAccountsConcept) which contains at > > the end a link describing how to Update an LDAP based addressbook > > (www.egroupware.org/egroupware/index.php?menuaction=phpbrain.uikb.view_ar > >ti cle&art_id=57).
Ah. I did overlook that. I wrote a small perl-script to fetch the entries from LDAP and put them into SQL. I guess it depends on the number of Categories, which method is more work. > > As LDAP is used by quite a small percentage of our users (with usually a > > high sysadmin skill level), we choose to not provide a more automatized > > procedure for the upgrade. Still, from earlier releases an admin expects to just click "Update" in Setup after a Version-Upgrade. Of course I understand, why you thought your time would better be invested elsewhere. > > - Addressbook ACLs change meaning without notice, meaning people won't > > be able to read what they used to be able to. > > > > This might be an other documentation issue Absolutely. Ideally, in such cases, Setup would provide the admin with Options during the "update" process and act based on his decision. But at least it needs to be documented. > > - Shared folders no longer work with Felamimail and Courier IMAP. > > > > Unfortunately the FMail developer abandoned the current FMail codebase > > and noone else fixed that bug so far, thought I'm not even sure there's > > a bug report for it in the projects bug tracker. I have fixed this one in a very rough way in IMAPProtocol.php in our installation, but did not commit it, because it's almost certainly going to break different imap setups. Unfortunately, Lars did not respond when I asked him to comment on the patch and a better location to fix this, but above sentence seems to explain this. > > - icalsrv is completely broken. > > > > Really. You are talking about 1.4.002? Many people reported it working > > better then ever (specially with Lightning/Sunbird) in 1.4.002. There > > was a bug with one of the other iCal clients with the content-type, > > which was fixed after 1.4.002 in svn and which will be included in the > > next maintainance release 1.4.003 Calender works more or less the same as in 1.2 with IcalSrv, I guess (Using korganizer as client). The problem was infolog (something about uid translation). I needed to take patches from trunk/1.5 including a schema-change, to make it work again. Those patches came from you, Ralf, so I guess you know better than I, what I'm talking about. ;-) Of course, icalsrv should not have been included in the 1.2 debian packages, as it's stated in icalsrv.php, that it's experimental. Unfortunately, icalsrv.php was part of the stable release tarballs, which led to the wrong conclusions, I guess. The thing is, we are talking about the debian package here. Debian users certainly are used to a minimum of manual work after a package upgrade. Of course there are counter-examples (almost always web-apps), but I don't think it's acceptable to have the user fetch the solutions to a handfull of issues from a mixture of mailinglists, wikis, knowledgebasses, etc. I guess usually in the case of difficult upgrades, the new packages would be called app*-version (egroupware*-14) and contain a doc/README.upgrade to avoid accidental upgrades with unprepared users. Of course this has the disadvantage, that the old 1.2 packages are kept for a longer time without upstream support. Carsten
signature.asc
Description: This is a digitally signed message part.
