Lack of data integrity upon corruption

[Nafeij]

The application drops all user data if it detects incorrect formatting or data corruption, even if said discrepancy only affects a single entry/employee/department. This could result in critical data loss.

To reproduce:

Launch application with sample data. Close application, open data/sudohr.json, make single breaking modification (e.g. remove one digit from Ben's phone number), and relaunch application.

Expected behaviour:

The application would attempt to parse and recover data for remaining employees.

Actual behaviour:

The application overwrites all remaining data and starts empty.

[nus-pe-script]

Team's Response

Hi, thank you for raising this up. Our team is aware of this and this behaviour is completely intentional. What you see above is one of our many safety mechanisms to guard against invalid data / inconsistent data. Our app is primarily on data consolidation and we prioritise processing of valid and consistent data, ensuring data that have been manually added, tracked and managed via SudoHR commands will never be corrupted.

Yet, what you have done above is to intentionally tamper (which shouldn't be the case.. changes to be made via SudoHR) with the data file and cause it to be corrupted. We believe in such extreme cases, the expected and safest behaviour is to ban the booting of the app with corrupted data as the results from any subsequent operations cannot be guaranteed to be accurate nor consistent. That said, does that mean SudoHR cannot run at all? That isn't ideal as well and so it is only natural for SudoHR to start with a clean slate.

It can be argued that users may want to upload an existing data file to SudoHR from elsewhere. That is fine, but it is their responsibility to ensure the data file is not corrupted and adhere to the correct format. After all, we do not explicitly offer this functionality nor encourage such usage. If the concern is that the data file would be automatically cleared by SudoHR, well, the data file must have been obtained from somewhere right? Perhaps look for the source to retrieve an original copy of the data file. It is not the app's job to safe-keep erroneous data. SudoHR can maybe save a copy of the data file and dump it somewhere, but this brings about the issue of storage, management and etc which is not quite in scope.

Ultimately, there isn't an efficient way to identify the source of error in any given data file. It could be as u messed, 1 tiny error, or the whole file is strife with errors. There are ways to handle it, but this is not at all crucial to overall usage of the app.

Note: The warning given to users, as outlined in the UG, shown below.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---