Version: unspecified (using Devel) OS: Linux As outlined in [1], Bernhard suggests to 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. The desktop version would also profit from the change. It also does affect usabiliy: * one extra button * high chance of missunderstanding on the button It seems that the concept of public, privat and confidential is also contradictory to the concepts of granted rights within a groupware structure. --- [1] Client behaviour regarding "Access" or better "information sensitivity" Bernhard Reiter Fri Aug 27 16:46:55 CEST 2010 http://kolab.org/pipermail/kolab-format/2010-August/000921.html Reproducible: Didn't try
For completeness, here's the e-mail I sent to kdepim about this: > > 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) Regards, Sérgio
And here's Bernhards reply: 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@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
IMHO out of scope of komo3.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of korganizer (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.