[Tickets #14585] Re: horde/nag/lib/Nag.php : 1733 [getSyncLists()]: Wron serialized array in prefs triggers warning
noreply at bugs.horde.org
noreply at bugs.horde.org
Mon Feb 27 15:54:09 UTC 2017
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: https://bugs.horde.org/ticket/14585
------------------------------------------------------------------------------
Ticket | 14585
Updated By | Michael Rubinsky <mrubinsk at horde.org>
Summary | horde/nag/lib/Nag.php : 1733 [getSyncLists()]: Wron
| serialized array in prefs triggers warning
Queue | Nag
Version | Git master
Type | Bug
-State | Feedback
+State | Assigned
Priority | 1. Low
Milestone |
Patch | 1
Owners | Michael Rubinsky
------------------------------------------------------------------------------
Michael Rubinsky <mrubinsk at horde.org> (2017-02-27 15:54) wrote:
>>
>>> Do I need to configure something in horde to create default tasklists?
>>
>> Nope. This is done automatically when the user logs in. See
>> Nag::initialize(), which calls
>> Nag_Tasklists_Base::ensureDefaultShare().
>>
>
> Ah, in my case, auto-create was not enabled, it has to be enabled in
> the horde administration interface. Now the default shares are
> created as you describe. Thanks!
Shoot. Sorry about that. I totally forgot about that config option :)
> Back to the topic of this ticket:
>
> Can you verify my bugreport by the following steps?
> 1. In the horde configuration, set $conf['share']['auto_create'] = false;
> 2. delete _all_ tasklists including the default one
> 3. To to Nag user preferences -> synchronisation settings -> check
> "support separate tasklists" and save the pref.
> 4. Go Into the SQL Database and query: Select * FROM horde_prefs
> WHERE pref_value = 'a:1:{i:0;N;}';
>
>
> I think, that horde should be able to handle non-existent shares in
> an app correctly, since Hordes "auto-create" feature is an option
> and not mandatory.
> Therfore a fix should be applied not only to nag and mnemo (already
> done) but also to kronolith and turba.
>
> Now we know what causes the issue, we can either fix it as you did
> on the evaluation side of this horde pref ( getSyncXYZ() ), or we
> fix it at the creation side in the sync preferences where this value
> is stored into the preferences. The latter whould by better
> regarding performance...
Correct. I want to prevent the faulty data from being created in the
first place.
More information about the bugs
mailing list