-
Notifications
You must be signed in to change notification settings - Fork 5
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.
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
Add functionality to whitelist and blacklist commands #156
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few comments, and perhaps add some testcases, but overall looks good 👍
// make the find command do the hard work | ||
return (new FindCommandParser().parse("find cs/blacklisted")).execute(model); | ||
} catch (ParseException pe) { | ||
return null; // this will never happen |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By any chance would it be good to have a good error message/log message anyways? In case find command changes or other code is modified? But for now, I agree, it won't happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This portion of the find command is reliant on the ArgumentPredicate
being changed, which is highly unlikely. But in the future I will be decoupling the blacklist
command from the find
command entirely; this was just a quick addition that I did not want to initially spend too much time on, so I could focus on the test cases and the whitelist
command.
// here, the predicate dictates that the client status should be blacklisted; | ||
// hence if the predicate fails (ensured by the ArgumentPredicateToFail object), | ||
// the client is not blacklisted => they are whitelisted | ||
model.updateFilteredPersonList(ArgumentPredicateToFail.getNotBlacklistedPredicate()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for my understanding, how come there is a different execution for whitelistcommand and blacklistcommand? Couldn't it be easier if there was a predicate 'getBlacklistedPredicate' that kept things consistent and reduces Blacklist's dependence on other code? That being said, I think this still works 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I will be decoupling the blacklist
command to make it work more like the whitelist
command later on, that was just an easy temporary fix.
src/test/java/seedu/address/logic/commands/BlacklistCommandTest.java
Outdated
Show resolved
Hide resolved
Remote change was made to resolve merge conflicts.
LGTM |
Previously, the
whitelist
andblacklist
commands could only whitelist/blacklist clients. Now, their functionality has been extended to all users to also list out all whitelisted/blacklisted clients through these commands.Fixes #151
Fixes #149