There is no edit feature

[nus-se-script]

There is no easy way to edit the details of a person. In the case that the user misinput the details of the contact or even that the contact in question changes their phone number or email, the only course of action for the user to correct the details of the now erratic contact is to delete the contact and then add it back in with the new command. This takes notably long as deleting the contact does not return the details of the contact deleted, but simply shows the success message Deleted volunteer successfully! as shown below.

Accordingly, over the course of usage of the application, the user will likely feel frustration over constantly having to retype the information of volunteers wholesale, especially as the amount of volunteers in the application grows. Notably, this also violates the project constraint of being a brownfield project as there was an edit command in AB3 that was removed for no perceivable benefit, making the current application feel like it is taking away from the existing codebase.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#3830] [original labels: type.FeatureFlaw severity.Low]}

[tzuennn]

Team's Response

The edit command is not a valid functionality in this application, and its error is handled gracefully (telling you that it is not a valid command and not crashing). So it satisfy the second condition of bug not in scope.

While it is true that an edit functionality would be helpful, it was not part of our intended scope for this application, which is why it is not mentioned in the User Stories in the DG. Given the added complexity of implementing and maintaining an edit command alongside the existing entities (Volunteer and Event), we prioritised features that provide broader value, such as advanced filtering capabilities. This functionality enables filtering not only by volunteer names but also by their availability for specific event dates, aligning more closely with our project goals.

Although the edit command may appear straightforward to implement from AB3's perspective, its implementation in our project would introduce significant issues due to the relationships between the Volunteer and Event entities, particularly concerning dates. For example, if a volunteer's date is edited, it could cascade into conflicts or inconsistencies with event schedules, availability records, and potentially other linked volunteers. Addressing these complexities would require careful handling of dependencies and significant changes to the underlying system, making it a far more challenging feature to implement.

As this is a brownfield project, decisions had to be made to balance resource constraints and focus on features that enhance usability for the majority of users. The omission of the edit command was a deliberate trade-off to allocate our efforts towards developing more impactful functionalities. While editing is a "good-to-have," it can be considered for future iterations. Thank you.

Duplicate status (if any):

--