search

jrchoo / pe

0 stars 0 forks source link

Editing causes previous tags to be cleared #7

Open jrchoo opened 9 months ago

jrchoo commented 9 months ago

It can be quite troublesome for a user to repeated type in previous tags along with the new tags if they want to update the tags for one of their contacts. Maybe it would be a good idea for older tags to be preserved?

image.png

image.png

Steps:

  1. edit 7 t/friend
  2. edit 7 t/classmate
nus-se-bot commented 9 months ago

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Tags replaces existing tags

As shown below, editing the tags replaces all existing tags. This appears to be a documentation bug - in which there should be a warning for users when editing tags.

Severity is low because despite the loss of data, tags are generally more carefree and probably doesn't contain very important info.

Before:

image.png

After:

image.png

[original: nus-cs2103-AY2324S1/pe-interim#3697] [original labels: severity.Low type.DocumentationBug]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thank you for bringing this up. We do acknowledge the limitations of our current implementation for updating the tags of a contact in CampusConnect. However, from our point of view, executing the edit command otherwise meant that you are changing the existing values for that particular field of your contact as per the layman definition of edit. We do acknowledge that if users were to add extra tags on top of the existing ones, they will also have to type in the edit command, e.g. John Doe, first index of CampusConnect has an existing tag friend. User wishes to add an extra tag floorball buddy. User has to enter edit 1 t/friend t/floorball buddy so that the original tag friend is kept. At the current state, we decide to follow the layman definition of edit for the implementation of edit command. Definitely, we could have made it clearer in our UG. Since this may apply to quite a handful of users, this is definitely an issue of a higher severity.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: [replace this with your explanation]

## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]