Add command does not allow empty tag

[shaunlxw]

Input: add n/roy e/s@ss m/A1234567X tl/john t/ Expected behaviour:

1. Command should either succeed and add person with no tags, OR
2. Commad should fail with output message specifying that tag cannot be blank/empty. (Current error message only mention that tags names should be alphanumeric.

[nus-pe-script]

Team's Response

No details provided by team.

The 'Original' Bug

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

edit command: inaccurate error message when multiple tags given with a blank tag

Input:

1. edit 9 t/ t/friend, or
2. edit 9 t/ t/

---

_{[original: nus-cs2103-AY2324S2/pe-interim#2508] [original labels: type.FunctionalityBug severity.Medium]}

Their Response to the 'Original' Bug

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

The error message is indeed correct, because a blank is not alphanumeric. It is also further stated in our UG that the TAG should only contain alphanumeric characters and spaces.

Severity Low because it only appears in very rare situations when users try to input blank tags.

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)

• [x] I disagree

Reason for disagreement: Not a duplicate because edit 1 t/ works without any bugs, but add ... t/ does not. The issue outlined in the 'original' bug lies with additional tag parameters supplied AFTER a blank tag, but the issue outlined in this issue is just a blank tag alone.

Also, different expected behaviour as edit. In the UG of edit (last bullet point of notes, screenshot included below), it is stated that blank tags are allowed.

No mentions of blank tags for add command in the UG, and hence expected behaviour are any of those stated above, but actual behaviour isn't.

---

## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** No response for this issue due to erroneous duplicate tag. Response to "original" bug is a play on definition, though a blank tag is considered to be vacuously alphanum. It also does not address the difference between the expected and actual behaviour of this issue. If the current behaviour is suppose to be the expected behaviour, it is still buggy as it does not aid user in fixing the issue. The received error message is: "Tags names should be alphanumeric". In the UG, for this error message the way to resolve is shown below.  A blank tag does not contain special character or whitespaces, hence user won't be able to resolve this error easily.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Erroneous duplicate tag as mentioned above. It also brings more than minor inconvenience, as provided instructions does not aid user in recovering from the error easily. Replicating explained above reason for disagreeing with rejection: The received error message is: "Tags names should be alphanumeric". In the UG, for this error message the way to resolve is shown below.  A blank tag does not contain special character or whitespaces, hence user won't be able to resolve this error easily.

---