LinkedInk / pe

0 stars 0 forks source link

`c-tag-find` does not return archived employees #6

Open LinkedInk opened 4 years ago

LinkedInk commented 4 years ago

Added both John Doe (active) and George Doe (archived). Both tagged as special. image.png image.png

Using c-tag-find: before image.png after image.png

As you can see, George Doe is not returned. This command should be updated to allow for both.

Perhaps this command has the same limitation as c-find command where it only returns active employees as mentioned in the UG. If this is the case, the UG should be updated in a similar fashion to c-find.

nus-se-bot commented 3 years ago

Team's Response

Thank you for the bug report.

However, we have changed the bug type to documentation bug, instead of feature flaw. Feature flaw means that the feature does not suit the problem given. The feature works as expected. In normal daily operations, when the manager (user) wants to get a filtered list of employees, he should only be searching through the active (unarchived) employees. The archived employees should be ignored as they are no longer working in the shop. Thus, the expected behaviour of this feature is reasonable.

It is actually a documentation bug, as clearer instructions should be given. i.e stating that it will only find the active employees instead of finding all employees.

image.png

Items for the Tester to Verify

:question: Issue type

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

Reason for disagreement: [replace this with your explanation]


:question: Issue severity

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

Reason for disagreement: For the current UG, it would be reasonable for users who use this feature to expect that it finds active (unarchived) and archived employees as it is mentioned in the UG that this feature finds all employees (as shown below).

image.png

Hence, according to the UG, it should be possible to find some archived employees using this feature. In actual, this feature does not find archived employees. This feature it only finds among active (unachived) employees. For users to discover that this feature does not find archived employees as well like they expect from reading the UG while in use is a major problem. This documentation bug is not merely an inconvience and as the problem it causes it cannot be worked around or ignored (especially as there is no other feature to search for archived employees).

This is not simply a case of forgetting to mention a limitation in the documentation. This is a case of misleading information in the documentation.

Hence, I argue that this documentation bug causes major problems and should be of a high severity issue. Even if the changes needed is minor.

image.png