Differing /etc/roundcubemail/calendar.inc.php files

[Daniel Hoffend]

Good morning

Just because setup-kolab overwrites the default configuration doesn't 
mean that those options do not work. It's just the fact that the 
template used by setup-kolab is producing a small but working 
configuration. If you want to customize roundcube you're free to 
configure it to your liking by using the options provided in the default 
configuration.

The fact that you get config.rpmnew comes down to the rpm packaging. 
Maybe it would be better to deliver a calendar.config.php.dist instead 
of the .php version which the packaging tries to replace and ends up 
with a .rpmnew version to not kill your working configuration

Example:

Original:
http://git.kolab.org/roundcubemail-plugins-kolab/tree/plugins/calendar/config.inc.php.dist

Setup-Kolab Template:
http://git.kolab.org/pykolab/tree/share/templates/roundcubemail/calendar.inc.php.tpl

--
Regards
Daniel

------ Originalnachricht ------
Von: "Brady, Mike" <mike.brady at devnull.net.nz>
An: users at lists.kolab.org
Gesendet: 26.02.2014 09:32:15
Betreff: Re: Differing /etc/roundcubemail/calendar.inc.php files

>On 2014-02-26 20:51, hede wrote:
>>Am Wed, 26 Feb 2014 16:36:15 +1300
>>schrieb "Brady, Mike" <mike.brady at devnull.net.nz>:
>>
>>>The setup-kolab that comes with 3.2 overwrites the second file with
>>>the first file, so you loose all the new feature settings, but the
>>>roundcube calendar still works. Is this a bug? I will log a ticket
>>>for it if is.
>>
>>Maybe the new "features" are planned features, for the future.
>>Or maybe for development packages.
>>
>>I think they get overwritten because they are not needed,
>>e.g. useless for now. It's in the "default" config, because
>>this part seems to be some kind of 'finished a part of work'.
>>
>>For Example the 'calendar_freebusy_trigger'. There's plenty of code
>>referring some trigger in the php-files for roundcube. But at the end
>>it's calling an url '%s/trigger/%s/%s.pfb', where this kind of url is
>>actually unsupported by the kolab-freebusy web script in kolab 3.2.
>>Hence it's ok to have this configure option, but it's ok to remove it
>>for now.
>>
>>hede
>>_______________________________________________
>>users mailing list
>>users at lists.kolab.org
>>https://lists.kolab.org/mailman/listinfo/users
>
>But then there is calendar_contact_birthdays which does seem to work if 
>set to true and was part of the 3.2 announcement.
>_______________________________________________
>users mailing list
>users at lists.kolab.org
>https://lists.kolab.org/mailman/listinfo/users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/users/attachments/20140226/07c8f860/attachment.bin>