ollayf / pe

0 stars 0 forks source link

Loss of data when one forgets to close the app and manually editing the file #7

Open ollayf opened 1 year ago

ollayf commented 1 year ago

I start by running the app. Then i edited the meeting_list.txt as instructed as it is faster. As follows any addition or deletion via the app removes all these edits

Screenshot 2023-04-14 at 4.58.57 PM.png

After adding or deleting any meeting. My manual edits are overwritten.

Screenshot 2023-04-14 at 5.00.08 PM.png Screenshot 2023-04-14 at 5.00.13 PM.png

This can cause very weird behaviour, when I forget to close the app before manually editing. Then subsequently continue using the app which is quite normal for me, many of my manual edits can be removed and erased, causing alot of loss of important data.

nus-pe-bot commented 1 year ago

Team's Response

This is a duplicate of #1556 as both mentions editing the file while using the program concurrently.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Edits are not saved

Screenshot 2023-04-14 at 4.53.35 PM.png

in the UG you allow quick and direct editing from the *_list.txt However, after editing:

Screenshot 2023-04-14 at 4.54.33 PM.png Screenshot 2023-04-14 at 4.55.31 PM.png

changes are not reflected in view_meetings. Changes are only loaded in on startup of the app.


[original: nus-cs2113-AY2223S2/pe-interim#2125] [original labels: type.FunctionalityBug severity.Medium]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

From what we can infer based on the information provided in the issue, we believe this is related to editing of the text file while the program is running.

The user mentions that "we allow quick and direct editing of the "*_list.txt". However, as seen in the description of our storage feature in the image below, there is no such mention.
Furthermore, this is our expected behavior of the program where if the "*_list.txt" is edited while the program is running, the edited details will not be saved.
Hence, our team change this from a FunctionalityBug to a DocumentationBug instead as it would be much clearer to the user if we added a line mentioning that the editing of file only works if the program is not running.
Our team also change the severity to Low as this does not affect the normal usage of the program and this misunderstanding can be fixed by adding a single line in the User Guide.
After the changes to the bug type and severity, our team decided to accept this bug.

image.png

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 all separate issues. Both deals with "issues when editing the file and using the programme concurrently". But the point is that if this broad category "issues when editing the file and using the programme concurrently" is enough to cover different sets of inputs and responses and different sets of issues relating to them as duplicate, that would be too convenient.

The previous issue deals with the fact that data input when editing the file is not loaded into the application causing the user to have an incomplete dashboard (assuming saving is done right) This issue deals with the fact that in some slightly more specific sets of commands after editing the file and using the programme concurrently, it can cause massive loss of data (potentially forever), furthermore, without any warning to users at all.


## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** This is clearly a functionality bug as: 1. devs recommend or at least advertise manual editing through the file 2. There is an implicit understanding that when I use the app, my data will never be lost (unless I specifically command it to) when I follow all the steps are described in the UG. I think this much at least is reasonable. 3. This is a feature that is implcitly advertised but not delivered properly. ![Screenshot 2023-04-19 at 1.29.24 PM.png](https://raw.githubusercontent.com/ollayf/pe/main/files/a86fc56b-936c-44f2-a931-487dd2012275.png)
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** 1. based on the OP: This scenario is totally not out of the ordinary. I can see this happening to a significant portion of restaurant managers who have tight schedules very busy etc. Since they don't understand programming super well other than using a terminal for example, they might not even have an inkling that these cannot be done concurrently. 2. Criticality of the issue: For a business to lose data like this it is ALOT it can cost them a lot. Hence, i think it should be kept at severity.Medium