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

RESOLVED INVALID

Status

Calendar
General
RESOLVED INVALID
13 years ago
12 years ago

People

(Reporter: HaMF, Unassigned)

Tracking

Details

(Reporter)

Description

13 years ago
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.

Comment 1

13 years ago
*** Bug 295398 has been marked as a duplicate of this bug. ***

Updated

13 years ago
QA Contact: gurganbl → general

Comment 2

13 years ago
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 

Comment 3

13 years ago
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

Comment 5

12 years ago
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
Last Resolved: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.