Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update DG for new feature flaws #298

Merged
merged 4 commits into from
Nov 12, 2023
Merged

Update DG for new feature flaws #298

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0338230
update planning enhancements
Nov 12, 2023
0ba51d2
resolve merge conflict
Nov 12, 2023
27e8cdf
update DG
Nov 12, 2023
a17bcd3
update filter feature flaw
Nov 12, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions docs/DeveloperGuide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -821,9 +821,9 @@ Given below are the fixes proposed to add in the near future.
1. #### Deal with values having leading whitespaces in data files
1. The current implementation will not load the `addressbook.json` file in the data folder when there are leading whitespaces.
2. Proposed solution: We plan to trim the values of leading and trailing whitespaces before reading into `jsonAdaptedPerson.java`, so that even if there is leading whitespaces, the values can still be read.
2. #### Deal with phone numbers having more than 15 digits long
1. The current implementation will accept any phone number length more than 2, including numbers that are more than 15 digits long. However, the maximum phone number length in the world is 15.
2. Proposed solution: We plan to limit the phone number length so that it is 3 to 15 digits long, since all phone number with length more than 15 are technically invalid.
2. #### Expansion of `filter` feature
1. In the current implementation, `filter` only works for 1 field. The user may want to filter for multiple fields so that they can have an easier time finding people of interest.
2. Proposed solution: We plan to let `filter` filter for multiple fields.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I think is good to add filtering for note, schedule and schedule name here

3. #### Expansion of `tag` feature
1. Currently, the only way to modify tags is via the `edit` command which overwrites the entire tag list when executed.
2. This can result in notable user inconvenience in at least one of two ways :
Expand Down Expand Up @@ -868,7 +868,7 @@ Given below are the fixes proposed to add in the near future.
1. Possible user information overload.
2. Implementation & testing overhead due to more complex behaviour.

8. #### Renaming of `clearschedule`
1. This is mostly regarding `clearschedule`, as `clearschedule` could easily be mis-entered as `clear schedule`, which would clear the addressbook.
2. Proposed solution 1 : Rename `clearschedule`.
3. Proposed solution 2 : Make `clear` not allow any input after `clear`.
8. #### Deal with input restriction in `Name`, `ScheduleName` field
1. In the current implementation, `Name` and `ScheduleName` limit user input to alphanumeric characters. This may be a problem as for example, some people may want to add non-alphanumeric characters like "interview @ Marina Bay Office" into `ScheduleName` field, which is not allowed.
2. Proposed solution: Change most disallowed inputs to be warnings instead of disallowing them.

Loading