Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aliases are not saved between runs #6

Open
krusagiz opened this issue Nov 15, 2019 · 1 comment
Open

Aliases are not saved between runs #6

krusagiz opened this issue Nov 15, 2019 · 1 comment

Comments

@krusagiz
Copy link
Owner

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

@nus-pe-bot
Copy link

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](nus-cs2103-AY1920S1/forum#159 (comment)

) 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:

  • By definition

severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

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.

  • Despite the inconvenience, the inability to save aliases would not make the product unusable.

  • As I was unable to reproduce the issue using the given steps, and some attempts of my own, I feel like this would only occue in some rare situations.

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

❓ Issue response

Team chose [response.Rejected]

  • I disagree

Reason for disagreement: [replace this with your reason]


❓ Issue severity

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

  • I disagree

Reason for disagreement: [replace this with your reason]


❓ Issue type

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

  • I disagree

Reason for disagreement: [replace this with your reason]


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants