[Kde-pim] Events, "Access" setting

Tue Sep 7 14:27:57 BST 2010

Am Samstag, 28. August 2010 13:43:39 schrieb Volker Krause:
> On Friday 27 August 2010 20:50:11 Sérgio Martins wrote:
> > 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.

Well, we could mark them to make this more visible,
but I believe that is the whole reason for tags (categories)
to exist: They should help us to treat groups of objects differently.

> > 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.

Sounds like a good use of the categories to me.
(And it means you already have "logic" attached to it.)
I probably would be an improvement to make a configurable "special" date
plugin that would display a number of events by a list of categories.

> > 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.

And all the other categories should also influence code.
(It is good to know though, I did not know about this effect about print.)
So how do I print my "private" events?

Again I would make categories and their usage configurable
and use categories. Then there is no special code for "sensitivity".

> > 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.

This might be too complicated thinking on your part. I guess the logic of 
categories is that they allow me to treat groups of objects differently.
So yes, I should think about where to use them. But if I use them, it would be 
quite uncool if they did not have an effect here or there in the future.

> > 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.

As explained this does not solve the issue that other Kolab Clients
do have a "privat" setting and they use it in a different way. 
To stay compatible, we have to show and allow the setting.
As I want to phase this out, I believe we can re-use the category
gui features for it. They would even fit a lot better.

The print logic of the desktop is really broken for people that believe
this access button really restricts access and then they do not see it in 
their printout, but when they use ACLs to give someone read access, this 
person will see the appointment. 

So your suggestion does not fully solve the problem 
(not for mobile and not for desktop).

> > (and about the access/sensivity wording, i totally agree)
>
> I fully agree with Sergio here, categories/tags don't have hidden meanings
> anywhere else,

They do as Sergio explained for birthdays and holidy. (Assuming he is right of 
course, I haven't tested it.) Again, I do not think this is hidden nor is it 
surprising in my view.

> 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).

No there is no danger, you have to explicitely give people access to an XFB.
Existence of the category would only hide some infos from it, so it gives
you another means to differentiate access, which I believe is unnecessary.
But again, we need it for backwarts compatibility. 

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100907/c4f456de/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/