[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


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