search

krusagiz / pe

0 stars 0 forks source link

Aliases are not saved between runs #6

Open krusagiz opened 4 years ago

krusagiz commented 4 years ago

Restarting the application results in the user created aliases being lost.

nus-pe-bot commented 4 years ago

Team's Response

Rejecting this report

Due to insufficient information (the issue is unclear) regarding how this issue can be reproduced, I suspect this issue occurs due to an attempt to manipulate the .json data files. Hence, I am rejecting this issue. See [this link](https://github.com/nus-cs2103-AY1920S1/forum/issues/159#issuecomment-549119227

) regarding the expected behaviour of the application when these data files are modified.

Please read the rest of this response for a more detailed explanation:

Cannot reproduce

I am unable to reproduce this problem. I have attempted to add an alias and close and exit the application via the exit command, exit button, and 'file > exit', and have not been able to reproduce this result.

Downgrading severity to Low:

severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.

severity.High : A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.

I suspect this issue has occured to an attempt to manipulate the .json save data files. The only situation where I would see the aliases not being saved is due to an intentional attempt to corrupt the alias data in the preferences.json file. In this case, opening the application using java -jar <jar name> in the unix shell, or checking the .log file will provide the user more detailed information regarding the internal behaviour of the application.

Attempting to corrupt the alias data could result in the following error message appearing in the log messages:

Screenshot 2019-11-17 at 13.11.56.png

The application will attempt to rectify this issue by resetting the alias mappings data to avoid unexpected behaviour due to corrupted aliases. This was mostly to avoid potential infinite loops occuring due to chaining of aliases to refer to each other as well as some other reasons.

As such, I am rejecting this issue.

I am also changing the bug type to FunctionalityBug as this problem is not expected behaviour in the event that it can be reproduced solely with actions within the product.

Another reason this could be occuring due to an inherited behaviour from Address Book 3.

To reproduce:

  1. Clear all save data files (particularly preferences.json) for a copy of the application with no aliases as a base line

  2. Open application instance 1 (A1) (the right picture)

  3. Open application instance 2 (A2) (the left picture)

Both A1 and A2 will be using the same inital data on loading.

  1. Add aliases to (A1)

  2. Execute command which modifies the data (e.g. addexpense d/ 1 p/1 c/food) in A2 (this causes the data written by A1 to be overwritted by the data of A2 which has no aliases)

Screenshot 2019-11-17 at 18.00.52.png

  1. Close both applications and reopen.

  2. listalias

  3. There are no aliases

If this was the steps which causes the bug, this is an inherited behaviour from Address Book 3 and is grounds for rejecting this report.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: [replace this with your reason]

:question: Issue severity

Team chose [severity.Low]. Originally [severity.High].

Reason for disagreement: [replace this with your reason]

:question: Issue type

Team chose [type.FunctionalityBug]. Originally [type.FeatureFlaw].

Reason for disagreement: [replace this with your reason]