Open krusagiz opened 4 years ago
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
:
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:
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:
Clear all save data files (particularly preferences.json
) for a copy of the application with no aliases as a base line
Open application instance 1 (A1) (the right picture)
Open application instance 2 (A2) (the left picture)
Both A1 and A2 will be using the same inital data on loading.
Add aliases to (A1)
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)
Close both applications and reopen.
listalias
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.
Team chose [response.Rejected
]
Reason for disagreement: [replace this with your reason]
Team chose [severity.Low
].
Originally [severity.High
].
Reason for disagreement: [replace this with your reason]
Team chose [type.FunctionalityBug
].
Originally [type.FeatureFlaw
].
Reason for disagreement: [replace this with your reason]
Restarting the application results in the user created aliases being lost.