Open chydarren opened 2 years ago
Should be a duplicate of #369, extreme user behaviour by tampering with the files when it is mentioned in the DG and based on the tP constraints only advanced users should do it.
[The team marked this bug as a duplicate of the following bug]
Departure time outside of 24H range was allowed to be entered into the application
It is mentioned in the user guide and in the application it was also handled that when the time is out of the 24 hour range, it will not be accepted. I attempted to try to add outside of the 24H format in the application itself and it did not allow as well.
However, I modified the storage file for the departure time and it allowed me to go through.
[original: nus-cs2113-AY2223S1/pe-interim#387] [original labels: severity.Medium type.FunctionalityBug]
[This is the team's response to the above 'original' bug]
Based on the elaboration given in this issue, the application does its job of catching the exception of trying to add an invalid time. However, the editing of the data file as stated by the tP constraint should be done only by advanced users. We believe that this is extreme user behaviour as it is deliberately tampering with the storage file.
It is also stated in the DG that the file should not be tampered with.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
Reason for disagreement: These are two different issues - one is about each entry not validating each field, the other is totally inserting an entirely wrong line into the passenger logbook, and the application data is compromised.
Team chose [response.Rejected
]
Reason for disagreement: Below are the reasons why I disagree with the team's response:
The User Guide did not indicate that users should not tamper with the file.
Based on the module's constraint, the file is Constraint-Human-Editable-File
, i.e. (advanced) users are allowed to edit the files. If this is the case, that means the team has violated this constraint as in their DG, they wrote "highly not advised to tamper this file".
Suppose users are allowed to edit the file (as per the module constraint), it is possible for a typo or extra field to occur. The team should validate that each entry entered into the application is valid before listing them for display.
Hence, with the above justifications, I'm unable to accept the team's rejection for this bug caught.
When my file is corrupted, I am able to generate a passenger list which contains a line of strange flight details that don't correspond with the passenger fields (i.e. look at the first entry).