nus-pe-bot
commented
1 day ago Team's Response
The tester raises the issue of an existing event not being updated when a contact involved in that event is given a new additional role. As seen from the screenshot provided, when a contact (Wendy Tan role: Attendee) is edited to have an additional role of Sponsor, the event is not updated to have Wendy both as an attendee and sponsor (only having Wendy under the original role as attendee). The tester suggests that this is a flaw with the edit command and edit should automatically add edited contacts to existing events in newly added roles.
The team disagrees that this is a flaw with the edit command, and that it has a severity of high. This is an intended behavior of the command (to not add contacts into existing events under new roles) and the suggested behavior of automatically adding contacts under their new roles would likely be highly inconvenient for our users. The roles of a contact are meant to show all possible roles a contact can fulfill and we feel that automatically adding contacts under newly added roles is likely to NOT align with user intention. Editing a contact to add additional roles does not necessarily mean that the user wants the contact to retroactively be involved in that role for all existing events.
The edit command is designed for users to dynamically update contact information with changes in contact information or additional information about the contact is made available.
As mentioned above, the roles of a contact are meant to show all possible roles a contact can fulfill (but the contact at this point in time may or may not have this role in any ongoing event). In contrast the roles represented under the event are the roles that are currently being fulfilled by contacts who have been added to specific roles in that event.
Contrary to what the tester noted, edit does update existing events. Upon using edit to change a contact's roles:
- If a role is removed from the contact, the contact will automatically removed from that role in all events where he has that role. (As it is no longer possible for him fulfill that role)
- If a role is added to the contact, the contact will not be automatically added to all event. (As he may not be intended to fulfill that role in any current event)
User Guide warning describing edit's behavior in for removing roles
When edited to have an additional role, it is not necessarily true that the contact will be acting as that new role for any events that he is currently a part of, and PlanPal reflects this by not automatically adding them under that new role for any ongoing events. This is because while a contact can fulfill multiple roles, he may not be fulfilling all his possible roles in every event that he is involved in.
Consider the following scenario with the tester's suggested behavior where a contact is automatically added to existing events under their new roles: 1) Wendy initially only has the attendee role. 2) Wendy is attending a Hackathon event (that our User is managing) as an attendee (Wendy is added under Hackathon as attendee) 3) As our User speaks with Wendy, he finds out that Wendy is a professional pianist as well and is open for performing at events (Wendy can now also have the role of vendor) 4) With this new information, our User edits Wendy's information in PlanPal to have both the roles attendee and vendor so that he can contact her for future events. 5) PlanPal updates Wendy's information and changes all events that Wendy is involved in to have Wendy as both an attendee and vendor. 6) Wendy is now reflected as performing at the Hackathon event as a vendor pianist (? This clearly does not align with user intent)
As seen from the scenario, the suggested behavior of automatically updating existing events would likely be counter productive and create an even greater inconvenience for our users, as they now have to trawl through all events Wendy is involved in and manually remove her from that unintended new role. Moreover, the suggested behavior completely goes against what the user intended and would likely make them extremely frustrated.
Our implemented behavior of not automatically adding a contact with new roles under newly added roles in existing events gives the user more control and agency over how their contacts are assigned to events. Moreover, it is significantly more likely to align with user intent when editing a contact.
However, we acknowledge that the behavior of edit can cause inconvenience in rare cases where:
1) A contact can fulfill multiple roles but the User does not have complete information and only records the contact with 1 of the roles (e.g. Attendee instead of both Attendee and Volunteer)
2) The User is unaware of the incomplete information and adds the contact under an event only under the role he has recorded
3) The User is made aware of the additional roles that contact can fulfill (e.g. a sponsor)
4) Despite only just being made aware of this new role, the User immediately wants that contact to fulfill that role in all his previously planned events in which that contact is involved
As this is an extremely rare scenario, and because our implemented behavior does not hinder the normal operations of our users whatsoever outside this scenario, we disagree with the tester's suggestion that this is a high severity flaw which would make the product completely unusable.
We propose instead a low severity due to the scenario being extremely niche and only causing a minor inconvenience.
The team also feels that our current implementation fulfills our user's intent in the vast majority of cases compared to the suggested behavior and the edit command functions as intended with our design (and does not fail when executed even in this case).
However, we acknowledge that there could be extremely rare scenarios where automatic propagation of added role(s) could be convenient and that additional functionality could be implemented for users to indicate that they want the contact to be added to all existing events under that new role.
Nevertheless, we feel that our current implementation is more closely aligned with our users' intent in the vast majority of cases and that this inclusion of an niche scenario is not a high priority issue and propose that the issue raised by the tester is Not In Scope.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
When the contact's role are changed, the expected behaviour would be that the event's numbers such as the event role count to change. However, it was not reflected as such.
Steps to reproduce the bug:
First, I created a unique contact named Wendy.
I edit Wendy's role to become an attendee.
Then I created a new event and added Wendy to the event.
Next, I updated Wendy's role to contain both attendee and volunteer. However, event's role count was not changed.
This could potentially lead to many inaccuracies for the user as which could lead to real world consequences if these numbers were wrong and not updated.
Instead, I after editing the role of Wendy, I am expected to remember the events that Wendy is partaking in and editing all of those events with the new tag 1 by 1, which might discourage users from using the product.