Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090307 Calendar/1.0pre In the past many users complained that they were unable to create events. Investigation showed that creation was successfully but the events were created in a calendar marked as hidden. Therefore the new event was not visible to the user. Sunbird 0.7 introduced the following behavior: If an event/tasks is added to a hidden calendar the calendar gets visible. This behavior is regressed in Sunbird 1.0pre. Steps to Reproduce: 1. Untick the checkbox for the selected calendar to mark it hidden 2. Create new event in the default calendar Actual Results: Calendar stays hidden, new event is not shown. Expected Results: Calendar is not hidden, new event is shown. This used to work in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090226 Calendar/1.0pre.
This regression has been introduced after the 0.9 release. It should be decided if it must be fixed before the 1.0 release or not.
IMHO this feature is useful, for an instant I thought there was a bug about new events creation. This patch restores the 0.9 version's behavior for new events and modified events.
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
Attachment #420058 - Flags: review?(philipp)
Attachment #420058 - Attachment description: patch-v1 → [short] patch-v1
I believe this was changed because of the cached calendar. onAddItem was called in cases that made sense for the caching mechanism, but were automated additions, not user controlled. This gave the user the feeling that having a calendar unchecked would not stick. Not sure how we should proceed on this one, I'll ask dbo when he comes back and would appreciate your opinion in the meanwhile.
You probably mean Bug 412963. Maybe split the behavior? If you (manually) add a new event the calendar gets visible and you see the new event. But if you modify an event (e.g. dismissing alarm) the calendar stays invisible (fixing Bug 405480).
We could surely split the behavior by checking if certain attributes changed, but that wouldn't help with the cached calendar. If a remote user adds an event to the calendar and the local cached calendar synchronizes, I believe onAddItem is also called. We can't differentiate between user adding items and the cache adding items atm. Doing so would probably break the encapsulation we currently have with the cache.
Attachment #420058 - Flags: review?(philipp) → review-
Comment on attachment 420058 [details] [diff] [review] [short] patch-v1 I don't think we can take this patch as it is due to the caching issue. I've pinged Daniel for an opinion, but this patch will probably a lot larger than expected to fix this issue correctly.
(In reply to comment #8) > (From update of attachment 420058 [details] [diff] [review]) > I don't think we can take this patch as it is due to the caching issue. I've > pinged Daniel for an opinion, but this patch will probably a lot larger than > expected to fix this issue correctly. OK, I change the status to NEW, so someone more skilled can take over the issue.
Assignee: bv1578 → nobody
Status: ASSIGNED → NEW
I think we can properly fix this by enabling the calendar from the UI side where needed: * Create a utility function that ensures a calendar is visible * From certain UI places (views, today pane, task mode, ...), call this function just before addItem is called This will keep the calendar hidden when in cached mode and still make it visible for the user when adding items. Decathlon, do you want to create a patch for this solution?
Whiteboard: [not needed beta][no l10n impact]
Sorry, I couldn't stop thinking about this bug. The solution was much easier than I thought, this should take care!
Whiteboard: [not needed beta][no l10n impact] → [not needed beta][no l10n impact][needs review]
The last change is of course not needed, pretend its not there :)
Comment on attachment 547954 [details] [diff] [review] Fix - v2 It seems working fine, for cached calendars too. It also fixes Bug 405480 if that one is the wanted behavior. r+
Attachment #547954 - Flags: review?(bv1578) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/7dbc9c5c2b41> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Whiteboard: [not needed beta][no l10n impact][needs review] → [not needed beta][no l10n impact]
Target Milestone: Trunk → ---
This bug was also pushed to comm-beta and comm-aurora, likely during the last merge.
Target Milestone: Trunk → 1.0b6
You need to log in before you can comment on or make changes to this bug.