Open Bug 296178 Opened 19 years ago Updated 2 years ago

Renaming category does not update name in existing events/tasks

Categories

(Calendar :: General, defect)

defect

Tracking

(Not tracked)

People

(Reporter: tania.hide, Unassigned)

References

Details

(Keywords: uiwanted)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; isp 1706; SV1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20050203 Mozilla Sunbird/0.2

When I edit the name of a category (Tools:Options:General, then select category 
name and click Edit), the category name in the list is edited, but all the 
events that previously existed with that category name do not change.

In my case, I imported/entered a number of events and tagged them with the 
category "public holiday".  Then I wanted to change the category to "South 
African public holiday" to distinguish them from the US public holidays I 
wanted to also enter.

I edited the category "public holiday", changing it to "South African public 
holiday".  The category "public holiday" no longer existed in the menu(s) but 
all my existing events tagged with "public holiday" stayed as such and were not 
changed to "South African public holiday" as I expected.

It would be very useful to have this change made.  Now I have to go through all 
my public holiday events and change their category.  ugh.

Reproducible: Always

Steps to Reproduce:
1.enter several events, with the category "public holiday" selected
2.go to Tools:Options:General; select the category "public holiday" and click 
edit
3.Change the name of the category "public holiday" to "SA public holiday" and 
click OK.  Click OK to exit the Options dialog.

Actual Results:  
When I looked at the events by selecting "All Events" or restrict this with 
word "public".  You will see that all the old category: public holiday events 
still contain that category and that no categories contain "SA public holiday".


Expected Results:  
All the entries tagged with the category name "public holiday" should have been 
changed to reflect a category of "SA public holiday".  

Optionally:
It would be nice to have a kind of "warning system" that prompts the user:
There are events mapped to this category.  Changing the category name will 
change all those existing events.  Do you want to continue? (Yes) (Cancel)

Yes would then change all the existing "public holiday" events to "SA public 
holiday" and Cancel would revert back to the previous step (i.e., undo the 
edit).

I would not expect it be allowable to have events mapped to a category that no 
longer exists.


I have classified this as normal, not due to the severity but due to the fact 
that there is no practical workaround that is not seriously labour intensive.  
AND due to the fact that one is left with incorrect information.
This is what's happening for me:
1. Create event, select category
2. Edit the name of the category in Tools->Options
Result: The category of the event is set back to 'none'.
This is only happening if the chosen category is a standard category though.

If I do this:
1. Create a new category (or edit a existing one).
2. Create an event with that category.
3. Edit the name of the category in Tools->Options.
Result: What you described, the old name of the category is kept.

I'm not sure if the behaviour in my first test is another bug or if they are
related though.

I'm not sure how calendar is supposed to behave when a category is changed while
being used by events though.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050807 Mozilla
Sunbird/0.2+
Confirming this as an enhancement request.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
QA Contact: gurganbl → sunbird
There is another bug with the categories that is really an old one - the application does not take the category names from the categories.properties file as it should - instead the category names must be hard-coded or what.
While this is not even noticable for English-speaking users, it is a nightmare for users of localized builds.
How to replicate this? Change "categories" value in categories.properties to "cat1,cat2,cat3" and install Calendar/Sunbird/Lightning.
The available categories won't be those three but the default, but hardcoded ones.
Maybe a new bug must be filed for this.
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
I think severity of this bug should be changed into minor. It's not only 'Enhancement'...
Severity: enhancement → minor
Component: Sunbird Only → General
QA Contact: sunbird → general
Summary: Editing category name does not change name in existing events → Renaming category does not update name in existing events/tasks
How come this is minor? a person with many events filed under the same category needs to manually go through all these events and change them.

I think this should get higher priority.
Flags: wanted-calendar0.8?
Flags: wanted-calendar0.8? → wanted-calendar0.8+
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Unfortunately this is not very easy to do. The categories are not saved with some unique ID, so if you change the category name we would have to go through all events in all calendars and look for events that have that specific name. You won't be able to catch category names that mean the same thing but are in a different language, and it will potentially take a very long time. Also, you might not want to apply this change to all of your calendars, i.e you have business calendars.

We would need some advanced UI to fix this bug, which I doubt is going to happen for 1.0. I'm happy to consider if someone is willing to fix and a good UI concept evolves.
Flags: wanted-calendar1.0-
Keywords: uiwanted

This bug is still in Thunderbird 68.1.

An (pre selected) option "Change categories in calendars" in the "Edit Category" window together with the mentioned function would be very nice. I understand that only a look up for the old category name string is possible and this may not handle all corncer cases perfectly, but this still should avoid a lot of manual work.

It seems to me that Bug 613351 is a duplicate of this one.

Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.