crownkira/pe

pe's Issues

Dummy report

No details provided by bug reporter.

Hard to type command

add property may be shortened to add p, it will make typing faster especially if this app is meant for fast typist.
avoid using special character for attribute prefix $/, since special characters are sometimes hard to type compared to alphanumerical character since user has to hold shift key to enter that.

Giving it a low, since users seldom needs to type the command to add property (idk) and the app is still usable.

Alphanumeric names not allowed

Names should only contain alphanumeric characters, hyphens, and spaces, and it should not be blank.
Names should also be at most 50 characters long.

the following is not allowed:

edit property 16 n/𝓉𝑒𝓈𝓉 does not work 

the error message only specifies that it should only contain alphanumeric character. The above test input is alphanumeric just with a slight tweak of style but is not allowed. Hence, a clearer error message would specify clearly the font style of the input too :D

Two properties with the same name allowed and no warning.

As the title suggest:

Auto format issue

Property Whiz autoformatted the name to become title case. This behaviour is not specified in the UG or the displayed message. Giving this a medium since it may affect users who want the name to be of a specific format (which i believe is in the majority including me) . This behaviour does not make the app unusable though.

Multiple components with low level details

It is recommended that we only expose the low level details of at most one component, but this seems to violate that.

Multi-command input issue

edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500
edit buyer 1 $/100000
edit buyer 1 $/500

entering this input will not cause the displayed price to change, eg. when i execute the command $500, the displayed price does not change as expected.

Inconsistency in association label

There is arrow here beside the label:

There is no arrow here beside the label:

No label in the list card

Users might find it hard to tell which field contains the address or name here.

Duplication of email due to manual edit will cause data to be wiped

As the title suggests:

Giving it a high since:
While it might not happen to most users, it can happen to any user, and the outcome is disastrous (i.e., loss of all data).

This also violates your NFR:

Should be able to restart without loss of data.

All fields are compulsory

Sometimes a user might not want to type address since he doesn't have a record of that or phone number. Making the fields optional would be better :))

Giving it a low since it might affect the majority of users (who might find the lack of need to fill up all inputs), but does not hamper the use of this app.

Overzealous phone checking

edit buyer 3 n/123 [hp] 456 causes error.

Reason:
While your software allows only one phone number in input values, a user might want to input 1234 5678 (HP) 1111-3333 (Office) -- blocking that input might not add any value but allowing it does.

Negative currency input not allowed

The error message only specifies that:

Price (in dollars) should only contain numbers, and it should be at least 4 digits and at most 9 digits long, not counting leading zeroes.

Numbers include negative numbers, and should not be excluded and should be allowed.

Confusing error message

Price (in dollars) should only contain numbers, and it should be at least 4 digits and at most 9 digits long, not counting leading zeroes.

edit property 16 $/0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001

meaning of not counting leading zero here is unclear.
If I don't count the leading zero, there is only one digit here, by the logic, this input should be allowed.