search

nus-cs2103-AY2425S1 / pe-dev-response

0 stars 0 forks source link

UG behaviour, Error message suggestion and actual behaviour is different #2116

Open nus-se-script opened 2 weeks ago

nus-se-script commented 2 weeks ago

Steps to reproduce

  1. type add n/Kimaya Wanjari p/12345678 e/kimaya@example.com a/Kimaya street, block 123, #01-01
  2. view terminal output

Screenshots of behaviour and UG

image.png

image.png

Expected vs Actual

Expected:

Actual: (investigation results below)

  1. Leave not optional image.png

  2. Department not optional image.png

  3. Favourite and TAGs are optional add n/Kimaya Wanjari p/12345678 e/kimaya@example.com a/Kimaya street, block 123, #01-01 d/operations l/10 is a successful command

Categorisation

I was deciding between categorising it as Feature Flaw + Medium vs Documentation Bug + High Eventually I decided

  1. It is a Dcoumentation Bug because the issue can be fixed by changing the documentation and error message implmenetation. Although, some bug reporters may consider it a Feature Flaw. However, I wanted to be fair to you all.
  2. I set the severity high because there is not only a contradiction between expected and actual, but rather there are 2 contradictions (UG + error message vs the actual), which makes the feature extremely confusing for the user, making it unusable unless they spend time testing different prompts to see which fields are actually optional and which are not. Hence, I see this as a high severity bug (compounded with the fact that there is a typo in the error message f/, which I decided to put it as part of this bug report as it can be fixed alongside the other commands, so it's potentially a duplicate bug/ belongs to the same problem).
  3. I also made severity high because the user story says that users should be able to easily troubleshoot using resources in the app (eg UG + error messages) so that they dont need external assistance and this is marked as *** high priority. Unfortunatley, in this scneario, the error message and UG is rather confusing to the user, which means that this user story is not met. Again, some might categorise it as a Feature Flaw but I feel like the root of this entire problem is documentation.

image.png

[original: nus-cs2103-AY2425S1/pe-interim#2910] [original labels: type.DocumentationBug severity.High]

WuJinhan1 commented 2 weeks ago

Team's Response

Thank you for your feedback. The primary concern for this issue is that there are discrepancies in the UG, error messages, and the actual usage regarding the fields (DEPARTMENT, LEAVE), which is indicated by the square brackets in the UG that it is optional but it is not in the actual usage of the app. Additionally, there is a typo in the error message for f/, which is meant to represent the FAVORITE field. I agree that it is a documentation bug as resolving this issue primarily involves aligning the UG and error messages with the current implementation of our HRHelper. You have also mentioned the user stories, which state that as a HR staff, I want to access help resources directly within the app. The current error message (present directly within the app) does address this requirement. However, I acknowledge that the clarity of the message could be improved to fully meet the story's intent. However, it is also worth noting that our Developer Guide (DG) explicitly mentions plans to fix invalid add command messages in the Planned Enhancements section. Therefore, I believe this issue is already accounted for in our scope of improvements.

Duplicate status (if any):

--