Closed Bug 290824 Opened 19 years ago Closed 18 years ago

data lost if auto-publish was turned off, then turned on again aand then adding a new event

Categories

(Calendar :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: dr.niemand, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20050203 Mozilla Sunbird/0.2

If you turn off auto-publish on a calendar and make changes to the calendar, the
changes are lost if you turn auto-publish on again and create a new event.

Reproducible: Always

Steps to Reproduce:
1.Turn off auto-publish
2.add an event (lets call it event 1 :))
3.turn auto-publish on again
4.add an event (event 2)
5.event 1 lost

Actual Results:  
only event 2 is saved not event 1

Expected Results:  
both events schould be published and saved.
*** Bug 295398 has been marked as a duplicate of this bug. ***
QA Contact: gurganbl → general
A similar issue... 

[Crossposted from netscape.public.mozilla.calendar 2005 11 02]

[snip]

I was able to reproduce the problem:

1. Disable internet connection
2. Add a task to a calendar connected to a remote server
3. Notice "updating" red circles appear
4. They don't go away.
5. Item does not appear in task list
6. Close Calendar
7. Open Calendar
8. Item does not appear in task list
9. Enable internet connection
10. "reload remote calendars" (twice, for some reason...)
11. Task is definitely gone.

This also happens for events.

The solution, in my mind, would be to create a separate file with 
"unpublished" events (or to somehow mark events in the existing files as 
unpublished) and an "unpublished events" flag in the list of calendars. When SunBird goes to refresh its calendars, it could check for this unpublished flag. If present, check out, add events, perhaps notify of conflicts, etc., toggle unpublished flag, check in, and continue on with life.

Johnathon 
Summary is now misleading when it says "auto-publish was turned off, then turned on again".  This makes the problem look like user error.  In fact it occurs in situations like the one Johnathon describes, where the user did nothing wrong.
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
I can't see any auto-publish option in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061201 Calendar/0.4a1

--------------->  WONTFIX?
No auto-publish control exists in the current products.

-> INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.