Trying to edit the category name of a newly made category, also changed the category name of the also newly made sister category.
Steps I can reproduce it with:
1) Make a new category for testing.
2) Click fast on the green cross, to create 2 subcategories of this category.
3) Any edit to the first subcategory is copied to the second one, and vice versa.
Expected behavior would be for the edit to be contained to its target.
I am in Linux (Manjaro) with aw v0.8.4, using firefox.
I solved it by deleting and recreating the "second" sister category. Trying to delete the "first" of the 2 sister categories sometimes didn't work.
I don't understand the behavior. Please follow the issue template and provide step by step instructions to reproduce.
I don't understand the behavior. Please follow the issue template and provide step by step instructions to reproduce.
Sorry, I was in a hurry. I edited the post.
Alright, so this seems to happen when two sister categories have the same name (which happens when they are created in succession with their default name).
Fixing this could be done by opening the edit dialog for the user directly when a child category is created (which is what we should do anyway).
I agree! Having said that, how come you don't assign a specific id to each category for things like these? Much like a database works. I'd say it would be more future proof than basing action on category's name.
Actually having unique id's for identifying categories internally and separately having a "displayname" for every category that the user could change would also improve the logic in renaming backend-stored categories (which is a feature I'm currently working on.)
Good idea.
edit: now looking into the code, I think we actually do have numerical category id's internally. We just don't populate them. I'll look into this.
Alright, so this seems to happen when two sister categories have the same name (which happens when they are created in succession with their default name).
Fixing this could be done by opening the edit dialog for the user directly when a child category is created (which is what we should do anyway).
The issue I rasied actually has another bug too.The renaming of the first media category, and the subsequent error actually creates the new entertainment category shown in the gif.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
Actually having unique id's for identifying categories internally and separately having a "displayname" for every category that the user could change would also improve the logic in renaming backend-stored categories (which is a feature I'm currently working on.)
Good idea.
edit: now looking into the code, I think we actually do have numerical category id's internally. We just don't populate them. I'll look into this.