Open Bug 649944 Opened 10 years ago Updated 6 months ago

Confidential Events vs. "Show date and time only"


(Calendar :: Dialogs, defect)

Not set


(Not tracked)


(Reporter: adi, Assigned: mozilla)


(Blocks 1 open bug)


User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110323 Iceweasel/3.5.18 (like Firefox/3.5.18)
Build Identifier: 

There are three possible Confidentiality settings: Public, Private and Confidential. The first two are translated as "Public Event" and "Private Event". "Confidential" however translates to "Show date and time only" which is misleading, especially when working with CalDAV servers that allow specifying ACLs:
We're using SOGo where "Confidential" means: "hide this event from others" -- at least in the default settings. (see

IMHO "Confidential" should translate to "Confidential Event" as "Show date and time only" refers to an implementation detail.

Reproducible: Always
In English, "Private" and "Confidential" mean almost the same thing so the difference wouldn't be obvious.  Maybe there's a different way to fix the problem.
eh... "PUBLIC", "PRIVATE" and "CONFIDENTIAL" are the three predefined values for "CLASS"-classification in icalendar standard (RFC2445, p78f). This classification corresponds 1:1 to the above mentioned parts in the user interface.

On a more linguistic view on the problem, there is a difference between private and confidential: The Oxford Dictionary says “confidential” means “meant to be kept secret” or “not told or shared with other people” whereas "private" means "alone and undisturbed by others" or "not connected with one's work or official position".

And still, a certain way to implement handling those kinds of events ("Show date and time only") is erroneously taken in the user interface (and then translated).
I think the status could be update to confirmed as "confidential" is how it is defined in the RFC for access classification. 


It does seem like the UI could use some improvement here to make things clearer for users. Not sure exactly what that would be as it seems a bit complicated, involving server settings which are beyond the client's control. Assigning to who is interested in working on this.

Assignee: nobody → mozilla
Ever confirmed: true
Blocks: 1643605
You need to log in before you can comment on or make changes to this bug.