search

dunliang0513 / pe

0 stars 0 forks source link

Same module tag shouldn't be add repeatedly #5

Open dunliang0513 opened 1 year ago

dunliang0513 commented 1 year ago

To reproduce:

CS2109S with tag CSF, trying to edit the tag to CSF again and it shows the command successfully executed.

Expected:

Since the tag is the same, should remind the user that this module already has the same tag as the user provided.

Actual:

Added tag to module CS2109S

SS:

before: Screenshot 2023-04-14 at 2.45.47 PM.png

After:

Screenshot 2023-04-14 at 2.48.28 PM.png

soc-se-bot commented 1 year ago

Team's Response

No details provided by team.

The 'Original' Bug

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

Able to add duplicate tags for a module

Steps to reproduce

  1. Add a module with module code add /m CS1101S /c 4 /y Y1S1
  2. Add a tag to the module tag CS1101S include /t CSF
  3. Add the same tag to the module by repeating the command in step 2

Expected:

  • Shows an error that the tag has already been added

Actual

  • shows success message

Screenshot 2023-04-14 at 2.38.42 PM.png

[original: nus-cs2103-AY2223S2/pe-interim#938] [original labels: severity.Low type.FunctionalityBug]

Their Response to the 'Original' Bug

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

By "Added" we meant that the tag either already exists or has been added if it did not already exists. If you look at the modules in the module list and the degree progress, there are no tags that are duplicated. The typical user would not require double tagging a module with the same requirement either. Therefore, it does not affect the functionality of the app and it is more of a semantics or clarity of language issue. Also, if we did include an error message for adding existing tags to modules, we might issue errors when there are a lot of valid tags with 1 duplicate tag added in one command, causing the user to have to re-type the whole command when it is not necessary. We believed that the error message is unnecessary in this case. Moreover, we did not state that this is a scenario when an error message will be displayed in the UG or DG.

However, we do agree that the clarity of the language used in the success message can be improved.

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 type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]