482110 - calendar stays hidden after adding event to it; new event not visible

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Stefan Sitter [:ssitter]]

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.

Comment 1

[Stefan Sitter [:ssitter]]

I think this is another regression from Bug 475715.

Comment 2

[Stefan Sitter [:ssitter]]

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.

Comment 3

[Decathlon]

Attachment: [short] patch-v1

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.

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 5

[Stefan Sitter [:ssitter]]

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

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 9

[Decathlon]

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

Comment 10

[Philipp Kewisch [:Fallen][📱📆]]

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?

Comment 11

[Philipp Kewisch [:Fallen][📱📆]]

comment 10

Comment 13

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Fix - v2

Sorry, I couldn't stop thinking about this bug. The solution was much easier than I thought, this should take care!

Comment 14

[Philipp Kewisch [:Fallen][📱📆]]

The last change is of course not needed, pretend its not there :)

Comment 15

[Decathlon]

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+

Comment 16

[Philipp Kewisch [:Fallen][📱📆]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/7dbc9c5c2b41>
-> FIXED

Comment 17

[Philipp Kewisch [:Fallen][📱📆]]

This bug was also pushed to comm-beta and comm-aurora, likely during the last merge.