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 |
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 toshare 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
State ⇒ Resolved
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 toshare 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
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?
displayed. The flag is not to hide all shares, but to only show shares
that have explicitly been selected to be displayed.
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?
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
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.