nus-se-script
commented
15 hours ago Team's Response
Hello, thank you for the bug report! While we know that users may want to use multiple instances of the app and edit the lists in parallel, we see this feature as "Out Of Scope" for the current version of our project. For now, we believe it's suitable for our users to stick to one application instance at a time.
In addition, we also believe that this violates some of the project constraints. For example, we are not allowed to use a DBMS (Constraint-No-DBMS) (Database Management System like MySQL) to store data. However, to have data changes flow consistently among multiple instances of the app, one would require a DBMS. The need of a backend also violates the Constraint-No-Remote-Server.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: While the project constraints (e.g., Constraint-No-DBMS, Constraint-No-Remote-Server) are valid, the issue does not inherently require a DBMS or remote server to resolve: Alternative solutions, such as file locks or instance detection, could prevent multiple instances from being opened simultaneously. This would mitigate the issue without violating constraints. In addition, the UG introduction have also mentioned that this is a single desktop application and the user is required to handle all the data, which would definitely have the case of opening up multiple tabs accidentally Furthermore, the UG promises automatic saving, which implies that data integrity is a supported feature. The current behavior conflicts with this promise and should be addressed to align the product with its documented functionality.
The issue is not an enhancement request but rather a critical flaw in the existing functionality as the conclusion of the above mentioned points. The app does not warn or prevent users from opening multiple instances, leading to significant usability issues, which is different from the claims of the ug. Users can unknowingly overwrite or lose data due to the lack of synchronization, which contradicts the app's core purpose of event management.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Thank you for your response and acknowledgment of the issue. While I understand the team's constraints and rationale, I respectfully disagree with the severity downgrade to severity.Low Below are my points: ### Severity Justification: 1. Critical Nature of Data Consistency: Event management applications inherently rely on data consistency to ensure accurate and reliable operations. A lack of synchronization across multiple instances risks creating confusion and significant data discrepancies, particularly when managing high-stakes events like cross-faculty IFG games, where: Event organizers handle a large volume of data. Multiple tabs/windows are commonly used for multitasking. The inability to synchronize updates across instances undermines the core functionality of the app, directly impacting reliability and user trust. Severity Definition Alignment: This issue directly affects a core audience (event organizers) and results in data inaccuracies and potential loss of work, rendering the product nearly unusable in scenarios involving parallel updates. The impact is not limited to occasional inconvenience; rather, it hinders the effective usage of the app for its intended purpose. The UG states that the app saves data automatically, leading users to expect that changes made in one instance are applied globally. This mismatch between user expectations and actual behavior is a critical flaw that can result in data mismanagement and operational inefficiencies. For users managing complex events, the lack of synchronization can lead to: Redundant manual effort to consolidate data. Accidental overwriting of updates. Wasted time identifying and correcting inconsistencies. After reading the team's response, i would disagree with the severity low but think that this should be a medium severity due to the use scenario of the app and the claimed auto save functionality of the app
ISSUE
In EventfulNUS, when multiple instances of the application are open, changes made in one window do not reflect in the other. This can lead to data inconsistency, particularly for users who manage a high volume of event data across multiple faculties, roles, or participants[which is mentioned in the UG and DG]. A user might open multiple instances of EventfulNUS, intending to work on different aspects of the event data in parallel (e.g., managing participants in one window while scheduling events in another). However, any changes made in one instance, such as adding a new participant or updating event details, remain isolated to that specific window. The manager for this should be very busy also, most people working/ study have multiple tabs like 100 tabs open, not to mention about people working to handle the IFG, a cross-faculty University level game This could lead the user to mistakenly assume that their updates were applied globally across all instances.
Further, there was mentioning in the UG that the data is saved automatically, which could be confusing to users.
Demostration
video:https://raw.githubusercontent.com/dominic2412/pe/main/files/ae9079c3-7d51-4fac-a962-7bd253a2e010.mp4
Reason for severity
This issue impacts the reliability of the application, particularly in event management scenarios where accuracy and synchronization are essential, such as coordinating participants, updating event details, or assigning roles. For busy event organisers, managing a large volume of data across faculties or roles, the risk of data discrepancies becomes particularly significant.