User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124) Gecko/20070914 Firefox/126.96.36.199 Build Identifier: Thunderbird v188.8.131.52 (20070728) / Lightning v0.7 build 2007101304 I've just created several new events but these events are not shown in the minimonth view. I compared them with older events and found out that they are only properly shown if the privacy has been set to 'Public Event' or 'Show Time and Date only'. If nothing has been set or 'Private Event' has been selected the event is not marked as bold in the minimonth view. Reproducible: Always Steps to Reproduce: 1. create new event 2. don't choose a privacy status or select 'Private Event' Actual Results: Event is not marked as bold in minimonth view. Expected Results: Event should be marked as bold in minimonth view.
Confirmed using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:184.108.40.206pre) Gecko/20071016 Sunbird/0.7. Minimonth doesn't mark days as busy (highlight in bold) if the day only contains all day events or events with privacy set to 'Private Event'. Question: intended behavior or bug?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: multi-day-events are not marked as bold in minimonth → Days with only all day or private events not marked as bold in minimonth
(In reply to comment #1) > Question: intended behavior or bug? IMO bug.
(In reply to comment #2) >> Question: intended behavior or bug? > IMO bug. Daniel, I'm not sure. We made the same deliberate decision in the event dialog, where all-day and private events are marked as 'Free' and not as 'Busy'. See http://wiki.mozilla.org/Calendar:SMB_Event_Dialog#Menu:_Options right at the bottom of the relevant paragraph. It is not exactly the same issue and I'm unsure of whether I would consider the issue in this bug report a real bug. I just want everyone to be aware of this fact.
Such intended behaviors should be configurable. I understand users not wanting whole day events being marked in minimonth, but I personally prefer it. Perhaps this might even be different depending on the calendar. Generally speaking: If it is not clear whether something is an intended behavior or a bug, it should be configurable.
(In reply to comment #5) > (In reply to comment #2) > >> Question: intended behavior or bug? > > IMO bug. > > Daniel, I'm not sure. We made the same deliberate decision in the event dialog, > where all-day and private events are marked as 'Free' and not as 'Busy'. > > See http://wiki.mozilla.org/Calendar:SMB_Event_Dialog#Menu:_Options right at > the bottom of the relevant paragraph. > > It is not exactly the same issue and I'm unsure of whether I would consider the > issue in this bug report a real bug. I just want everyone to be aware of this > fact. > IMO different bugs. The event dialog just presets the TRANSP of all-day events to transparent, i.e. those won't taken into account for free-busy by default. This does not disable users from specifying all-day events being opaque. The difference is that the event dialog makes a good default when creating all-day events while this bug is about showing busy all-day events, regardless whether those have been created by our app or not.
(In reply to comment #6) I think the current default of the event dialog is very common and sensible for most users; I wouldn't opt for additional prefs UI.
(In reply to comment #8) > (In reply to comment #6) > I think the current default of the event dialog is very common and sensible for > most users; I wouldn't opt for additional prefs UI. I didn't mean to change the event dialog, but the preferences dialog or the add calendar dialog. It could be configurable whether private / all-day events effect minimonth or not. If it is an option in the preferences dialog, it would effect all calendars, if it is part of the add calendar dialog, it could be different for each calendar.
Created attachment 317588 [details] even with normal event The mini-month view is not bold even with no privacy all day events
Looking at the option, Simon Paquet, it certainly seems that if you decide to define bolded days in the minimonth in this manner, your described behavior is correct. The presumable userland solution would be to mark all all-day events as "busy." Perhaps we can even get users to use it properly. I can certainly see this functionality as being more useful for users with very heavily used calendars. However, user expectation goes along the lines of other popular calendaring applications like Google Calendar, which, while they do have the notion of Busy/Free, do not factor this into their calculations with the minimonth. This functionality is most useful for people with very sparse calendars. I hold with those who think that this should be configurable, and I don't think that it makes any sense to pidgeon-hole the functionality one way or another. That being said, I don't consider this bug terribly high priority. Some user education, however, is in order.
Here's a piece of useful information, from comment 6 to bug 442029: ============= The default free/busy states can be controlled via advanced preference "calendar.allday.defaultTransparency". Set it to "TRANSPARENT" (free) or "OPAQUE" (busy). The current mini-month displays marks only days as bold that contain events marked as busy -> current behavior is as intended. Behavior is already under discussion in Bug 399761, resolving as duplicate. ============= This option is found here, in the now current version of Thunderbird: [Tools-->Options-->Advanced-->ConfigEditor] Now, if someone will point out the remaining preference[s], for "private" items or anything else that configures and sets the default for new event items as "FREE" . . . . I, for one, would have preferred the default install value to be "busy"/"OPAQUE", if only to make that mini-calendar report "days with events are bold", as opposed to "days both without busy events and without private events are not bold". As it is, I now have to remember this quirk, whenever I install the Thunderbird/LightningCalendar on a new machine.
You need to log in before you can comment on or make changes to this bug.