| Summary | Wrong initial sync_calendars preference |
| Queue | Kronolith |
| Queue Version | 4.0.4 |
| Type | Bug |
| State | No Feedback |
| Priority | 2. Medium |
| Owners | |
| Requester | lauffer (at) ph-freiburg (dot) de |
| Created | 05/13/2013 (4448 days ago) |
| Due | |
| Updated | 06/10/2013 (4420 days ago) |
| Assigned | 05/13/2013 (4448 days ago) |
| Resolved | 06/10/2013 (4420 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | Yes |
doesn't mean that it isn't set though. Please check this.
We did not touch the default_share settings. And yes, that is the
problem: Why does getDefaultCalender() return foreign calendars.
I guess the answer is in lib/Kronolith.php line 1378, 1379:
static public function getDefaultCalendar($permission =
Horde_Perms::SHOW, $owner_only = false)
owner_only is default false. Maybe this shouldn't be the default here?
Our idea was not to touch this since we don't know much about this
function and just to fix the prefs.php
State ⇒ Feedback
user's calendar? Do you have that set in the default_share preference?
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Wrong initial sync_calendars preference
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ Yes
New Attachment: kronolith-sync_calendars.patch
State ⇒ Unconfirmed
In conf/prefs.php round about line 278 we set the sync_calendars
preference if unset/empty:
if (empty($sync)) {
$GLOBALS['prefs']->setValue('sync_calendars',
serialize(array(Kronolith::getDefaultCalendar())));
}
This may end in a wrong entry if the user has other calendars (f.e.
shared ones by other users), too. In our cases our customers f.e. got
its 1st foreign calendar synced.
This wrong entry will not be shown in the webfrontend.
We fixed the problem with just use calendars owned by this user:
$GLOBALS['prefs']->setValue('sync_calendars',
serialize(array(Kronolith::getDefaultCalendar(Horde_Perms::EDIT,
true))));
What do you think? Is this bugfix ok?