Open pzl111 opened 11 months ago
The get
command is designed for these scenarios, see duplicated issue for more information
[The team marked this bug as a duplicate of the following bug]
Long names don't display properly
Running the command
at n/longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong type/expense amt/30
Results in the following UI:
This makes it hard for the user to find out what the transaction actually is
[original: nus-cs2103-AY2324S1/pe-interim#3677] [original labels: type.FunctionalityBug severity.Medium]
[This is the team's response to the above 'original' bug]
Hi, thank you for the feedback.
We have decided to reject this issue, as not only is the issue unclear, we are also unable to replicate the issue.
Firstly, entering the input command
at n/longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong type/expense amt/30
as specified by the tester into our app results in the following output of successful transaction addition.
The reason for the shown DateTime error is unclear, as the input transaction is considered valid and therefore it is added to UniCa$h with a confirmation message shown that the transaction is added. Thus, we are not able to replicate the shown error.
Secondly, it is not clear what is meant by "Results in the following UI" and also "makes it hard for the user to find out what the transaction actually is". In the UI shown, the transaction is displayed as entered and shown by the user. Furthermore, the
get
command is provided to retrieve the full name of a transaction, and as we have mentioned in our UG, we provided this command so that transaction names are not subject to arbitrarily short lengths.Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
Reason for disagreement: The duplicate bug is somewhat similar in that it has truncation in transaction name when run, however they had the issue of DateTime error, which is not what my bug report is about.
I think this is a minor cosmetic issue, since it can be displayed on the right. However the user when navigating other transactions, cant see this properly, hence i think it is still a bug. The app could have considered wrapping. The amount would not be visisble too.