Fwd: [Kolab-format] Visibility of incidence infos in XFB-lists, was: Client behaviour regarding "Access" or better "information sensitivity"
bernhard at intevation.de
Mon Sep 20 17:17:58 CEST 2010
Feedback from a long-standing Kolab-/Kontact-operator:
---------- Weitergeleitete Nachricht ----------
Am Mittwoch, 8. September 2010 um 14:38:40 schrieb Bernhard Reiter:
> Am Dienstag, 7. September 2010 14:29:21 a long-standing
> Kolab-/Kontact-operator wrote:
> > IMHO the core issue with this "prominent" setting is (and always has
> > been) its label: There is not the slightest hint anywhere in the GUI,
> > that it deals with the scope of visibility of XFB-/FB-information
> > only.
> Just to be extra clear: It only has an effect now on the XFB
> information. There is _no effect_ on the FB info.
Well, first of all, this is a loosely related, but distinctively different
topic. Here the functionality of the setting is discussed, in contrast to
the original topic "keep the prominent placement of that setting or not".
NB: I will quickly dive into this other topic (functionality) for one
So if one sets this "Sensitivity" to "confidential" (=invisible), the time
and date of that IMAP-folder item (incidence type) will still be visible
via (non-extended, regular) FB-list (containing time & date only, that is),
but not via XFB-list?
If so, this is a modelling-flaw resulting in inconsistent functionality
(independent of the original topic "placement"), as the information one
intends to hide is easily obtainable for others: just trigger the
generation of an regular FB-list and download it. In an mixed client
environment this unintended information disclosure automatically happens,
as soon as MS-Outlook clients utilise this Kolab server (and its FB-lists).
Even more important is that this is inconsistent from the user's point of
view: if one does not intend to publish date & time of an appointment
(using the setting which is currently called "confidential") via
(X)FB-infos, that setting must suppress *all* (X)FB-data on all [kinds of]
IIRC this also was a requirement of the original Kolab customer, but it
never worked as intended due to aforementioned usability and technical
(scope does not include regular FB-list) issues: as a result the
(X)FB-lists are nowadays just used as an minor source of additional
information, rather than as a pivotal point for many calendar-based
The obvious and IMO "right" solution is to extend the scope of this setting
to FB-lists as well; the "wrong" alternative "solution" is to label this
setting "XFB-visibility" and to hide it (your original suggestion might
serve well, then); then it also would have to be accompanied by a tool-tip,
which clearly states that hiding the (basic) FB-infos this way does not
work, as they are obtainable for everybody with HTTP-access to that
In the following responses I assume, that the export of information to
regular FB-lists will be also covered by this setting.
Yes, I am aware that regular FB-lists cannot show the contents of an
IMAP-folder item (incidence type), hence the topmost two choices will be
equivalent for regular FB-lists.
> > I believe it should stay prominently (and separatly) placed, as it
> > would provide valuable ease of use in many XFB-based use-cases, if
> > only this setting would be labled with concise wording, so most
> > users intuitively understand it instead of being misled (which is
> > currently the case).
> Improving the wording was part of my proposal.
> Did you like the suggested words?
No, IMO they are almost no improvement to what we have already, as they
still avoid to clearly name what is happening; instead metaphors are used
again, which will be interpreted to mean something vastly different by
others: the same story/theme as before.
IMHO the category shall be labelled "Visibility in Free/Busy lists"
or "Relevance for Free/Busy lists" (I like the first one much better);
the choices may be called "Full content visible" / "Only date & time
visible" / "Invisible", alternatively, when using "Relevance" in the
label: "All content relevant" / "Only date & time relevant" / "Hidden".
An maybe even better alternative may be to use the label "Export to
Free/Busy lists:" with the choices "Full content" / "Only date &
time" / "Nothing".
Actually, I believe that is the best choice I came across yet.
> > It is definitely not a part of the regular IMAP-folder item
> > (incidence type) properties, due to the aforementioned fact that
> > it deals with the scope of visibility of XFB-information only.
> > Hence I believe this setting must not be merged into those IMAP-
> > folder item specific settings, as this would be mislead users again
> > to believe the setting would be a property of the IMAP-folder item
> > (and maybe affect its access rights for others).
> > But this setting sure has been in dire need of better UI-strings for
> > years.
> Again to be extra clear: Currently "sensitifity" does affect single
> objects so moving it to be reachable via the categories would keep this
> focus as the selection of categories also are per objects.
Oh, I never questioned the fact that this is "per object (= IMAP-folder
item, incidence type)": it definitely is!
My point is: it is a very special setting, which is solely specific for the
(X)FB-list visibility of that incidence item, so it shall not be
intermingled with other settings.
As said, it could provide a very valuable instrument for conveniently
controlling which data becomes published via (X)FB-lists, hence enabling the
long overdue proper and full use of (X)FB-lists.
> When there are more clients that can deal with several accounts and
> folders fully, the need for the use of those categories and even for XFB
> at all will vanish and then there will be only the ACL settings that
> affect the folders.
No not at all, as per account and per folder settings are way too coarse for
many use-cases and -models: with these one will never be able to properly
substitute per item settings.
The discussed setting is so unique, as it controls per item what information
is exported to the (X)FB-list: any setting which does not carry exactly
these properties will not work as a substitute.
P.S.: I changed the subject line , as 'Client behaviour regarding "Access"
or better "information sensitivity"' IMO does not at all point to that
More information about the format