Adding duplicate tag behavior doesn't make sense

[mesyeux]

Before executing command, first person already has tag "sweet"

Executing command

After executing "tag add selected -t sweet"

In the UG this is explained as "When adding a same tag to a person, the command will be executed successfully, but the same tag will not be added to the person". It doesn't make sense for a command to be executed successfully even though nothing is in fact changed within the application.

[nus-pe-bot]

Team's Response

First of all, the severity has been downgraded from medium to very low because the issue does not affect the usage of the tag feature and is purely textual (in the UG and command results).

Before we begin explaining the current behaviour of the tag command that you have highlighted, let us explain the design consideration behind it.

The tag command allows multiple tags to be added to multiple persons. Let me give you a scenario where 10 tags are added to 100 persons, and in the event that there are some duplicate tags for some persons, what would the command result then show?

We needed to keep the command result simple for all spectrums of the scenario, from adding 1 tag to 1 person to adding 10 tags to 100 persons. This was also explained as a design consideration for the tag command in our DG.

In our UG, we explained that:

There is nothing wrong with the command being executed successfully even though nothing is changed, furthermore, this was an intended behaviour already mentioned in the UG.

On top of that, after the command is executed successfully, whether or not anything was changed, the outcome of the command is the same. For example:

• Adding tag sweet to person Charlotte Oliveiro who already has sweet tag, will result in Charlotte Oliveiro with sweet tag.
• Adding tag sweet to person Charlotte Oliveiro who does not have sweet tag, will still result in Charlotte Oliveiro with sweet tag.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I do see the point of only showing the tags that are added instead of all the tags based on your explanation, but that wasn't the issue I raised.

The issue I raised was that the command is said to be successfully executed even if the tag already exists, which I believe is more of a feature flaw than a functionality/documentation bug, so I didn't consider the documentation part. Perhaps it was the phrasing of the documentation that made it slightly misleading - did you mean to say that the same tag won't be added twice? In that case, it is odd to inform the users/readers that the command was executed successfully and yet do nothing about it - an error message detailing the tag already exists would make much more sense. That's why I tagged it as a feature flaw as I think the design choice made here is slightly odd and could be more useful/less confusing to the users.

---

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Medium]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---