Lack of validation checks for users who edit the text file directly

[nus-pe-bot]

Improper number format by editing directly on the file results in nothing being shown No error message provided to tell the user what went wrong when they were editing directly on the file which is intended behaviour for advanced users according to UG

---

_{[original: nus-cs2103-AY2122S1/pe-interim#2729] [original labels: type.FunctionalityBug severity.High]}

[bharathcs]

Team's Response

Thank you for the suggestion.

On the category

If I may refer you to DonnaFin UG: Editing the Data File, there is a detailed explanation of the situation that occurs when you edit files and the behaviour that occurs:

If your changes to the data file make its format invalid, DonnaFin will discard all data and start with an empty data file on the next run (no clients are shown).

As we can see, this is not a functionality but, and at most a feature flaw as this is entirely expected behaviour.

On the severity

Furthermore, in that section, we took great care to explain how invalid formats can render the entire data file invalid. We used a specific example of missing the '$' symbol in a monetary value field, but it was clear that the example is not exhaustive of the ways the data file can be invalid. We further elaborated on the situation as follows:

However, when this happens, to prevent total loss of your data, we do not delete it right away. DonnaFin will assume that the intended action is to clear your data and restart only when any valid command is run. DonnaFin will then proceed to cleanly wipe donnafin.json and execute your command.

On our response

While the previous points could be grounds for rejecting this issue, I do believe this is a valid feature suggestion. We had actually considered making such a feature, and planned for creating a UI pop up on application start up that lists issues with the file if any, or if none, it would list possible duplicates (e.g. lower case / upper case or double spaces) to make the file editing experience as convenient as the add or edit commands with thorough and helpful error / warning messages. Unfortunately, this would require a lot of work:

• UI component to be designed and created on start of app
• Per client preferences to include ignore warnings to prevent the user consistently being bombarded with the same warning over and over again each time.
• Supporting such warning configurations in Person and / or AddressBook in Model.

At the end of the day when we planned out the work all the way up to v1.4 we deemed this was not a critical feature and elected to treat it as out of scope of this tP.

Duplicate status (if any):

--