Exporting and Importing does not work together

[rickkoh]

Description

I had exported a csv file created by the application and tried importing that file back in but an error occured as depicted in the screenshot.

The issue here is that I have no tampered with the exported file at all.

Steps to reproduce

1. Run the command clear.
2. Add a new contact add n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25.
3. Go to the app directory and create a folder named export.
4. Go back to the app and run the command export. (Notice that the file is exported)
5. Run the command clear again.
6. Run the command import f/./export/export.csv.
7. Notice an error pops up although we are trying to import a csv that was created by the app itself.

Expected Behaviour

At step 6, the application should import the exported csv file successfully.

Actual

Application unable to import a csv file that was exported and untampered.

Notes

Marking this issue severity as high as some users might export multiple data and then deleting their current ones blindly trusting that the import feature would work, leading to loss of large amount of data.

For example if:

1. User creates a list of contact
2. User exports the contacts
3. User thought he/she can import the exported contact in the future and hence run the clear command to delete current list of contacts
4. User might never be able to import back the old list of contacts.

[nus-se-script]

Team's Response

This bug is caused because .csv files, depending on where they are downloaded, may have a security attribute that prevents the proper reading of the file by the app.

Actually, the UG had a line to address this:

• Ensure that the file provided is saved before used as an import file

If one opens the file and saves it, the security attribute will be disabled and the command should work as intended. However, I agree that in hindsight the understanding from the description is definitely not the most intuitive, and should have been refined or explained further.

Hopefully with this clarification the reason for the proposed severity/type changes are clearer. Regarding the severity change, I would label the severity as medium for the following reasons:

1. Users who import using files that do not have the security attribute (i.e. because of manual editing, security preferences, or from trusted sources etc.) would not be impacted e.g. Those of the target audience of student leaders who collect information via a google forms sheet
2. Those that interpret the UG correctly and save the file before using it would not be impacted

   Items for the Tester to Verify

   :question: Issue type

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

• [x] I disagree

Reason for disagreement: Hi, I appreciate your insights into the situation, and while I acknowledge the possibility of it being a documentation bug, I still believe this should be marked as a feature flaw for the following reasons:

Behavior Misalignment: The application is not behaving as expected or intended. The export functionality is generating a file that cannot be successfully imported back into the application, despite being untampered. This misalignment between expected behavior and actual behavior points to a flaw in the functionality itself.

Impact on User Experience: The inability to import exported data can have significant consequences for users, potentially leading to loss of important data. This impact on user experience elevates the severity of the issue beyond a mere documentation problem.

Additionally, I have attempted the workaround suggested - opening the file and saving it to disable the security attribute - but unfortunately, it still doesn't work on my end.

---

## :question: Issue severity Team chose [`severity.Medium`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Hi, as previously mentioned, I have attempted the workaround suggested - opening the file and saving it to disable the security attribute - but unfortunately, it still doesn't work on my end, and hence I would disagree. Given the potential impact on user experience, particularly the risk of data loss for users who may rely on the import feature, I would argue that this issue should be marked as High severity. The inability to import exported data directly affects the core functionality of the application and has significant consequences for users. Therefore, it warrants a higher severity classification to ensure that it receives appropriate attention and priority for resolution. Additional information that might be helpful for you to debug: I ran the test on a 14-inch 2021 MBP running macOS Monterey.

---