donovan9617 / pe Goto Github PK

Your UG:

My understanding of this is the second person in the list is the target. However, when I ran this command the target was the first person in the list instead:

participate 1 no p/P02

Before:

After:

This is not a cosmetic issue and causes slight inconvenience to the users who wish to edit students.

This is a cosmetic issue in the error message because it is reasonable to conclude that the line "Received..." becomes confusing to read based on some invalid inputs, such as "bubble". There should be a spacing between input and "sort:..." or a line separator or else the error message does not make sense for certain types of inputs. Therefore cosmetic issues is a FunctionalityBug that warrant VeryLow severity.

This is a markdown writing error bug because the rightful intended behaviour was to have it as a header in orange just like the other 4 of them in the document. As its a cosmetic issue, I assigned it VeryLow severity.

Testing

Too much details revealed about the internal structure of the codebase based on the UML diagram. It is not summarised enough to show what needs to be seen for this specific function.

What was tested:

Input is a very long assignment name. When there are multiple of such long assignment names added, it clogs up the person view panel and becomes very difficult to scroll to the other end to view important details such as grade, participation etc. This couldve been handled by using an ellipsis for long names. It hence leads to a minor cosmetic issue (VeryLow severity) because user's view is disrupted.

I believe the command mark 1 present is an invalid command because it is missing the c/ prefix as per the error message in your app:

This is not a cosmetic issue because it involves the execution of the function. It is unlikely to affect normal operations and causes minor inconveniences if a user plans to mark and refers to such a diagram.

What I keyed in:

add n/John Doe m/CS2103T id/IamGivingARandomIdThatsNotAReasonableIdForAStudentToHave

What I found:

Your definition of what a valid Student Id is:

I gave an extreme example of what is a very unreasonable Id for a student in the form of "IamGivingARandomIdThatsNotAReasonableIdForAStudentToHave", that did not even began with the letter "E". I do not expect a student to have such an Id, by any reasonable measure at all. I expected such an input to be handled in some way or another. So I consider this as a Feature Flaw that is not handled properly that warrants Low severity as its unlikely to affect normal situations but is not a cosmetic issue.