[Kde-pim] Events, "Access" setting

Volker Krause vkrause at kde.org
Sat Aug 28 12:43:39 BST 2010


On Friday 27 August 2010 20:50:11 Sérgio Martins wrote:
> Hi Bernhard,
>
> 2010/8/27 Bernhard Reiter <bernhard at intevation.de>
>
> > As outlined in [1] I suggest we remove the "Access" setting
> > from the event editor and implement a mapping of categories:
> >
> > Setting   Category
> > public <->  <none of the other>
> > private <-> private
> > confidential <-> confidential
> >
> > This is especially helpful for Kontact-Mobile where screenspace is even
> > more valuable than with the desktop Kontact. But I believe the desktop
> > version would also profit from the change.
>
> These are korg's categories on a new environment: Appointment,
> Birthday, Business, Education, Holiday, Meeting, Miscellaneous,
> Personal, Phone Call, Special Occasion, Travel, Vacation, [private?,
> confidential?].
>
>
> I really don't like the fact that some categories have hidden
> logic/magic associated with them, instead of just plain tags.
>
>
> For example, only a few weeks ago I discovered that events in the
> Birthday and Holiday category are displayed on kontact's special dates
> plugins.
>
>
> Currently korganizer uses the "Access" to hide stuff in the print and
> html export dialogs, so "private" and "confidential" would be two more
> categories that influence logic/code.
>
>
> Then, users will start asking questions like "What happens if I put
> this event in the Education category?", or "What's the feature
> associated with the Phone Call category?", and don't realize these are
> dummy.
>
>
> RFC2445 says it's up to the application to decide what to do with the
> classification field. Korg-desktop uses it in the print dialog. If
> korg-mobile doesn't have a print dialog I would suggest to simply
> remove this Priate/Confidential feature from the phone.
>
>
> (and about the access/sensivity wording, i totally agree)

I fully agree with Sergio here, categories/tags don't have hidden meanings 
anywhere else, so this would be highly surprising, especially when it comes 
to something sensitive (as Bernahrd points out on kolab-format, it could 
cause information to be "leaked" into an extended f/b list IIUC).

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100828/fa2e33d3/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list