6.0.0-beta1
7/20/25

[#11438] Inconsistent behaviour of [share][hidden]
Summary Inconsistent behaviour of [share][hidden]
Queue Kronolith
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester mrubinsk (at) horde (dot) org
Created 09/20/2012 (4686 days ago)
Due
Updated 10/15/2012 (4661 days ago)
Assigned
Resolved 10/02/2012 (4674 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
10/15/2012 08:41:56 PM Git Commit Comment #5 Reply to this comment
Changes have been made in Git (develop):

commit bc6a5e7c030af4f87e0cc9a9967495d906532a62
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Tue Oct 2 18:24:25 2012 -0400

     Bug: 11438 - Honor conf[share][hidden] in both views and limit to 
share backed sources.

     This extends the timeobjects API so that 
listTimeObjectCategories() now returns
     an array of {'title': xxx, 'type': xxx } hashes. This way kronolith
     can only apply the hidden configuration to timeobject categories that
     are actually backed by shares or share-like resources.

  folks/lib/Api.php                   |    2 +-
  kronolith/lib/Calendar/External.php |   13 +++++++++++++
  kronolith/lib/Kronolith.php         |    9 +++++----
  nag/lib/Api.php                     |    2 +-
  timeobjects/lib/Api.php             |    2 +-
  turba/lib/Api.php                   |    4 +++-
  whups/lib/Api.php                   |    9 +++++----
  7 files changed, 29 insertions(+), 12 deletions(-)

http://git.horde.org/horde-git/-/commit/bc6a5e7c030af4f87e0cc9a9967495d906532a62
10/02/2012 10:32:44 PM Michael Rubinsky Taken from Jan Schneider
State ⇒ Resolved
 
10/02/2012 10:32:02 PM Git Commit Comment #4 Reply to this comment
Changes have been made in Git (master):

commit bc6a5e7c030af4f87e0cc9a9967495d906532a62
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Tue Oct 2 18:24:25 2012 -0400

     Bug: 11438 - Honor conf[share][hidden] in both views and limit to 
share backed sources.

     This extends the timeobjects API so that 
listTimeObjectCategories() now returns
     an array of {'title': xxx, 'type': xxx } hashes. This way kronolith
     can only apply the hidden configuration to timeobject categories that
     are actually backed by shares or share-like resources.

  folks/lib/Api.php                   |    2 +-
  kronolith/lib/Calendar/External.php |   13 +++++++++++++
  kronolith/lib/Kronolith.php         |    9 +++++----
  nag/lib/Api.php                     |    2 +-
  timeobjects/lib/Api.php             |    2 +-
  turba/lib/Api.php                   |    4 +++-
  whups/lib/Api.php                   |    9 +++++----
  7 files changed, 29 insertions(+), 12 deletions(-)

http://git.horde.org/horde-git/-/commit/bc6a5e7c030af4f87e0cc9a9967495d906532a62
09/21/2012 07:38:07 AM Jan Schneider Comment #3 Reply to this comment
Thinking about this some more, is there any special reason why we 
don't check for [share][hidden] in the parent application rather 
than in the client code? I.e., why don't we filter out the shares in 
within the listTimeobjects API method?
Because only the client application knows which shares are actually 
displayed. The flag is not to hide all shares, but to only show shares 
that have explicitly been selected to be displayed.
09/21/2012 12:20:50 AM Michael Rubinsky Comment #2 Reply to this comment
Thinking about this some more, is there any special reason why we 
don't check for [share][hidden] in the parent application rather than 
in the client code? I.e., why don't we filter out the shares in within 
the listTimeobjects API method?
09/20/2012 06:12:29 PM Michael Rubinsky Comment #1
Priority ⇒ 1. Low
Patch ⇒ No
Milestone ⇒
Assigned to Michael Rubinsky
Assigned to Jan Schneider
Summary ⇒ Inconsistent behaviour of [share][hidden]
Type ⇒ Bug
State ⇒ Assigned
Queue ⇒ Kronolith
Reply to this comment
When using dynamic view, and $conf[share][hidden] is set any calendars 
provided by the timeobjects API that are not backed by shares and 
"subscribed" to are hidden in the UI. I.e., it is impossible to select 
these for viewing.  When the timeobject is based on an actual share 
like an Address book that's fine since you can still "subscribe" to 
the share and have it appear, but if the timeobject provided via the 
API is not share based then it becomes impossible to ever see these 
calendars. For example, Whups provides timeobjects based on "My 
Tickets", not on individual shares and none of the objects provided by 
the timeobjects application is based on shares.

When viewing in the traditional view, the $conf[share][hidden] setting 
is ignored when building the list of available timeobject calendars.

So I think we need to:

(1) Fix the traditional view so that it honors the hidden setting.
(2) Add some new return value to the listTimeobjectsCategories API 
method that indicates whether or not the objects are share based and 
should be subject to filtering through the [share][hidden] setting.

Saved Queries