Attempting to Change ID Prompts Incorrect Error Message

[ZaydM18]

Steps to Reproduce:

1. Use the edit command.
2. Attempt to change the 'id' of a household.

Expected: ID can be changed or an error message displaying that ID cannot be changed.
Actual: Says the secondary 'id' specified cannot be found.

Explanation: Given that 'id' is a displayed attribute, some users may attempt to change the ID number to match some custom criteria for themselves. Also, it is not mentioned in the User Guide that the ID number cannot be changed. The error message is confusing, and does not rule out the changing of ID numbers. However, given that they are not allowed to be changed, it should be specified in either the User Guide or in an error message.

[nus-se-script]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

"some users may attempt to change the ID number to match some custom criteria for themselves"- Good point, however this seems quite niche and given the target users being social workers, the team does not think this is something that is likely to happen. This is also not the intended functionality of the ID parameter, which is not a field but an identifier.

"Also, it is not mentioned in the User Guide that the ID number cannot be changed."- This is correct in that the user guide does not explicitly state the ID cannot be changed. However, per the screenshot below, the available parameters that can be changes are n/ a/ p/ t/. id/ is not a stated available parameter that can be specified to be edited, it is used to specify the household to be edited. If there is ambiguity as a result, it is likely as a result of the phrasing in the documentation and not a bug.

"The error message is confusing, and does not rule out the changing of ID numbers"- As mentioned in the user guide, only the last instance of the parameter is processed i.e. H000023 is processed, and the subsequent error message appears because it is probably the case that such an ID did not exist, hence no household was found with that ID.

The team feels that there was incorrect classification of the bug type (if anything), the intended usage was already specified in the UG, and the error message appears in accordance with what was specified in the UG. Therefore, the niche case specified with regards to changing the ID seems out of the project scope.

Items for the Tester to Verify

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: The dev team suggested that changing the ID is a niche case, but I do not necessarily agree with this statement. This is an app for use by many different users, who may have their own personal preferences. As a result, it is very common that potential users may want to edit the Household ID of a particular household or group of houses for their own convenience. For example, they may want to store users living in the same general area under a common area ID code (using something like SK for Sengkang) or otherwise. Although the dev team does not have to allow the ID to be changed (if they believe that maintaining the integrity of Household IDs supersedes these personal choices), it is clearly something that a number users may attempt, especially given that it is not explicitly ruled out except in the specification of the edit command, which is also something that may be easily missed by inattentive users.

---

❓ Issue type

Team chose [type.DocumentationBug]
Originally [type.FunctionalityBug]

• I disagree

Reason for disagreement: While I understand where the dev team is coming from with their decision to refer to this bug as a documentation bug, I do not believe it to be so. Once again, the documentation is highlighted correctly. But my belief is that the inability to edit this particular parameter should take precedence over the behaviour described in the Before We Begin section of the User Guide. My reasoning pertains to the second definition of a functionality bug as described on the CS2103T website: A legitimate user behavior is not handled e.g. incorrect commands, extra parameters

Given this definition, it is reasonable to classify an unhandled error for trying to change the ID number to be a functionality bug, because it should be an expected user behaviour. Moreover, this may even serve to confuse users, who, after viewing the error message, may believe that Household ID is a parameter that can be edited, given that it behaves almost exactly like other ones, but then find no way to do that. This would fall under the third definition of a functionality bug: Behavior is not specified and differs from normal expectations e.g. error message does not match the error because they may believe that IDs should be modifiable.

---

❓ Issue severity

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

• I disagree

Reason for disagreement: [replace this with your explanation]

---