tP comments dashboard

Sorted based on the number of comments given to others' PRs, but also showing comments on own PRs and other comments given. Updated weekly.

[This page was last updated on Apr 08 2021]

This might sound like a bit of nitpicking, but then if I don't other teams might, the "adds" in this sentence can be confusing, perhaps we can use something like append/include/insert? Same for the things below.

I think this is the same issue as what you have raised about separation of the add/delete of dog/owner, in this case shall we just keep things simple and simply call it "missing required information"? To maintain clarify we can put a note at the bottom saying what field are required for dogs and owners. Doing it this way reduces clutter since we can combine more things together, makes any future edits less likely to miss out any detail.

the image name needs to be wei-yutong.png to match your github username, you should be able to rename it easily thru gui or by using the git mv command

Your link is https://nus-cs2103-ay2021s2.github.io/tp-dashboard/?search=&sort=groupTitle&sortWithin=title&since=2021-02-19&timeframe=commit&mergegroup=&groupSelect=groupByRepos&breakdown=false&tabOpen=true&tabType=authorship&tabAuthor=wei-yutong&tabRepo=AY2021S2-CS2103T-T10-1%2Ftp[master]&authorshipIsMergeGroup=false&authorshipFileTypes=

the blank lines prevent the table from appearing correctly

Remove this line perhaps?

Maybe we can include dogs and programs in here too?

I feel that this line a bit weird? It does make sense though if we have the feature to take note if someone has paid for the upcoming program.

There's the black circle symbol, is this intended?

For headings I think it is fine to leave out the bold if we are going to use headings. It is also necessary to leave a space in between the # and the word after for it to take effect.

As in the hash-tag is a hash-tag not used as heading? Because throughout the document it seems like they are intended to be headings, if you preview the rendered markdown.

Yea, you can refer to our submitted user guide.

Oh but if we still want to keep the dot right, would it be better to use the markdown representation so it is rendered nicely?

I closed it because idk how to rename the commit message xD.

You can try git commit --amend -m "Your new commit message".

this might need to be a part of the addressbook instead, given that storage will likely modify it after reading back the saved file, and especially since in the tests there will be different addressbooks created, but a simple equal will fail since there is no way to sync up the id numbers

isn't it just otherOwner.getID() == getID()? and I think we can do away with this check since it is reasonable enough that 2 owners with all details that are the same point to the same person, and some tests also uses this method to compare between owners.

maybe do some basic checks at this point for the owner keyword? the tests can also be updated this way and at least the syntax will be updated.

This is a really strange change, might be due to the problematic git history.

This is not a bug, if you look carefully at the condition that triggers the exception, it is either when some compulsory arguments are missing or that there is some additional things in between the command keywords and the arguments. In this case, saying the unknown argument might be applicable, but only for the latter scenario. The more useful thing choice is to display help for the particular command or even subcommand like add owner will display the specifics are adding an owner.

Try not to introduce additional line breaks that do not have much meaning.

I like that you have added in the javadocs, however, this is to be kept private as it is an internal helper method that should not be exposed to any other users. Perhaps you made it public in order to write test code for it, but I think it is better to refrain from that since it is the public API that we are testing out, the test code should not care about the actual implementation so long as it does what it promises. Else we will fall into this never ending issue of making all methods of every class public. I could have inlined these two lines into the switch case of the main parse method, but for SLAP I created the helper functions.

As commented above, this testing should not happen anymore, but should instead be tested through the parse method. Also, try to make use of the constants already defined to come up with the command instead of the magic literals.

The brackets of the the lambda arguments should not be split into 2 lines, especially not when they are empty.

checkstyle has passed for these code or else it won't have been possible to merge them, so I think it might be a problem with your IDE configuration.

Yes, you can take a look at the rest of the code base and see how it is done for the others. Especially for helper methods that are more concerned with internal implementation, they could be very dynamic and change every time.

is this going to match all kinds of date formats or just our specified one?

I think we came to a conclusion last week that this field is to be storing an ID of the owner.

does it mean dogs can have the entire spectrum of sexuality now?

Nope this is perfect. But just need to make sure that the LocalDate parser is able to handle this variety. Maybe add a comment above it to indicate what it is looking out for? It will help make it more readable.

Yup, the idea here is to take in the ID and verify with the backend that the owner does exist for this ID to be considered valid. But you can just put some placeholder functions now when it comes to the adding part.

Hmm, then do we want a validation regex just like the date?

a bit of nitpick but got extra lines

perhaps there's a more succinct way to express this, but i think it's fine for now

I was wondering if it is better to store the date of birth and calculate the age from there.

Oops

I'm not so sure if we want interface templates instead of abstract base class, since interfaces only define methods, no common data like name or tag can be made common, the other thing is when it comes to writing functions like find it might be difficult to avoid boilerplate code.

where the spectrum hahaha

Maybe we can avoid the dilemma just by calling it Sex, since gender is what you identify with, sex is biological, easier to just have an other instead.

Is it better to store it as LocalDate instead? this will simplify a lot of things especially for the getAge method. And it will be easier for us to manipulate into any other format elsewhere, say the UI and json.

Is it cleaner if we just parse using LocalDate right from the start? Something like LocalDate localDate = LocalDate.parse(dob, DateTimeFormatter.ofPattern("d-M-yyyy"));

Is the indentation here supposed to be 8 spaces? Can consider updating your IDE settings to automatically indent by 8 spaces.

package private?

Tbh I'm quite keen to remove the use of INDEX__, because we have switched to referencing by ID and not by the visible index number. For this method it is fine of course, but there is a need to probably remove Index and create an ID class in its place, but that's probably another issue to be created.

Not to mention the convoluted construction and usage of the Index class doesn't seem to help.

I only have myself to blame for this, maybe at least we can extract it into some form of a helper method in the util class? it isn't very straightforward that we are deleting the first dog since we are still using getTypicalAddressBook just from a different class.

This is referring to the ModelStub btw

As in because previously there was only one CommandTest so given ModelStub's nature it made sense to just have it as a private class of the Command, but going forward we probably want to abstract out a bit of these test code as well. The ModelStub should become a package private shared by all the CommandTests, it will be good to combine the tests under AddCommandTest.

do you want to change it to entity-level

int can never be null, that's why it doesn't have the check. and perhaps you can update the javadoc to refer to Entity while you're at it?

can just delete directly since all usage already changed

hmm why expose the this actually?

I think can revert this portion of the commit and preserve the one above.

I don't quite understand the reason behind this change. There's another one below as well.

This particular overload is to make it possible to use the same ID across restarts using the one stored in the file. The check for ID is not redundant since it is possible that someone modified the file to make 2 entities have same ID, then they will come and file a bug.

same as what was mentioned above.

this is very dangerous, it exposes the internalList directly to modifications beyond this class, is there a reason for this?

maybe use a valid ID number? I think I have settled on positive integers.

okay I think i get the rationale for the returning the internalList directly, but it is alright to use the unmodifiable version as many other tests does the same. Also I think if this is targeted at owners but will not test dogs, it is a good idea to filter using instanceof as well.

same the other one

Okay I understand this portion now, it might seem fine to do this for now, but the issue is that this codebase isn't very small, having equivalent api will confuse others that are not so familiar with this portion, and any direct modification is now possible since Java passes by reference, it will be difficult to track down bugs if someone modifies it and violates the assumptions we have about unique entities etc.

this can be another test to remove an invalid ID equivalent to the null test above.

this indentation doesn't make sense, since it is a continuation of the bracket of the previous line, the && on this line is not at the same level as the || on the previous line.

Could use some updated variable names.

This also can be renamed.

Here too!

Naming for this as well.

extra line breaks!

is it better to use the hasEntity method to check if the ID exists and throw an exception if it doesn't. then we can assume that getFilteredEntityList will return something that definitely contains the owner, then we retrieve it for real this time and check if it is indeed an owner object instead of any other entities. It will be better to use the setEntity method to change the target owner by creating a new copy with the up to date details.

arrayset might be better?

as mentioned in the AddDogCommand portion, it will not necessary to directly modify the Entity objects since all attributes are constant throughout the lifetime of the object. This is to align to the original AB3 codebase whereby the edit command also modifies by creating an updated instance of Person before asking the model to set it as the new one.

there shouldn't be a need to do this as well.

Hmm then maybe HashSet will do also, btw can just leave it without the specific type of implementation, i.e. List instead of ArrayList, Set instead of Hashset, there's a discussion on the forum on this.

and a set makes more sense for our case, since we don't really need an order to them, it is more ideal in the sense, but why not get it right at the start and not worry later.

Another thing of note is that we have to ensure that the check that the entity we have is an instance of Owner first, or else we might be downcasting illegally, it would be a good opportunity to throw an exception along the lines of id doesn't refer to owner.

Will it be better if we keep naming a little more consistent here? Since elsewhere in the I have already used something like idEntityPair, it will be confusing to see idEntity here since it can be ambiguous. I think a better alternative would be to simply name it idNumber or simply just id.

There's an extra line break here. Other than that, another naming thing again, this applies to other areas as well, is it better if we use either id or ID in the naming and don't mix the casing? It helps to make things consistent as well.

Naming is especially confusing for this part, since idEntity supposedly refers to a pair already.

Refrain from commenting like that, a better practice when using git is to simply delete all these lines that you don't need or want to disable, commit this set of changes as an individual commit. If you intend to fix it later, maybe leave a todo around the original area. This way even if we don't implement it there won't be a need to clean up the code much. But if you do intend to restore this portion, it will be simply a matter of finding the commit that removed the lines and reverting it, creating an additional commit that essentially negates the removal yet retaining full history.

this makes Owner mutable.

and also this.

Maybe can declare an integer on top first but don't initialise it? then in the try part can use the result of parseInt such that it can be directly returned below.

indent one more layer.

This is not something that is meant for an assertion, since it is one of the expected possible errors that we need to handle. Assertions are for verifying assumption that should not be broken and if they are indeed broken, the program is unable to handle and we need to investigate further. I suggest that this be removed.

this needs to be removed

this instance here is redundant as well, since it will cause the if below to trip otherwise.

is it better to separate into 2 conditions so the error message can be a lot more precise?

instead of calling getEntity multiple times, it seems better if the result is saved first and reused later, the code will become more readable this way. and i think it is fine to separate the 2 checks here as well, since for a lot of other commands it fails at the first incorrect one.

this comment does not explain the invalidity well, since session but not obvious, thus it is better to explain it as an illegal date format

does the java coding style require that the indentation be aligned this way? this seems more like a c/c++ styling

I know this is a copy and paste from the tests for owner, but please drop the unfiltered part, if you wish you can drop them from the owner side as well. You probably don't understand the original behaviour of AB3, but it originally referenced to every entry by their index in the displayed list, thus filtering makes a difference to whether or not one can reference to a particular Person. We have since switched to using ID and whether or not the target entity to be edited is visible or not no longer matters. If you haven't noticed, there is no longer a filteredlist complement test as I've deleted them, but to prevent too many changes in one PR I refrained from doing the small renames.

How about doing this test for the EditEntityDescriptor instead? While testing here may or may not be redundant, it helps more to test the base class as well in case the bug actually lies inside there and the child classes are just a distraction from the real problem. This applies to tags as well.

I don't understand the rationale behind this change

For typical dogs, I have inserted an owner so as to make all dogs have a valid owner. And that the ID of the owner is 1, therefore all dog IDs are offset by 1. The fix here should not be with the dog ID, but rather it should be the input text. You might feel that both are equivalent, but fixing it like the current way is convoluted and nobody can understand why the input is 1 yet the ID of the first dog does not match.

it is ID now, please help to rename for all the various tests as well.

could use consistent format like above.

comment needs updating.

in this case all fields should be repeated including the owner id

it will be good to test against EditCommandParser as well. I know it is an abstract class, but it is possible to create a simple implementation and test against that, especially for things like tags which there is a protected method that handles it for all classes. That way things like preamble etc only need to be tested once and not repeated since having repeated test cases on the same thing does not help with code coverage or prevent bugs but only increase the execution time of tests.

It will be good to adhere to the DRY principle and apply some OOP like in the main codebase. That way setName and setTags can all be simplified. It helps that EditEntityDescriptor is already in place so there isn't as much tweaking to do. This was also one of the reason I rewrote the Edit command implementation to ensure minimal repetition, avoiding potential points of failure when copying blindly and not keeping necessary parts updated.

Similar to the builders as well, using OOP to adhere to DRY principle is better since we have no test code for test code, else this will result in some infinite recursion.

originally this file worked together with only one typical addressbook, but now there is 3 copies on top of the fact that there is no longer ID, I think it will be better to define these constants directly within each addressbook to avoid confusion. Each of those addressbooks require better naming as well as they are not descriptive at all and there is nothing typical about them. To make it more typical, perhaps it is good to just combine 3 of those into a TypicalEntities class instead. Something like getOwnersOnlyAddressBook and getSingleOwnerMultipleDogsAddressBook will help make things clear.

can there be examples here as well?

this should be pawbook?

Still got addressbook here

do you want to also rename the json files?

the method names too!

probably need separate this rename as part of another commit so as to track as a rename instead of creation of new file. There's several references that needs to be renamed as well

this line is copy pasted from somewhere?

this one is a comma

tbh these message won't be in use anymore after @shaelynl and @wei-yutong merge their enrol and drop changes in

I think it is necessary to retain the original message to make sure the user calls the relevant methods beforehand to ensure the file is valid.

i actually meant that it is one indent more than the previous line, relatively speaking in this case. sort of align to the open parenthesis.

I think here I removed one of the comments to avoid that awkward indent or not problem.

maybe we need standardise whether to put a line break right after the requireNonNull statements

don't you think it is neater for the body text of the description to be aligned, this one is not very strictly specified though, but i'm fine if everything is done this way

this assertion isn't pointless actually, as the editEntityDescriptor variable is of the parent class, though initialised as one of the child classes, with no programming errors this shouldn't be triggered, but if initialised wrongly for the wrong command then this might be an issue.

actually isn't it just [ID}?

is it bad to remove the line break here? as in the intention was to make it clear that normal case is above and the default should not be triggered, i'm honestly not sure if it helps

Is there a reason for not doing anymore integration tests?

Sorry I didn't make myself clear, I meant to drop the UnfilteredList portion in the name, not to drop the integration tests themselves. Previously there was both UnfilteredList and FilteredList versions of these tests. I have removed the FilteredList versions that's why you see the UnfilteredList ones remaining. It will be good to write similar tests for the other 2 classes as well.

Link to the general release page, or else we will have to keep updating to the latest release and we might just forget.

Here you might want to explain what each of the letters mean, especially since "mm" appears twice and it becomes ambiguous. Perhaps it is better to follow the code convention and capitalise one of them.

As in I think that even this format it will be good to specify what each one of them means, like mm refers to minutes should be 00-59 etc, to prevent some lunatics from going crazy. Also this portion is kind of general, you might want to explicitly mention that the birth date of the dogs follows a similar format, omitting the time portion and that the date has to be on or before the current date.

This part also needs to be edited, to keep things short and succinct, it would be good to just have a link that redirected users to the add portion for details on the parameters to keep things simple and not repeat yourself.

It is the command summary that is wrong

Makes more sense check this within NameComtainsKeywordsPredicate

just statically import, looks neater

Violates DRY principle, can just use ParserUtil.parseId here

requireNonNull

is this a mistake? I don't think I see any cardPaneDog around

What does the generic parameter do?

is it better if program is explicitly matched as well? then you get to do some defensive coding by asserting in the else

is there a way to specify this in fxml? I think it is generally better if parameters that don't need to be dynamically set be left out of the code

why is this test method renamed? isn't it correct?

leave out the file if not written so others can easily tell if the test has been written

this isn't used anywhere, I think it is better to leave it out and let the person who is writing program tests to everything

date is optional, place the [] around it

I think the better way to phrase it is that everything should be in sync and mirror each other when accurate. Two wrongs doesn't make one right. You might want to just update all since these are all documentation issues.

I don't think there's a clear cut answer to your query, I'm not sure if the UG is fully accurate as well, the only correct format is what the application currently accepts.

Tags are only able to take in...

The name of the css file has been changed if i'm not mistaken, changing it will break the current theme.

I think this portion is still problematic, the ellipsis is necessary, what i meant was text getting cut off due to the column width

you might not want to have dogs enrolled for the manually added programs, since it doesn't make sense for a new program to have any dogs enrolled, perhaps it is better to restrict this default list of dogs to the ones that's part of the typical database

I would say avoid defining dog IDs this way, especially since none of the others entities have defined their IDs this way. ID is largely dynamic and only because of the typical database being largely static that's why it was hardcoded. For tests that require the dogs IDs to be present but not necessarily correct, I suggest using the TypicalId class and use some of the numbers inside.

I think the method name convention should be "success" at the back.

I actually intended for getTypicalDatabase to eventually contain all types of entities and use it throughout all tests so number and whatnot are more or less consistent.

hmm maybe consistent use of the constants? avoid the literals since you have defined the literals

Yay good use of streams, but it will be more readable if it is something like:


String expectedMessage = String.format(EnrolCommand.MESSAGE_SUCCESS_FORMAT,

        dogIdSet.stream()

                .map(String::valueOf)

                .collect(Collectors.joining(", ")),

        ID_FIFTEEN);

Of course, adjust the indentation as necessary.

Maybe use Arrays.asList(ID_TWO, ID_FOUR, ID_SIX)?

Then it will be possible to use the addAll method to make it more succinct.

This could use some rearrangement to match the dogs and owners so it is clearer which are the ones manually added and which are part of the typical database.

should there be valid test cases as well for sanity checks?

it would be good to test one or two problematic dates like 31-04-2000 etc, though the bulk of it should be tested against the parserutil. And if I'm not mistaken there are 2 constructors for this, one that accepts string and another that accepts LocalDate.

generally same comments as the dateofbirth one

Lel, is every number used?

There are leftover remaining.

These are also part of the undo

If you look at the source code, ReadOnlyPawbook doesn't exist, those references to AddressBook has been renamed to Database instead.

In case you miss out.

Here's another one

This should be the last one.

this one kinda violates the naming conventions, maybe drop the number for the one above and just reuse the same variable

does this not conflict with #400?

there could be more failures as well, like drop a dog that's not enrolled etc.

I did this slipped my checks, but coding standards still need to be adhered to even for test code, it looks like bad practice to name variables with the number at the back, and it is fine to repurpose a variable after it is done. And I think if after these kind of changes, there are 2 highly similar blocks of code, maybe its time to extract a function out?

Do you mind explaining why this is taken away? I cannot seem to find a reason that the override should not happen.

add a test that changes the owner ID, and also one that causes a duplicate, change the other 2 accordingly as well as you deem fit.

do you mind explaining why casting is necessary?

and this too

it is ID now

here also

check the javadoc!

how about invalid values for the other attribute fields like sex?

are you sure this is all that's editable?

owner?

see my comments for the dog version

you need a resetSessions equivalent

I think we need another test that ensures that those repeatable fields like tags etc, if different values are supplied, all will be captured, and if repeated, it will be deduplicated correctly.

I don't want to do any finger-pointing here, while this is my oversight the previous time, it would be helpful if you broke down your commits such that every commit has a purposeful message along with the stated changes, that way it is easier for me look through at each step and figure out if anything is wrong. However, all that I get here is around 1k lines of code changed, barring the fact that the previous commit history didn't carry over, it is really difficult to be that careful. I won't request that you review what I changed for you in the previous PR, in short your builder pattern was less than ideal, thus sub-type information was lost, hence requiring the casting. I fixed it to avoid those issues, but since extra casting is not technically wrong but just poor coding practice, there wasn't anything that alerted or reminded me that these portions needed to be updated to remove the casting. The fix here is simple, just remove the cast. Do let me know if you don't understand any part.

Restore it back, it is essential, or else when the owner ID of a dog changes, the old owner will still have the dog

It is not just whether or not someone is going to review it, git commits are supposed to be incremental regardless, the previous PR could have been kept by merging in the latest master and resolving the conflicts. By creating another PR the commit history and authorship are all gone, that's the same reason I previously tried to restrain myself from directly pushing to existing PRs and make everyone perform the minor changes themselves, it actually takes more effort to type all the comments I have given than to directly modify them myself.

I'm referring to more test cases that can be written, this line is the most logical thing I can point to. For tags and sessions, repeated values are all captured, but the tests clearly don't look out for this, in this current test case there is only repeated tags, which will be parsed as one.

To avoid any confusion, I meant to add an additional test for this, not to rename this test method.

my bad, do standardise how the comments are placed for the block of code, if i'm making this mistake it means the assessors might also make similar mistakes, where you won't be able to explain yourself anymore

the point of doing repeated fields is to ensure that only the last repetition is taken as the value, you have repeated the same owner ID twice...

the method name implies that multiple fields that should only be specified once are now specified multiple times, in which only the last repetition is to be accepted as the final value, programs clearly don't have such a field when being edited, both tags and sessions accepts all of the fields and will only ignore repeated values, what I need from you is to write test methods that instead test if multiple tags & sessions are all accepted.

Also, in the copy-paste process, you might have not spent the time to understand what each of the test are doing, there is an expectedModel which we modify by hand in the most crude way to keep things simple and avoid errors, while the model is the target that we let the EditDogCommand execute on and therefore modify.

Just in case you don't understand how Pawbook works, I will explain it here in the interest of everyone's time. Every dog has an owner, and so long as the dog exists, the owner must also exist, but not the other way around, so owners can be dogless and still exist. While we don't allow for dogs to be created without a valid owner, it is possible to change the ownership afterwards. If the edit requests for dog with ID 2 to be owned by owner with ID 3, obviously the original owner with ID 1 now needs to disown the dog, followed by owner with ID 3 taking over the dog instead. In case you're still confused, 3 entities have been edited at this point, 2 owners 1 dog.

You might want to go to Settings > Editor > General > On save, and enable Ensure every saved file ends with a line break, can prevent future CI from failing.

that EOL thing is really quite annoying, can refer to anli's pull request where I detailed the instructions to make the ide add the extra line at the end of every file

do you want to split this PR into 2 though? like it is easier for someone else to just merge your README updates separately, plus adding the mockup image first also allow everyone to get a copy from master faster

Quick question, do you intend to do the formatting now or just leaving it in this state? Because as you are the first to completely rewrite the user guide, this will set the precedence for others.

Also, you might want to create an issue and assign it to yourself for this.

You need to rename the image itself too!

Duplicate of #51

You might want to install the checkstyle plugin on intellij and run it locally before committing. Another way is to run them using the command line via gradle like what the course material mentioned, which I will not repeat here. There are two advantages to this, firstly you get feedback faster, since it is much quicker to run locally than for the CI to return its results, next several of us are watching this repo, each pull request and separate commits pushed to a PR will generate notifications/email for everyone subscribed, reducing unnecessary notifications will be helpful for everyone.

Another thing I've noticed is that intellij files are seeping in, i.e. src/.idea, by right .gitignore is configured to not add these files, you might want to check your setup to ensure that the excluded files are indeed excluded, else your future PR might still have the same issues.

Merged #110 instead.

Kindly sync your master with the team repo and rebase this branch on top of the latest master, dropping the merge commits along the way as well. The current state of the PR has both unnecessary and also wrong changes.

If you look at the commits you're trying to merge, there's 5, only the last 2 are really relevant. The merge commits when you merge master into this branch can very easily clutter up the commit history, making it hard to find bugs later on. If you do not want to rebase, try to avoid merging unless you need to resolve conflicts. Otherwise, a rebase is a good idea to keep the git history linear. I will elaborate on the problematic code in the review.

you need to fix your git history, you're recommitting past commits and changing the git history. it will cause trouble for the reposense tracking

@branzuelajohn after merging this you should be able to rebase your branch on top of it and be able to merge #137

It is unnecessary to update the undo feature related DG and UML, we are not implementing it nor are we keeping those sections.

I think some of my feedback for the previous attempt at writing test still stands, like the typical addressbook ideally should be combined as one since there's no benefit to having 3 that's hard to maintain, I do see some effort made to refactor some tests, but some generics are not written correctly. Furthermore, I think while most of the edit implementation can be attributed to you, kindly exclude the edit program ones as you initially only implemented edit owner and edit dog partially.

It would be good the break up your commits into several commits that each does a specific change, this way it is easier to see what each one does and also pick out part of it to merge first if necessary.

Do you mean combining the TypicalDogs, TypicalOwners and TypicalPrograms into TypicalAddressBook?

Yes, more like TypicalDatabase after Anli did the rename.

Although we are not implementing it, I juz changed it to Pawbook for all those diagram so it fits in unless you want to remove. Coz for those parts that we are not implementing is written as address book. This will make it neater.

Yup, I rather you remove them than to merge extra diagrams and whatnot. Do just amend your previous commit so everyone won't need to download diagrams that has already been removed.

Can you merge this first? I'll make the changes for the typical addressbook thing in the next PR

Sure.

Some of the images that are no longer referenced are being edited and instead of removed.

If you look properly, the addressbook in the uml diagram is changed to pawbook.

If you look properly at my previous reply, I was referring to puml files not updated while the PNG files are updated. And if you look properly at your commits, you didn't include the updated puml files 😃

This is a non-issue, we need to update the documentation to reflect that only upcoming timeslots will be shown

This can be considered to be fixed, perhaps in the date validation portion.

@branzuelajohn might want to look into this, along with the possibility to use tabs to select also, if it is difficult to make this feature conform to usual CLI behaviours, we might need to take it out.

The rationale behind requiring the entity type for delete is that delete is a dangerous and irreversible change, hence it is one of the safeguards to ensure that the correct entity type is deleted. Whereas for command like view this precaution is largely unnecessary since it is a read-only operation.

We need to relax the condition of the equals check to resolve this, trivial fix. Might need to look into the various entities as well.

I don't think it is necessarily a bug, since some programs might be concurrent due to how training works and perhaps there's a continuous rotation between 2 or more programs

Not too sure if this is necessary, this has got to do with GUI design.

I would think that this is a invalid bug since it is not necessary that a name must not be numeric, especially for programs which sometimes has a codename that is purely numbers.

Cannot reproduce for now, needs further information from author.

I think we need to make session optional as well.

I feel that this doesn't need fixing, since we support arbitrary length phone numbers it is a feature rather than a bug. As the world population increase, we may need to constantly lengthen phone numbers so there isn't a point in limiting it in the first place, unless we are indeed validating that the phone number belongs to a real user.

Able to reproduce this, the issue is that delete command retrieves the entity manually from the filtered list, which is a mistake. The solution here could be to use the unfiltered list instead, however, there are already ways to retrieve an entity directly using its ID, that method should be used instead, similar to how edit is done.

to be fixed together with #303

This is similar to #287, probably need to update the documentation to state that we are only showing the upcoming timeslots, and at the same time display "none" if there isn't any.

This is a documentation bug, not a functionality bug

I suggest we stop using brackets, it is confusing and always inconsistent, let's just switch to using colours instead.

This has a simple fix, date validation currently uses the parser directly, we just need to convert it back to string to see if it still matches to avoid all the silent rounding.

Duplicate of #289

We need to do away with storing the sex as a string, store as a enum instead.

Poor phrasing here, the words after "and" should all be removed. Where the ID is located should be explained through a screenshot, not using confusing words.

This is a duplicate of #315, it should have been more generally phrased as M and Male are actually the same but is different to the application.

Similar to #291, we need to reintroduce the isSameEntity method for proper checks.

Similar to #291 and #318

while constraints of the tag need to be defined, the first half of this report is unnecessary, the second half shouldn't even be a bug report on its own either.

same as #288, another person who doesn't like to give chance to time-travellers

In this case it is hard to quantify what exactly is a valid home address, for some place, only the postal code is necessary, hence an address consisting of only numbers will work, if address must contain letters from the alphabet then it will become a bug for those cases.

Rejecting for the same reason as #294

Repeat of #287 and #306

I think this is common sense, and that I think it is safe to say that no one will recognise 99:96 as a valid format for the time of the day, it is more likely to be the score of a basketball match. Thus this is wrong format also, the letters themselves already carry additional constraints with them on what numbers fit and what doesn't. Format is not simply about the numbers or else we won't have used letters as placeholders.

This is invalid because a program timing could be added retroactively, and even without that assumption, enforcing such constraints is not feasible since the actual json file can be edited and there is no way to determine if the rule holds when restoring. That means the user can still bypass these checks under the current design.

The severity is at most low...

Marking as invalid until reporter provides steps to reproduce.

Duplicate of #291, #292, #318, #319

Should be same as #298 and #304

This is purely cosmetic as the message still gets the point across.

Perhaps we should highlight more clearly that it is an ID not index, and that by default everything is listed.

It's a some people want to eat apple, some prefers pear problem. There is no single way to satisfy everyone.

There's nothing we can do about a user who doesn't read right?

No concrete steps given to reproduce bug, marking as invalid until reporter provides more info.

we need to state the fact that all tags will be overridden in the UG

The list owner/dog/program commands exists for a reason... This guy isn't reading

At the same time we can state the constraints of tags in the UG to be an alphanumeric string

Can you drop commit 26621e2? Otherwise everything looks good.

I don't know what you meant by rebase either, it is too vague. There are 2 types of rebase, one that changes the root commit of the branch, i.e. the point whereby the branch branched off, and another is interactive rebase, where you can change the history of the commits through a variety of options like rearranging them, squashing them aka combining, or dropping some commits, which is what you want to do. What you have done seemed like neither of them, since both will rewrite the commit history and require a force push which evidently isn't present here. From what I can tell, it seems like is you have cherry-picked an irrelevant commit from @ZhangAnli that's already in the master branch into your current branch. Give it a shot to find out how to correct your git history, what you need here is an interactive rebase, in which case you can also take the time to edit the commit that you deleted docs/images/EditCommandScreenshot2.png and undo the deletion such that there is no longer a merge conflict. While I can perform these operations for you, I don't want to take away the learning opportunity from you by directly modifying your branch.

I like the colour change, but it doesn't seem like the issue has been resolved. I think what users expect is that the suggestions isn't selected unless arrow keys or tab is used to trigger the selection, then without those keypresses, the enter key will work for the command box directly, so commands like list and exit only need to press once without dismissing the suggestions.

The help window still isn't big enough, especially the Format column needs to be wider, such that there's no longer ellipsis at the back.

If you want to work on the program right, I suggest following the Owner and Dog closely, even the examples should be similar, so there's "Program A", "Program B" etc, some will be manually added into the database while some are part of the typical database, if you notice the way that the OwnerTest and DogTest are written, most of the comparisons are actually between one that is within the typical list while another is from the manually added ones, preferably the new tests also follows the same to keep things consistent. The typical database will come in really handy when writing the delete tests, since some parts of the test will spillover into the delete dog portion to ensure that the dog ids are no longer within the enrolled programs.

I forgot another issue I want to bring up, while writing test case will let us discover bugs, it doesn't always mean that something that doesn't work with your test case is wrong, it might be that your test case is written wrongly in the first place, before modifying the functional code, please double check or even do some manual testing to see if the bug can be replicated to confirm that the behaviour is wrong...

To save you the hassle, the mistake you've made is forgetting to delete the dog ID its owner. ---- On Fri, 09 Apr 2021 18:52:41 +0800 @.*** wrote ---- Made those changes! Just that after restoring the execute() there's one test case failing in editDogCommandTest which I have commented out. I need your help for that, I have tested the database.equals(other.database) in equals() of ModelManager is failing. I tried printing it, the database is exactly the same object but it fails...

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

It's fine, breaking down PR is for every PR to serve a single purpose, I rather not have a single PR for every "minor change" or "some change" that you have made. This PR dragged long enough that a little while longer won't hurt ---- On Fri, 09 Apr 2021 18:54:45 +0800 @.*** wrote ---- Also, is possible to merge this PR? coz it's getting bigger

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

Remove empty space on new line >_>

Formatting!

Swap the parameters to be consistent with the rest of the assertEquals

nitpick: that should be named other iirc

No need else clause here. Can reduce the indentation level.

Its not exactly a nameString. Rename to searchString

Got better name? I think calling it anniversary would feel better other than date.

return time == null, no need to store another instance variable.

Can just check using time == null

No space between Event and (

nitpick: no need else clause, just return

Style violation, supposed to be 8 spaces from the preceding line.

I think better to store as LocalDate. Can use #41 dateUtil to make it easy.

Use DateUtil.fromDateInput(...) to get back a LocalDate. Use that to create Birthday. This will not change the tests that were already written.

Wrong comment. Should be {@code Birthday}

Probably can do the dateUtil parsing here too

Yes, we should still do it. I added some comments to the test files. Essentially, when we create the test objects, we parse the dateStr to a LocalDate using the util methods. i.e. withBirthday(...) takes in a dateStr, parses that string and returns a new Birthday with a LocalDate in it.

I think this should be in the present tense. if they are not in it

Can be shortened to


return Arrays.stream(arr)

  .map(ParserUtil::parseIndex)

  .collect(Collectors.toList());

I think there should be a space between the arrow heads. updateFilteredPersonList(x -> group.getPersons().contains(x))

Wrong indentation, change intellij settings

Having a parameter here is out of the norm. Can add a comment here saying that it requires the actual personList serialised from the persons json file?

Multi-line for readability. I think the lambda has a spaces enclosing the arrowhead.

Not optional parameter. This line should be + PREFIX_INDEX + "INDEX"\n

Should we have the command name be del-date? Easier to type a shorter command

I think this could be better.


LocalDate xRelative = x.compareTo(now) < 0 ? x.plusYears(1) : x;

LocalDate yRelative = y.compareTo(now) < 0 ? y.plusYears(1) : y;

return xRelative.compareTo(yRelative);

Can we have date.setText(personEvent.toUi())? Makes it easy to test the formatting later on

We should store the localDate here instead of taking only the day and month. Easy to change formatting later on.

Should have a toUi method here to do the formatting using the LocalDate formatter methods.

PersonEvent should have no knowledge of Birthday and Event classes, put these two helper methods in their respective methods. They could be named toUi() too.

So for here, it will just be person.getDates().forEach(event -> personEvents.add(new PersonEvent(event.getDate(), person, event.toUi())

person.getBirthday().getBirthday() is very strange >_>. Can rename to the last getBirthday() method to getDate()?

Rename to getDate()

Ok, got it. Lets leave it here first

👍

Is this still temporary?

Should this be date.toUi()?

Possible to create another component to store the profile picture? The same code is used in PersonDetailsCard and PersonCard.

I think you have to write the b/ prefix stands for. I think we can leave birthday there. Users should know to supply a date from the examples below.

Would this be better? Can optionally provide a group name to list all friends in that group

I think we should still put Birthday here

Would be good to write docs on the specifics for Event and Picture as it is not clearly shown in the class diagram. Like the multiplicity of Person to Event (1 to *) and multiplicity of Person to Picture (1 to 0..1)

I think would be good to document something the rationale for this

Ok, btw I was talking about the usage of a single Person in the detailedPerson observable list. That one probably need to document the rationale for it.

Can just do static import, then it will look like private final Frequency frequency

Should use static import

This runs goal.getNext() with the lastest meeting date? If it is, should probably write.


Date latestMeetingDate = meetings.stream()

        .map(Event::getDate)

        .filter(x -&gt; x.isBefore(date)

        .max(LocalDate::compareTo)

        .orElse(DateUtil.ZERO_DAY);

return goal.getNext(latestMeetingDate);

Need follow the style guide, don't use this in instance methods if there is no need to. Link here

I don't think method name is clear enough. getNextMeetingCutoff would be better. Open to suggestions too!

Can we encapsulate the ENUM_MAP so we could change implementation later on? Goal.isValidFrequencyString(frequencyString) would be a better API

Same for this. Goal.getFrequency(frequencyString) would probably be better.

Another way would be to convert into one method Goal.parseFrequency(frequencyString) that throws an exception if the frequencyString is invalid. I would prefer this as it would reduce the API exposed from Goal.

Should use Frequency frequency here


String frequencyStr = argMultimap.getValue(PREFIX_FREQUENCY).orElse("n")

frequency = ParserUtil.parseFrequency(frequencyStr)

The parseException from ParserUtil.parseFrequency(...) not caught here >_>

Goal.fromGoalString(goal.toLowerCase(Locale.ROOT) would be better. Can hide ENUM_MAP

person.getGoal().isNoneFrequency() would be better. Can hide the implementation away from UI

👍

Format: set-goal INDEX f/FREQUENCY can just use back ticks.

Where is the new ThemeCommandSequenceDiagram.png?

Oops, my bad.

This looks really weird. I think it would be better to just have two separate commands and parsers for add-debt and subtract-debt.

Should have two different commands for add-debt and subtract-debt

No need to have conditionals here if have two separate commands

What if negative value?

I think u are missing the formatter for 2dp. Need to pad with zeros for 2dp if float has only a single dp

Can we follow the order for initialisation according to the data fields order declared above?


public Person(Name name, Phone phone, Email email, Birthday birthday, Address address, Picture picture, 

       Debt debt, Set<Tag> tags, List<Event> dates, List<Event> meetings)

Follow attributes order

😢 inconsistent ordering from Person.java for attribute order

Shouldn't debt be after picture following the order from Person.java

Negative debt is valid? 👀

Should follow test method names for here, add() and subtract() command below

Shouldn't this debt be below picture

Debt probably has to be formatted with $ sign and 2 dp. Could do debt.setText("Debt: " + person.getDebt().toUi())

toString() could be used for debugging etc

Ok, got it! I think better document it here because it is weird that only the ChangeDebtParser takes in a boolean.

Ahh, the constructor of Debt rejects the init.

Ok! Should document that you can record negative debt in Debt class to signify that the user of FriendDex owes money to the person instead.

Can add a TODO comment here so we can refactor this if got time? The rest looks ok!

nitpick: should add a new line here for readability.

Newline here for readability.

Do static import here

This is to account for the meeting added today? Write comment above saying that the latestMeetingDate includes today

Need remove

nitpick: Use p in the lambda perhaps, much more related to person than x

Same for here p -> group.getPersonNames().contains(p)

New line here

style: should have space before and after the ->

Will the model.getDetailedPerson() be emptied out when switching to other panels?

i.e. will the list be empty if the app is not showing the detailedPerson view?

Ok got it

Arrays.asList(new String[] {"w", "week", "weekly"}) shorter line to convert to List

Use static import for the whole file, will be more readable

You should test something other than NONE since the default value is NONE

Why are we removing this? This seems valid.

Actually don't have to clone right?

Just rename all aliceCopy to ALICE, shouldn't need to copy here

.withMeetings(Collections.emptyList()) would be better

Can shift this to PersonTest because getTypicalMeetings() feels like I am retrieving all the meetings from TypicalMeetings but that is not the case here.

When would index be null?

You should create another method on Goal class that abstracts this out. Maybe name it toUi() or something

Use static imports for WEEKLY

Differentiate the magic numbers for jpg and jpeg

Can rename to MESSAGE_INVALID_FILE_SIGNATURE for clarity.

Better add in a comment saying that null bytes in magic numbers are like wildcards and can take on any values

JavaDocs incomplete. Need newline between param and method doc

"an integer with MSB set."

New line here for JavaDoc

Can you add in the isValidImage check here also? I think this is check is used when deserialising from the json data file.

Very nice tests!

Ooo, the magic numbers for them are the same? I think better to write which subclass are u targeting for each magic number.

"set MSB" is just the most significant bit flipped to 1 right? If that is the correct terminology, then I am okay with it.

Yeap, u can do that too

nitpick: can we standardise whether to leave a new line here and keep it the same throughout the UI components?

nitpick: lets keep it consistent with the other UI components and leave a new line here

Ok, thats great!

Singleton pattern? Better write in this class that ThemeManager is a singeleton.

Write that after execution of this method, the personNameToDelete is guaranteed to be not in the group. Also add some note saying that no exceptions will be thrown.

Document behaviour here also -> that the personToDelete is guaranteed to be removed from all groups.

nit: instance of the {@code person} with given {@code name}. No need the in this group portion.

Can add the markup portion here for CS2101? We wrote this here because it was in the sample UG

There should be a new line here

Two "Updates"

typo: "The Friend Panel gets list of all the"

Same typo

Can we add something here saying that the names are case-insensitive

Can we use something other than emojis for the invalid email because I am not sure whether emojis in emails will be allowed in the future or something

Can add a line to UG saying that names will be rejected if any emojis are found in it.

Should this be without?

Don't use wilful, use intentional, easier to understand. Also add the rationale for violating

Simplify to English for the format portion, nobody will understand the brackets and asterisk. Emails should be of the format "local-part@label". Multiple labels can follow after provided that they are prefixed with a single period.

typo: "example".repeat(100).

Can add in "Names are case-insensitive in FriendDex. This means that FriendDex interprets "John Doe" and "JoHn DoE" as the same name."

Can add in "It is okay for two friends to share the same address. They could be siblings stored in FriendDex."

Can we switch the definition for positive and negative debt. I feel it is more intuitive this way but let me know if you think otherwise.

Test positive boundaries also

assertTrue(Debt.isValidDebt("..."))

Maybe can create a function to abstract the checking out? E.g. isDebtOutOfRange(newDebt), could be created in Debt class as a static method

Person is still immutable, the setters are not changing the Person itself. Will change it to withDates instead of setDates because the set prefix is commonly associated with mutability.

This should work for asdf.tar.gz. .gz will be extracted from the function and validated.

I think its ok here because we are deleting the filePath of a picture.

Nope, this is still used when the Person being initialised has no meetings and no dates.

yeap, my bad

👍 too late alr

Will add as an issue first!

Yeap done

LOL, i just realised it too.

Yeap, it will be added. Adding meetings will always increase the streak if the meeting is qualified to be counted, i.e. in the same period of the first meeting that starts the streak up till today.

I will leave the explicit consecutive times out because technically any valid meetings will still add on to the streak if it is in the correct time period.

Quite hard to abstract this method because of circular dependencies. I am using this.toString() in this method.

Lets say if I create something like this to abstract:


/**

 * This factory allows the creation of IllegalValueExceptions with inbuilt logging. We assume that everytime

 * a class uses this factory to create an exception, that exception will be thrown and so we log. This factory

 * should only be used for throwing IllegalValueExceptions for errors found during json deserialization.

 */

public class JsonExceptionFactory {

    private final Logger logger;

    private final String clazzName;

    private final Object object;



    public <T> JsonExceptionFactory(Class<T> clazz, String clazzToDeserialize, Object objectToDump) {

        logger = LogsCenter.getLogger(clazz);

        clazzName = clazzToDeserialize;

        object = objectToDump;

    }



    public IllegalValueException build(String message) {

        logger.warning(String.format(MESSAGE_DESERIALIZE_ERROR_DUMP_DATA, clazzName));

        logger.warning(object.toString());

        return new IllegalValueException(message);

    }

}

In JsonAdaptedPerson.java:


// ...

private final JsonExceptionFactory exceptionFactory = new

            JsonExceptionFactory(JsonAdaptedPerson.class, "Person", this);

// ...

throw exceptionFactory.build(String.format(MISSING_FIELD_MESSAGE_FORMAT,

                    Name.class.getSimpleName()));

Will have circular dependency because JsonAdaptedPerson owns JsonExceptionFactory owns JsonAdaptedPerson, to put it simply JsonAdaptedPerson -> JsonExceptionFactory -> JsonAdaptedPerson

Will further consider abstracting it out if it becomes easier.

Lgtm!

Would be good for Event to use a LocalDate instead of String to represent date.

#41 fixes this

According to the updated image, the help command doesn't show a popup? I was expecting something like this with the new url.

Fixed with #97 and #98

Yeap, that's correct. I think you can think of it as weekly homework. If I were to complete my weekly homework on Monday when it is supposed to be due on Friday, I don't want the following week's homework deadline to be shifted to next Monday.

Fixed by #119

Fixed by #134

Add test to confirm error message so it won't happen again next time!

This is correct, just need update docs.

Intended, just need to document

Intended, just need to update docs

Intended, just update docs

Fixed in v1.3.1

Can't fix this as the app will detect add as the command word. Not much that we can do.

Leap day happens on 29th Feb, not 28th Feb...

You can also try providing more examples on how the regex should work. Probably will help the user understand better.

How did u manage to solve the error ah?

Ohh ok

Should AddCommand always return to the all person view? Should DeleteCommand still stick to the groups view?

https://github.com/AY2021S2-CS2103T-W14-1/tp/pull/221#issuecomment-814739957 Ok thanks for the reply

Remember to handle the case where the deleted person is the only person in the group. What should happen to the group then?

Remember to check that del-date command will still work as intended

Nope, its quite close to the submission date so I would prefer not to change all the names at one go. The interface of userPrefs will still work as per normal and I think we are all used to calling the internal structure that stores Person as addressBook.

UG portion is done from #216

Code Quality sounds more like a responsibility. You could put "Developer, VS Code Expert" for your role.

Should these @return and @param aliasName have descriptions?

There are similar cases in this and other files.

Missing method comment?

These look like they shouldn't be here.

Are these missing JavaDocs?

Is this missing JavaDocs?

Is there a link to this source? Also, if you understood and adapted it, consider using

//Solution below adapted from ...

Reference: https://nus-cs2103-ay2021s2.github.io/website/admin/appendixB-policies.html#giving-credit-for-reused-work

Saw this in a few other files.

Should there be a newline between these two methods?

Could you add descriptions to these tags or remove them?

What is object?

Please standardize the javadocs format in future to follow the style guide. Will approve first because it's non-breaking and we should merge soon.

Perhaps this could be instead shown as an arrow returning to the user

Consider using MODEL_COLOR instead of LOGIC_COLOR since this is part of the model component.

Should the return arrow be dashed and the activation bar disabled when returning?

Perhaps

can then be executed by entering the Alias instead of the full or partial command.

should instead be

can then be executed by entering the alias instead of the full or partial command.

because the user is not typing in Alias but rather the alias that they specified. It's a small semantic point.

Are these comments supposed to be here?

There may be a missing closing bracket here:

if () then ([all parameters are valid)

The tense seems a bit off here.

Maybe this

If the input begins with an existing command word, parses it as one of those pre-defined command.

should be

If the input begins with an existing command word, parse it as one of those pre-defined command.

(italics added). Similarly for the rest of the points.

Also consider placing this description above the activity diagram, with a transition to the diagram. E.g.

The following diagram illustrates this flow.

DIAGRAM GOES HERE

Consider labeling the arrow returning from UI to user with display commandResult instead of this:

I'm not sure but the new keyword may not be appropriate in a sequence diagram. Consider this example from the textbook:

Maybe change return result to return commandResult for consistency with the related return statements below.

Should this be an IssueList?

This activity diagram appears to have the condition within the branching diamond. However, this may not meet requirements for this module. Consider moving the branching conditions out of the diamond as guard conditions in square brackets.

Agreed. It may also be good to list out pros and cons for each possible implementation.

This looks like commented-out code. Was this intended to be here?

There may be a typo here. Did you mean something like this?

Checks that room 03-100 is not occupied by anyone.

There may be inconsistent tense here.

The problem is reversed if the parent-child roles were swapped.

Maybe this could be changed to either

The problem would be reversed if the parent-child roles were swapped.

The problem is reversed if the parent-child roles are swapped.

Consider adding a fullstop at the end.

It may be good to give a short description on what this example does.

Thank you for moving this to its own class. Could you update your PR to close #69?

Should there be a blank line between the description and the parameter list? I believe it's in the JavaDocs guide.

Saw this in other files too.

Is this class missing JavaDocs?

Perhaps put a @throws NullPointerException ... since you're using requireAllNonNull

Saw this in other files too.

Should there be an @param tag?

It might be good to document this method too, even though it's an overridden method because each command is different.

Should there be a blank line between description and parameters?

Perhaps the first letter of the parameter description and return description should be capitalized?

That is,

@param aliasName Name of the alias.

@return Whether the name matches the regex pattern.

Saw this in most other files.

Is this missing a @param tag?

Is the @param missing a description of the parameter?

Is this missing an @return tag?

Is this missing an @throws NullPointerException?

Should field be fields?

Should there be a blank line between description and parameters?

Is this missing a param tag?

Should there be a blank line between description and other tags?

Is this class missing JavaDocs?

Perhaps this method should have JavaDocs even though it's an overridden method?

Saw this in other files.

Is this missing a param tag?

Is this class missing JavaDocs?

Should there be a blank line between description and @throws?

Saw this in other files.

Perhaps the first letter of the @ tag description should be capitalized. That is,

@throws NullPointerException If the input is null.

Saw this in most other files.

Is the parameter aliasName missing a description?

Is this missing @param?

Is this missing an @throws NullPointerException?

Should field be fields?

Should this be a instead of an?

Oh, then maybe change it to The field must not be null.

Should there be a space between the bottom-most import and the start of the class header?

Is this missing JavaDocs?

Consider adding JavaDocs to this because it is the key part of a predicate.

Are these missing fullstops?

Is this missing a fullstop?

Maybe change wants to requests. Wants doesn't indicate that the user is performing an action on SunRez.

The use case above (UC-022) has the same thing.

Should this be an extension of step 2 instead of step 1?

Very minor nit here: Should this be "Deletes the findBob alias..."?

Maybe provide a justification for this user story? It could be asked "what's the benefit of deleting aliases? Just don't use the ones you need anymore."

Should this be Example?

Should this be Use case ends. also? It seems a bit weird that it branches from 3 then goes back to 3.

Do you want to specify that the room is unoccupied?

Maybe add a fullstop at the end?

Perhaps don't include delete as part of the read-only address book.

Hmm, could this instead make a copy of alias mappings? Otherwise undo may be more difficult to support.

Should it be "... are unique within SunRez"? (no "the"')

Hmm, should we state that we are targeting Singapore/NUS? Otherwise this may be a different point of contention.

Perhaps add a fullstop?

Is this missing a fullstop?

Hmm, if you link up this dealloc, then we might have to link up all other command references.

The dealloc link seems to not work for me.

Hmm, if you link up this dealloc, then we might have to link up all other command references.

Should this be a proper description?

Maybe change to "Must be one of the following strings ..."

Hmm, just in case, maybe make this "A keyword used in the various find commands."

Just in case someone points out that there is no find command.

There seems to be an extra [ here.

Does this include the space?

Hmm, what do you mean by "Tags will collate ALL tags..."?

Should this say "... may reject it based on..."?

Maybe something like "On the other hand, all tag parameters specified will be taken. For example, ..."

Is this missing a fullstop?

Maybe add a bit of text explaining what this diagram shows? When I was reading this section, it seemed to come out of nowhere.

On a more general note, if dealloc isn't a very different command (in terms of execution flow) from regular ones, this sequence diagram may not be strictly necessary.

Hmm maybe add a section header for alternatives considered. Check out the Command History section or Room section for ideas.

I like the descriptions of the alternatives you gave though.

What's this tag for?

Is this missing a fullstop, and should it start with a capital letter?

Saw this in Model.java and AddressBook.java too.

Is this missing a fullstop?

Is the spacing here supposed to be 8 spaces instead of 16?

Will creating a Resident with a room cause trouble with allocation and deallocation?

Hmm why is hashCode() being deleted?

If it is because it only accounts for residents, then it could be replaced with Objects.hash(...) as in UserPrefs:

Should this

stores the address book data

instead be this?

SunRez data

Is this missing a fullstop?

Should this

which stores a list of ReadOnlyAddressBooks which are the states after each command is executed

instead be this?

which stores a list of ReadOnlyAddressBook objects, each representing a state after a state-changing command is executed.

Missing fullstop?

Might this be better phrased as

track room issues and their status

Hmm,

search for issues

seems to be repeated.

How about

ensure issues have the latest and correct information

Is this user story still relevant?

see both available rooms and unassigned residents side by side

Maybe indicate that this test case continues from step 2.

Missing fullstop?

Hmm maybe specify the prerequisite of there being no existing resident called John Doe.

Consider adding another prerequisite of Jane Doe not already existing

Consider adding the other constraints that must be satisfied before a resident is deleted. E.g. the resident is not allocated to any room.

Wait, does rulist further filter down the existing list of displayed residents? If not, then maybe change "There is at least 1 resident displayed" to "At least 1 resident exists..."

All unallocated residents?

Maybe "Residents whose names have words fully matching..."

This could be misinterpreted as 1 allocated resident in any position. It might fail if the first resident listed is not allocated but the second is.

Hmm, this seems like it has too much detail about the implementation.

Suggestion: remove the stuff about index and list displayed. Keep it high level like UC-019.

Minor grammar nit:

This include both issues...

Suggestion:

This includes both issues...

Saw this in a few points below also.

Hmm what does history a d/ABCDEF mean here?

Maybe add a >br> on the previous line so that Expected: ... is always on its own line.

Saw this in several other places too.

Is this missing a fullstop?

Must not be empty

Are these missing fullstops?

Saw this in other entries below too.

May want to standardize to either

digit

digits

Should E.g be E.g.?

Saw this in other places. If you make the change, consider doing a search for e.g

Missing fullstop?

but there are only 10 residents

Maybe change this to

but there are only 6 residents

to better match the image that follows.

Good catch, thanks.

Hmm good point. An optional frame might suggest that a command being unsuccessful is the "happy path". My original intention was to convey the fact that unsuccessful commands will not be recorded in the command history, but I guess an activity diagram or a note in the sequence diagram might be more appropriate.

Thank you, I will consider this suggestion seriously for a future update.

Thanks, added.

Yup, there are above-upper-bound and below-lower-bound test cases.

Ah good point. Thanks.

Hi Colin, could you re-open this PR to the upstream master branch to follow the forking workflow?

As agreed in our team meeting, we will be splitting work by feature, not component.

Closed in #63

Closed because no longer relevant

We may want to break this up into at least 5 separate issues since each member is expected to update the DG. That way, each member can close the relevant issue when they are done with their part.

Further, I suggest we break up DG update issues by feature, rather than by team member because a DG update per feature seems like a more correctly-sized unit of work than a DG update per team member or one monolithic update consisting of everyone's updates.

I would like to discuss if the command history should also include failed commands. I think there is merit to mimic the same behaviour where the invalid command can be access via up and down arrow keys so that a Power User can edit the invalid command rather than retype it all.

If we do go down this path, I think a possible implementation is that each history entry will keep a field to keep the corresponding command used. Thus, if the field is null, it indicates an invalid command, otherwise it indicates a valid command.

Hmm, thanks for the suggestion. SunRez currently does not consume the user's input when a command is invalid, so a power user can already edit an invalid command easily.

Split into 5 separate issues that can be closed individually by each member.

Okay sure, thanks.

Will resolve this when our UI is finalized.

Could you merge master in and make sure the conflicts are resolved so that we don't have any unexpected surprises, and another pair of eyes can double-check it the merge to ensure we don't lose any info.

Done. Thanks for your comment.

Hmm, if that is the case, then I think narrowing the valid formats would be better. i.e. MM dd hh (enforce double digits always)

I agree. Do you want to update the timestamp pattern? E.g. to make month MM instead of M?

Broke into smaller issues.

Team decision: style it as in the former case.

Closed because individual team members will open their own issues if they need to.

Should we use the actual website links instead of the link to the markdown file?

Should there be a corresponding w-yuchen.png image uploaded as well?

Should there be 2 formats for the sort command as well?

Perhaps this should be updated too

Should this be left out because the use cases are supposed to show only what the user can see?

Similar to the previous comment

I guess this is down to the implementation already.

Will you want to

execute the edit command even if there are erroneous fields or
abort the whole command entirely and show an error?

The add command follows number 2 for now.

Good point raised, we can follow up on this discussion about which format we want with the other team members.

I think this may have been left out by mistake

Rmb to update this javadoc

I think this may be removed as it is handled above

All the EditPropertyCommand.EditPropertyDescriptor can be simplified to just EditPropertyDescriptor since EditPropertyDescriptor is an inner class of EditPropertyCommand

Perhaps this should be removed

Remember to update all the javadocs too

Maybe can do a import seedu.address.logic.commands.EditPropertyCommand.EditPropertyDescriptor; on top so that you can directly use EditPropertyDescriptor instead of the whole verbose type

Rmb to change this javadoc

Rmb to update this variable name

Rmb to update this javadoc

Should the message_usage be from FindPropertyCommand instead?

Rmb to update this javadoc

Should this description should include the appointments also?

Perhaps this part should be under the switch clause instead

Should this two be getTypicalAppointmentBook() instead?

Should this two be getTypicalPropertytBook() instead?

Should this two be getTypicalAppointmentBook() instead?

Should this two be getTypicalPropertyBook() instead?

Ok thanks

I think it is?

Should this two be getTypicalAppointmentBook() instead?

Should this be getFilteredAppointmentList() instead?

Don't change this because the time is supposed to be displayed as "9:00AM" and not "9:00am"

Rmb to update this to getTypicalPropertyBook()

Can simplify to just SortAppointmentDescriptor instead of SortAppointmentCommand.SortAppointmentDescriptor

Same goes for other instances in this whole file

I think this should be sorted in %1$ending order instead right? Because its ascending and descending.

Will this throw an error if user did not pass in either asc or desc in the command? Is the asc/desc supposed to be optional instead?

Think there is a typo here. This whole file is using EditPersonDescriptor instead of SortAppointmentDescriptor.

But I think for SortAppointmentTest, the testing should be of a different format too right?

Oops right!! My bad.

Ohh, ok sure

Remember to update the UG in this case

Ok, do rmb to update it in future

Rmb to update this javadoc

Any reason for this change?

I think it will be neater to create an empty constructor in Client class.

There will be an extra ; in the toString of Property when both the client information and tags are printed

E.g. Client Asking Price: $800,00;; Tags: [4 bedrooms]

Rmb to update this javadoc

Is there a reason for using .withName(VALID_NAME_BURGHLEY_DRIVE)?

Just a suggestion: Would you like to consider using the ArgumentTokenizer class here?

Perhaps this can be changed to:

"Parameters: [KEYWORD]... [pl/UPPER_PRICE_LIMIT] [pm/LOWER_PRICE_LIMIT]"

instead and put the note on inclusive in the description? So that it aligns with our command format of replacing the uppercase characters in the command format with user input.

Rmb to update this to property book

I think it may be better to standardize your prefixes by adding a space behind "proceed" and "cancel" as as well

Have you considered the use of forward slashes in these new prefixes? Such as new/, proceed/ and cancel/

What may be some of the reasons you choose not to use them?

Rmb to remove this extra line

Maybe this description can be more descriptive?

Rmb to update this javadoc

Is there a reason for this change? Have you tested with resizing the app? Because I am not sure if this will affect when the user resize the app (e.g. maximize it)

Would it be better if you leave all these changes to the default one? Because I think it is the conventional way to express as top, right, bottom, left.

Similarly for this, I think there is no reason to change their positions?

Good that you make it consistent with the others

Is there supposed to be a use for this? I can't find any place that uses this matcher object

Maybe you will like to include an example usage as well

Will you like to move this to the UpdateCommand parent class instead so that it is not duplicated in UpdateProceedCommand class?

If you are moving the MESSAGE_NULL_STATUS to UpdateCommand class, then perhaps this should be moved as well for consistency

Same as the comment in UpdateCancelCommand

It seems weird to me that next() for Completion returns a Completion?

Ohh, I see

Would it be better if the .next() method is never called for Completion? But I do understand that it has to implement the method in this scenario. So I guess its fine.

But perhaps one other suggestion is to show the user that it is already completed or something if user pass in a command to update a completed property to the next stage?

Yeapp!!

Didn't realize that the update command is called as such update 1 proceed/, without anything behind the prefixes. So they are not really prefixes in this case, so maybe the forward slashes are not intuitive for the user and should be removed. Sorry!!

An alternative suggestion may be to change the command format to update INDEX s/STATUS?

E.g. update 1 s/NEW, update 1 s/proceed, update 1 s/cancel

In this case, you can even make use of the ArgumentTokenizer and ArgumentMultiMap classes to parse the inputs.

Will this be better?

Maybe change Undoes to Undos?

Undid?

Undos?

Correct me if I am wrong but do you have to set the previousAppointmentLists of previousAppointmentBook as well? So that the user can call undo two times in a row?

Same as the comment for AppointmentBook

Can this method be shifted to PocketEstateParser instead? So that the regex and parsing are not duplicated.

Let me know if it is not possible because it will affect the implementation or if there are any other reasons

Actually, the main question is just whether the user can call undo two times in a row now?

Ohh,that's good! Then we can merge this.

I think we shouldn't add this kind of setting files to the team repo. Can you leave this file out or put it in the .gitignore?

I don't think we should change this file too

I think we should be consistent with the add property command and use [t/TYPE] to indicate that the filter is for property type

Do you mean accepted here?

Can reuse the PREFIX_TYPE defined earlier in the file instead of defining a duplicate one

Is there a reason for defining a separate method to get properties with clients? Will it be better to just include JURONG in the getTypicalProperties method?

What does julLogger stand for? Will it be better to use a more descriptive name?

I think we should be consistent and use t/PROPERTY_TYPE here

Need to remove appointments here

This should be appointments instead

I think it will be better if the ... are after the square brackets.

E.g. find property [KEYWORD] [OPTION]...

Is the diagram changed or updated? If not, I think we shouldn't change the .puml file too

Should it be EditAppointmentDescriptor instead?

Just wondering if the \n should be taken out because the user can never enter a \n in our app right? Hitting the enter button will result in executing the command alr. 🤔

Do use the constructor with both property book and appointment book as the other constructors should be removed asap

Can you change this file back to the original version or leave this file out?

What is this commented out testcase for?

Similarly for this

Perhaps use PropertyBuilder here?

I am fine with this but perhaps use static variables for this? Something like INVALID_COMMAND_ADD?

Food for thought: how about finding client and the other extra stuff (finding by postalcode, etc) yuchen is adding? Or do we only prompt appointment and property because they are more important?

Ohh i meant the "add", "find", "clear", etc

So that they are not magic strings

Just wondering if you separate out this 3 formats of update in the command summary, then should you separate them in the Command section above too? Its better to be consistent so if you want to separate out to 3 formats, then both sides should be separated. If not, both sides should be 1 format only.

Actually will it be better if you have only 1 format, update INDEX u/OPTION, then you specify what the options are? Similar to how find is structured?

Not really sure whats the best way to present this...

Should you also add a bit more information on what each of the status represents, and calling proceed on one will lead to which one?

Maybe state what the amount means also?

Would prefer a nested table to explain what option, sales agreement and completion mean here. But ignore me if you don't think its better

There will be error parsing the html tags here. Try following what i did for the find property command below if you can. If not I will fix it after this is merged ba

omg im so sorry i meant like a nested list like that

...

cuz a table would be kind of out of place right?

Should this be UserPrefs instead?

just a small nitpick, but personally would prefer the options to be grouped in this way:

[KEYWORD]... [pl/UPPER_PRICE_LIMIT] [pm/LOWER_PRICE_LIMIT] [t/TYPE] [p/POSTAL_CODE] [a/ADDRESS] [r/REMARKS] [tags/TAGS_SEPARATED_BY_COMMA] to make it consistent with the rest of the commands

I agree with david that you should probably try to use ArgumentTokenizer here. This function has to be modularized one way or another because it is way too long and not reader-friendly now

Should this be matches the remark given instead?

Perhaps this can be clearer by saying ... contains all of the tags given?

Side note: should this be changed to contains any of the tags given instead? Since the user might want to use a few tags to search for properties with any of them.

I dont think its a good idea to duplicate the code from FindPropertyCommand#parse to here again. Given that this is a test class, is it possible to manually create the Predicate/PredicateList in each of the test itself instead?

Sorry, this way instead because address should be before postalcode:

[KEYWORD]... [pl/UPPER_PRICE_LIMIT] [pm/LOWER_PRICE_LIMIT] [t/PROPERTY_TYPE] [a/ADDRESS] [p/POSTAL_CODE] [r/REMARKS] [tags/TAGS_SEPARATED_BY_COMMA] to make it consistent with the rest of the commands

Will adding n/ for name be a solution? Since we are adding prefixes for the rest.

Do you need to add the square brackets here too?

Just a suggestion: I will suggest to format the square brackets like this so that it is much neater

Also, remember to add the tags parameter too

withAppointment takes in an actual Appointment object. So if an example is given, it will be quite verbose.

E.g. AppointmentBook ab = new AppointmentBookBuilder().withAppointment(new Appointment(new Name("Meet Alex"), new Remark("remark"), new Date(LocalDate.parse("2021-01-01")), new Time(LocalTime.parse("20:00:00"))).build();

So I don't think it is necessary to put. Let me know if yall think we should include it.

Ohh right good point. Shall change it. Thanks.

Thanks, merged and updated this branch

ok!

ohh ok!

Will update this

@dvdweien to update this section

@dvdweien to update this section too

The format is supposed to be t/hdb for example

@w-yuchen to update this section

ohh, thanks for catching this

Shall update this

I think we should probably separate source code and test code

Same as above

Oops, forgot to remove

will remove them

The new keyword is explaining the new in u/new AMOUNT. If it is still unclear, then maybe @dvdweien should fix it in his next PR.

@w-yuchen to fix this. I didn't touch any of their explanations, just fixed the ordering.

Ohh, I left it as date because it is checking if it is an actual date. Should I change to deadline?

ok shall update this

Update target user profile and value proposition.

Add glossary.

Add user stories.

should I close this pull request?

No, this is for the tutorial only.

Do remember to update the command summary for these commands at the bottom of the user guide page as well

Only property types "hdb", "condo" and "landed" and all forms of their capitalization are allowed for the PropertyType attribute of a property

I think that we originally discussed and decided that the asking price should be an optional "client asking price", so I had put it under client info. We can discuss more about this in the next meeting to see if we want to change it to be under property directly.

Do you mean like this? Is this better?

i think can lose the underline, maybe the bold isn't needed oso. I was just confused why every date was red

Then wont it be the same as the original alr? The main idea was to place some emphasis on the dates so that the user can see his upcoming deadlines/appointments more clearly

@candyhy what do you think of this 🤔

Updated image:

Storage interface should extend PropertyBookStorage, AppointmentBookStorage and UserPrefsStorage too

This shouldn't be execute(undo) right
I think should enclose the parameter in quotes cuz its supposed to be a string
should be dotted line for returning
This is a constructor call, so the label shouldn't be 600000 I think. Either leave it blank or change it to a call to create a new Option object
should be dotted line for returning
should be dotted line for returning
missing returning dotted line (if everywhere else has a returning dotted line, then u should probably include one here too)

Your diagram:

My diagram:

For this, I do agree that the 3 child classes should have a composition relationship with Offer, and I will update my diagram. But do you think there should be a dependency arrow from Status to Offer as well?

I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status

Ohh, because I thought Status has a method returning an Offer object. Hmm, not really sure whether to include this dependency arrow...

I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status

Ohh, because I thought Status has a method returning an Offer object. Hmm, not really sure whether to include this dependency arrow...

Oh yeah! I forgot about that, that method isn't currently being used now should i remove it? If it shouldn't be removed then i will add the dependency arrow

Ohh, its not being used? Then ya please remove and I will update my diagram. Thanks!

Just a quick question, do the photos have a transparent background?

No, but because our UG has a white background, it shouldn't matter?

Agreed. Full name for everyone would be great.

Agreed

@Eriksen2411 Yes 😃

In that case would it be

In charge of: Deliverables and deadlines

Role: Deliverables and deadlines

Role: In charge of Deliverables and Deadlines

I think there should be a space between // and Set.

I think there should be a space between // and Maximise.

Nice touch.

Add space below.

Yup, I'll add an issue!

Nice

colab_icon_32 would be easier to differentiate. 32 being an example size.

Perhaps all colour constants can have a prefix. COLOUR_PRIMARY_LIGHT and COLOUR_ACCENT.

COLOUR_CELL would be better. "Cell" is unclear.

What's the reason why it is NaN?

Nice!

Any reason for this specific resolution? Perhaps a generic 1280x720 or 1920x1080 would be consistent among different computers.

line space between if statement and previous line

line space

indentation. && should be aligned to ||.

Do add the types in the array list as well. It's failing the checks.

"new" has been duplicated twice.

Here

A list of Persons -> Tasks instead.

This one can use requireNonNull(), but no big deal.

I love how your comments are so detailed btw! 😃

Should it be target.isSameProject(edited) && contains(editedProject) without the ! in front of target.isSameProject(edited)?

Nothing implemented here

Should there be a requireNonNull(project) here?

Should there be a requireNonNull(key) here?

Need to implement. Why return null?

Should the predicate being imported be PROJECTS instead?

Here too.

Personally I feel that if we have to reference something from the Command class, then it might be better to put this message within the Command class rather than Messages. What do you think?

I like this change, but maybe wanna add the requireNonNull(projectToEdit); before this line.

Not a big deal but I think having the comma makes sense.

Why not have 2 constructors. The one with 3 parameters shall require non null for all 3 fields. So that when it is used externally, it is used correctly. The one with 2 parameters shall require non null for 2 fields.

This will then need to be updated.

Lets standardise the way this message_usage String is formatted in the future 😃

@samuelfangjw Referring to standardising it over all the command classes. Not too important for now. I wanted to neaten it for the other command classes.

Was referring to this part, that refers to the COMMAND_WORD. Not a big deal for now since command word will most likely be unchanged.

@samuelfangjw Added a new comment to the correct line for this.

Sure!

Add extra line here

Extra line here.

Add extra line here.

Just a minor suggestion. I think convertedProjectName would be clearer here. Since there are many variables starting with "project" and "projectName"

Is there a reason why you do this once here, and then assertDoesNotThrow for the same thing below?

Looks repeated as the one below.

Looks repeated as the one here.

Can the Set(i,deadline) method be used instead. This way the list would not get reordered unnecessarily.

Do you wanna make this change to EventList too?

Do you wanna simplify "deadline.getIsDone() ? "✔" : """ with a method in Deadline? Or even from toString?

Do you wanna simplify "todo.getIsDone() ? "✔" : """ with a method in Todo? Or even from toString?

I think it would be better if DP can be labelled better. Like DP_COLOR_NO_TRANSPARENCY etc

Same as above

Got it, then DP_1_ELEVATION would be good

Sounds good to me!

I think it is better to have it in the previous form, so that the ParseException e's message can be shown to the user as well.

Although the new design does simplify things.

The method header name here is wrong. For other methods, your method header names also seem irrelevant to the what the test actually does.

Wrong method header.

Header names here are fine

Oh okay. In that case, nice catch 😃

Good idea!

So for now there is not mechanism to tick the todo off in via the GUI right? It'll just update the GUI accordingly?

Was id left out intentionally?

Is the ID here intentionally left out?

id here too

Reading this, it looks like ID should be checked too. Hmm

here too.

Maybe the UiCommand can be specified to be ViewProjectUiCommand since that is the current context?

and here.

Looks better man!

Is it overridden instead of overwritten?

Looks better man!

Got it man, thanks

Perhaps can add requireNonNull for dateOfEvent

requireNonNull

Looks like id isn't being used at all.

I remember the implementation here was changed, or is this correct?

Perhaps can requireNonNull here for Event just to be thorough

Wanna change the string text for this and deadlines to a constant declared at the top for easy access?

In reference to the previous PR haha

I see. That does make sense and simplifies a lot of things!

"events list" can be changed to "EventList"

issues & ececutes change to "executes"

It checks Event provided is valid or not -> It checks if Event provided is valid or not

"an exception will be thrown, Ui will" change to "an exception will be thrown and Ui will"

It check whether -> It checks whether

and Event provided is duplicated or not -> and if Event provided is duplicated.

I kind of don't understand what is being said here.

works -> work

works -> works.

remove the word "issues".

-> The user executes the command

not work with the immutable -> not work with an immutable

Maybe this line can change INVALID_REPEATABLE_DATE -> INVALID_EVENT_DATE.

can't merge with deadline one because of the different prefix.

Nice explanation man

Does it need to catch DateConversionException too, given that it is thrown in checkDateIsNotNegative? Or is DateConversionException a subclass of DateTimeParseException?

I checked and it doesn't appear to be a subclass of DateTimeParseException

Hmm, because they throw with different messages, perhaps can leave it as it is?

The syntax changed to "addEto PROJECT_INDEX d/DESCRIPTION on/DATE at/TIME w/Y"

This one I feel it would be better to have 2 constructors. 1 that has only 1 parameter for ColabFolder and sets CommandResult to null be default. And another constructor that has 2 parameters such that both parameters would have requireNonNull.

Not a very big deal because the Null in parameter is only used in ColabFolderHistory

CommandResult.

Should just be name here. Its showing the entire package currently

Was day here intentionally left as 4 chars? as it has been shortened to 3 chars above.

Is it supposed to be > "Repeatable" > here

Is this method still used?

If so, it could reused in line 49.

👍

Ok. Not a big deal since we only have 1 type of repeatable

In line 46 and 48 you changed "#4features" to "#4-features". Might want to do it here too!

Good idea on shifting the explanation here!

In Ms Aileens pdf, she was asking if description is only for deadline, event or todo. Thats why I added that line.

We changed the explanation for Description in the app to "Description can take any values, and it should not be blank"

Good idea shifting it here!

Hmm, any reason why the words in the square bracket is [Contacts] and not [Today]

Maybe this sentence, "To switch between the two, use the overview and todo commands respectively." can put in the "Info or Tip" box?

Maybe this portion can be clearer on how Contacts and Groupmates are still separate entities.

Here too. "Maybe this portion can be clearer on how Contacts and Groupmates are still separate entities."

Haha I checked again, need to change

Tip is fine!

Ooh. What about putting it as a tip?

Adding it to FAQ can be a bonus too

I agree with you that the first sentence already makes it clear.

Oh nice catch. thanks @Eriksen2411 !

np!

Good catch. Added it. Thanks!

Yup! I took from address field because that allows for long and varied sentences. I think the one from project name allows only for 2 words

Thanks!

Thank you. I will merge the changes and request review again 😃

Will resolve this at a later date. Placed in issues. 😃

Good idea!

Thanks!

Nice thanks!

Nice. fixed!

thanks!

It is optimized for use via a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, CoLAB can get your project management tasks done faster than traditional GUI apps.

We can add with a clean and inviting UI. to this paragraph or remove it all together.

Good idea. I'll shift it around.

LGTM

Dimensions have been updated.

@samuelfangjw thanks. I have updated the title and the description.

Pull Request was closed due to deletion of branch. No merging was done.

@samuelfangjw Looks great! Please add the changes you have added to features to the table of contents.

Nice work! LGTM!

LGTM.

Nice work. LGTM!

@samuelfangjw the images that show the features in detail. It can be seen in the pages further below in the user guide.

@samuelfangjw Good catch 😂

@samuelfangjw I think you've found the one 😂

Are you able bring back the v1.1 milestone?

@samuelfangjw Looking forward to it hahaha!

@samuelfangjw Nice thanks. I'll get on it soon!

@samuelfangjw Good idea!

Closing as Tutorial PR irrelevant to project.

Thanks! @samuelfangjw

Nice. LGTM man!

Might need to check the things brought up in the comments. Accidentally approved and left out this comment.

All the models, storage and tests have been updated. PR is ready for review. Thanks!

Tests aren't sufficient, but we'll ignore that for now so that the rest can proceed. I'll add more tests over time.

Done up all the necessary classes for AddTodoCommand and related classes. Some changes and additional checks were added/made to AddEventCommand and related classes. I have yet to do up tests for AddTodoCommand. I will do AddDeadLineCommand after this, and then will add the tests for Todo and Deadline at the same time. Thanks!

Done up all the necessary changes for AddDeadlineCommand and related classes. Some changes were made to AddTodoCommand and AddEventCommand. I will work on deleteE/T/D and then do the tests for all. Thanks!

Ready for review. Tests will be added at a later date after deleteEvent & deleteDeadline are done.

Ready for review. Will add tests soon after merge.

Ready for review.

Done up the tests for AddTodoCommand and it's related tests.

Ready for review! Thanks!

Made relevant changes and fixed some issues. Fixed a minor issue with a test for DeleteContactFromCommandTest. Ready for review. Thanks!

Ready for review! Thanks!

Ready for review, thanks!

Need to decide what the equals method determines as equals.

Update UG to say tags are optional

Update the message that is displayed to the user.

Need to find the optimal minimum display size.

Update the UG

Update the UG with correct quotation marks.

update the UG with correct quotation marks.

Does not occur even with 24000 1's.

Update UG with quotation marks.

Update the UG, remove the extra line about TODO_INDEX param

This is as expected.

Update UG to fix quotation mark.

Unable to replicate this issue. Tested on both Windows & macOS and am able to add as many events as required.

Events are sorted based on time. Not their names. Hence it shifts to the correct position.

Update message to

"Date should either be a valid date and in one of the following formats:"

Perhaps can edit the message to

"Time should either be a valid time and be in one of the following formats:"

Update the UG to say that 0000 to 2400 in our application. Hence only 0000 would be considered valid, not 2400.

Display bug

shouldn't this be resumes from step 2, like in UC1b below?

what defines a conflict? overlapping datetime + same name? or overlapping datetime + same doctor? or both? or are there other cases where a conflict will arise?

In the same vein, how specific should we be for Use Cases?

Think all the 1a's and 1b's can be summarised somehow since its being repeated in all use cases, but I'm not sure how to handle it. does *a work? or use inclusion with a bigger use case? -


1. user enters a command

2. system reads the command and executes the command 

1a. invalid command

1b. invalid subcommand

might want to consider changing to something like this?


steps 1a1 to 1a2 are repeated until command entered is correct/free from errors.

same thing for the other loop-style/invalid input by user use cases

1c, 2a looks to be repeated as well in edit and find (1c), and edit and delete (2a)

@AY2021S2-CS2103-W17-2/developers

should it extend Exception or RuntimeException? any particular reason for making this an unchecked exception?

same for NegativeOrZeroDurationException, AppointmentConflictException

is this an intended mention of addressbook.json here?

maybe consider a naming more similar to UniquePersonList.java, and same ordering of methods as UniquePersonList.java

not sure whether this is allowed under coding convention for spacing

this doesn't look like it fits the regular format of implementing Parser>DeleteAppointmentCommand>

think u may have missed a param INDEX?

command should be something like edit-appt 1 pt/2, which means:

edit first appointment (right side of GUI),

change the patient in the appointment to the second patient in the patient list (bottom left side of GUI)

check out editPatientCommand regarding this.

i don't think this is true, if this were true then each patient would only be able to have 1 appointment at any point in time.

why allMatch? this doesn't sound like it would work.

with allMatch(), wouldnt it mean all appointments in the appointment schedule have to be the same appointment for this to return true?

this sounds like it should be anyMatch instead, in which case the original contains() should be used

i think leaving as List>Appointment> may fit the current coding convention better, All previous commands like DeletePatientCommand, EditPatientCommand uses List>Person> as well

agree,

rationale is that for a scheduling conflict to happen, either patient has overlapping timeslot, or doctor has overlapping timeslot,

think this method wouldn't work, and hasConflict should be used instead

same issue here with allMatch(), should use hasConflict instead

i think the issue is that the current editContains is using allMatch(), which i don't think is correct?

from my other comment on this, all appointments in the schedule have to return true for equals() for allMatch to return true, which doesn't seem to be the right idea

this code would not work if patientIndex didn't exist. Should handle it like lines 104-106: ie. something like


Person patient = editAppointmentDescriptor.getPatientIndex().isPresent()

        ? displayedPatientRecords.get(editAppointmentDescriptor.patientIndex.getZeroBased())

        : appointmentToEdit.getPatient();

this method name sounds like you're converting a Set>String>, instead of converting to a Set>String>. Would recommend to change to convertToStringSet or something along those lines

is there a need to 8 spaces then 8 spaces again? im not too sure about the coding convention

what's the rationale behind trimming? code looks like it should work without trimming right?

programming to an interface is better coding practice if you don't need to use any ArrayList specific methods: ie.

List>String> xxx = new ArrayList>>(); instead of ArrayList>String> on the LHS

combine?

String keywords = argMultimap.getValue(prefix).get();

this may be just me but i feel like doing the object creation on another line feels v messy...

i'd rather do Collections.addAll(tagKeywords, listKeywords(argMultimap, PREFIX_XX));, but its up to u!!

think this portion should refer to both appointment schedule and patient records, not just patient records

is there a need to separate the predicates PREDICATE_SHOW_ALL_PERSONS into Patient and Doctor for better clarity? since in this command we are supposedly only showing all patients, not all persons

same question with the separation into doctor/patient for this

believe this may change to just Predicate>Patient> if we don't use the Predicate>Person> in Model.java (change will populate downwards)

abstract class?

propose changing the name of this class as well since it only affects data for patients.

on a side note, i think we will need to create a sample appointment data util to populate sample data for appointments as well. will add this in the issue tracker.

may be able to make this abstract as well

Accidental use of Patient here.

can probably remove the initialisation and stick with only the declaration if abstract class is used

should change AddressBookStorage here to AddressBookStorage>Patient> to avoid future confusion with AddressBookStorage>Doctor> when it is added into this method

to change naming of the json file itself, same for the other test jsons,

unless intention was to leave it as PersonAddressBook.json because should be clear enough that it is meant for patients because it is in a JsonPatientRecordsStorageTest folder. (but i still think renaming would be clearer)

to update comment

small issue that doesn't affect anything but the param name is still addressBookFilePath

consider refactoring method names?

I don't think so? I think this should be a class that tests for all versions of addressbook? because this would correspond to the main class AddressBook.java, which is for both doctors and patients right

yup i think so

does this imply that force delete must be before patient index? ie. command must be given as delete-patient --force 1

if it does, is it intended?

if yes, then i may be better to specify maybe in the force delete message

i believe this portion of the code doesn't have to be in a try?

i think its cleaner to move it out of the try if it doesn't have to be inside.

u can then handle the isForceDelete cleaner as well (ie maybe in the else)

actually, i think a cleaner way may be to check the index first, if index is wrong then throw a parse exception for index related stuf (ie DeletePatientCommand.MESSAGE_USAGE, only after index is confirmed to be good, then parse for forceDelete.

this is because currently the emphasis of the parse exception message usage being returned isn't very clear,

ie if user keys command delete-patient --force notAnIndex, this method returns a ParseException with FORCE_DELETE_MESSAGE_USAGE. Emphasis of the exception should have been on the Index being wrong instead,

should edit the method name to indicate that this method is for empty appointmentschedule, non empty patient records

same here, method name is wrong, should be execute_nonEmptyAppointmentScheduleNonEmptyPatientRecords_failure or something along those lines

yeah that does sound abit ugly.

i'd prefer just the 1 line (or multiple lines) which causes the exception to be within the try, so it makes it clearer for readers too

would be good if FORCE_DELETE_REQUIRED is renamed to FORCE_DELETE_PATIENT_REQUIRED as well

refactoring error here

why wasn't this previously in ah, is it because this would be used for the statusbarfooter (which currently only shows appt schedule storage filepath)?

shouldn't we just call this PATIENT INDEX instead of PATIENT (positive integer)?

minor, but should be have 😆

should be find-doctor, probably means FindPatientCommand may be wrong as well.

note to @onnwards to add hasConflictingUuid checks

note to modify according to clear-patient bug

note to modify according to delete-patient bug

note to @onnwards to modify according to edit-patient bug

need to update javadocs

update javadocs, probably means javadocs is wrong for EditPatientCommand as well

AddDoctorCommand object instead. probably means that AddPatientCommandParser is wrong as well, and potentially AddAppointmentCommandParser

same for all mentions of AddCommand in this file

same for all the EditCommands here as well

this file is not supposed to be here and should be deleted

javadocs here, and below as well

needs javadocs update in this file, for patientrecords as well

why??

why no override?

note to @onnwards for UUID

why though? is there a rationale behind it @Jacob-Pang

looks like its because we can get more abstraction with an abstract class?

just noticed, weird indentation for this line for javadocs

javadocs for this and probably also JsonPatientRecordsStorage.java

seems to be inconsistent with the overall order of userprefs, patient, doctor, appointment

here too

will there be any side effects of renaming this? any other places in the code that we need to change? not very familiar with the Json storage conventions

again quite minor, but inconsistent order?

note to @onnwards to Predicates to resolve merge conflict properly

jdocs, same problem for AddPatientCommandIntegrationTest.java

note: to modify test classes here to test correctly after delete-patient/delete-doctor bugfix has been implemented

jdocs

jdoc

should not be a remove and an add, and line 34 looks like it should fail: comparing AddressBook>Patient> with AddressBook>Doctor>

refactoring error

recommend to change to a more doctor sounding name for consistency's sake

jdocs for patient

jdocs for patient to change to doctor

why not the straight up import?

some refactoring issues in this file, need to rewrite these methods since we now have 3 different things to get from

an update to the TypicalAppObject's objects will probably require an update to the corresponding json (typicalDoctorRecords.json, typicalAppointmentSchedule.json) as well.

@Jacob-Pang any ideas on why this isn't failing tests?

shouldn't the typing of addressbook fail the equals? because we are comparing >Patient> with >Doctor> right

this extra = misaligns it 😢

javadocs has mention of patient

actually, i feel like we should throw an exception if forceDelete not equals "--force" as well? feels like we shouldn't just let a user pass with an input such as delete-patient aisjdhabakahbakshdbankdjashb 1

if we do this we can then make the inner if conditional not nested, and more flat

same for DeleteDoctorCommandParser

ah i missed that out, yeah then it works perfectly

if timeInput == null then null is returned, which will lead to a NullPointerException in the method calling this one

can try to use Matcher instead, check out sebastian's PR on how he uses Matcher.compile for forceDelete and patientIndex. exceptions can then be handled that way.

with this, it probably means you won't get an index out of bounds exception, or nullpointer exception with the input, makes stuff cleaner

a NullPointerException shouldn't be thrown, because the caller method don't handle it. should throw ParseException instead. also NullPointerExceptions technically shouldn't be thrown/caught either since they're runtime exceptions, not checked exceptions.

it would be better if this was more explicit to facilitate/improve resuability by someone who doesn't know regex, maybe something like DD_SLASH_MM_SLASH_YY, etc

i don't think there's a need to have a new class for this? i think it is fine to have these constants be in TimeslotParser.java

@Jacob-Pang for input

at most, i would probably make it an enum with a field, ie


enum TimeslotRegex {

    DATE_SLASH_SHORT ("([0-9]{2})/([0-9]{2})/([0-9]{2})"),

    DATE_SLASH_LONG ("([0-9]{2})/([0-9]{2})/([0-9]{4})"),

    DATE_DASH_SHORT ("([0-9]{2})-([0-9]{2})-([0-9]{2})"),

    DATE_DASH_LONG ("([0-9]{2})-([0-9]{2})-([0-9]{4})");



    private final String regex;



    private TimeslotRegex(String regex) {

        this.regex = regex;

    }



    public String getRegex() {

        return regex;

    }

}

you could then access the first regex by: TimeslotRegex.DATE_SLASH_SHORT.getRegex()

you could even take this a step further by having an abstract method in the enum, eg. maybe formatterExpression, with each indiviudal enum having their own implementation of formatterExpression (returning a different formatter string) so you could shorten the if/elseif testing in parseFormat

have you tried javafx.scene.input.KeyCombination

i think calling this addInput would be clearer

would be cleaner if this was this.inputCommandList = new ArrayList>>();

then line 10 can then be private static List>String> inputCommandList

pointer should reset back to the end of the list right? instead of just ++

this feels like it could be cleaner.


public static String retrieveInput(boolean upPressed) {

    if (upPressed) {

        incrementPointer();

    } else {

        decrementPointer();

    }

    return getCurrentInput();

}

public static void incrementCurrentPointer() {

    if (currentPointer < inputCommandList.size() -1) {

        currentPointer++;

    }

}

public static void decrementCurrentPointer() {

    if (currentPointer > 0) {

        currentPointer--;

    }

}

public getCurrentInput() {

    return inputCommandList.get(currentPointer);

}

it doesn't matter whether you abstract it into a function or not like above, but the conditionals can be simplified

u can just omit the else if nothing is going to be written

what does it even mean when the most recent item will be on the top of the list?? this is not correct.

the last added patient and doctor will appear on the bottom of their respective lists. the appointment with the earlist timeslot (arranged by start time i believe) will appear on the top of the appointment schedule.

I think you need to take a look at our current website UG.

The table of contents is populated automatically with kramer, there is no need to replace the dynamic TOC with a static one.

i assume this combines the code blocks into 1 while still bolding add-patient

(ie. avoiding this gap thing)

mildly related to this, but how do we specify that the --force parameter has to be before the index but after the delete/clear? (ie cannot be in any order)

this should be all 3 clears right? should we write somewhere in the UG that when we refer to like the front word w/o the back words, we refer to all 3 commands? ie. if we refer to clear without the -xxxx, we are referring to all 3 commands? or should we just be specific (and mildly repetitive) and just mention all 3?

related to the earlier comment: is there a need to specify explicitly that the --force must be before INDEX?

regarding this, im not sure if we should repeat this, since a possible UG bug is unnecessary repetitions under neatness/correctness:

same for this regarding repetitions, but perhaps more acceptable here since its different from edit-patient regarding the parameters

Would it be better if we say parameters with prefixes e.g. n/ can be in any order to avoid confusion?

this sounds good

i think this is a bug, didn't notice in the PR when doctor was changed from string to Doctor

can follow the patientList way to do this

what does this mean?

might want to be more specific here? and list 2 or 3 appointments that this will match, ie something like

Apppointment with Patient name: alex and doctor name: Jekyll, or Apppointment with Patient name: edward hyde and doctor name: Jekyll.

to make the formatting more consistent with lines 357/358

this notation feels abit weird, im not sure if its correct

missing a space between these 2 lines?

actually, should check whether the patientNameSplitMapper is still valid considering all the new changes to AppointmentContainsKeywordPredicate, or should we revert back to patientList.stream().anyMatch(isMatchDoctor)

isn't this already mentioned under Appointment Schedule at line 588? I don't think we're using the term Appointment Records at all

don't think so, logic is we don't want any patient commands to affect appointment schedule, so we make a new typicalAppointmentSchedule here

still missing some sections to UG, like the summary table, so will not close issue yet.

fixes #6

duplicate PR with #26

you can perform the CI checks locally by using .\gradlew build

is this PR still relevant? @icytornado

to solve:

recommend 2 prs:

raise exception if appt list has the patient being deleted,

- recommend to add `--force` (or whatever) parameter, force delete feature: 

- if `--force` is specified then cascade the deletion

3 ways:

>s>1. change patient class to have mutable fields (and potentially appointment class)>/s>

>s>2. couple the patient class to appointment class such that edit-patient will also perform edit-appt>/s>

ID (or UUID)

create doctor that extends from person and relevant methods

DG Components:

Architecture: @Jacob-Pang

UI component: @onnwards

Logic component: @pngsebastian

Model component: @icytornado

Storage component: @kwmiw

Proposed features: remove undo/redo, data archiving @onnwards

change codecov badge in DevOps Guide

Requirements:

Use case/user stories/Instructions for manual testing: each person handles own features, follow UG numbering from UC03 onwards (UC02 is help)

check on NFR, product scope, glossary: @AY2021S2-CS2103-W17-2/developers

invalid because the error is intended, no to/ or dur/ was specified so command format is invalid.

invalid because the word alphanumeric implies no spaces.

invalid because this is intended, internally there was an edit being done, ie the object instance is different before and after the edit. it was just a case of the edit details being the same.

on a side note, the functionality for this edit is the same in AB3 as well.

invalid because a@b is a valid email (ie. without TLD)

invalid because this is intended. since add-doctor takes in only the name parameter, everything after n/ will be treated as part of the name, ie. name would include what was typed: DR Bob p/987672. this would then prompt the error message names should only contain alphanumeric characters and spaces

invalid because this is intended, since the levenshtein algorithm is used to determine what the closest word is to the invalid command. exit happens to be the closest word to delete or list, with it requiring a minimum of 4 edits, while delete --> delete-appt and list --> list-appt requires a minimum of 5 edits.

invalid, because integer in this case refers to the datatype integer, which is from (-2^31 - 1) to (2^31 - 1'). 10000000000000 is not considered to be an integer, and therefore the right message was shown.

invalid. UG states:

Either and only one, TIMESLOT_END or TIMESLOT_DURATION, must be provided.

invalid, feature suggestion

duplicate of #90

closed to avoid clutter

duplicate of #90, closed to avoid clutter

duplicate of #91, closed to avoid clutter

UG bug

same UG bug, duplicate of #102, closed to avoid clutter

duplicate of #112, closed to avoid clutter

duplicate of #116, closed to avoid clutter

duplicate of #93, closed to avoid clutter

duplicate of #126, closed to avoid clutter

invalid, similar to #129

duplicate of #102, closed to avoid clutter

UG bug, duplicate of #102, closed to avoid clutter

duplicate of #99, closed to avoid clutter

duplicate of #126, closed to avoid clutter

UG bug, duplicate of #102, closed to avoid clutter

duplicate of #125, closed to avoid clutter

duplicate of #99, closed to avoid clutter

also fixes #112

to prevent possible FeatureFlaw bugs

It seems like this exception is relating to session, but i'm not sure if it should be named as IllegalArgumentException, since there's the default java exception IllegalArgumentException. Might be confusing in future. Perhaps we can further discuss this? @JonahhGohh

🎉

minor bug: find_session KEYWORD instead of find_student KEYWORD

Perhaps we could consider the test case where it starts with 6/8/9, but has >8 digits in total, instead of this current one (or we could create a new one). Not sure how important it will be, but feels good to have!

I believe should be k/120 instead of l/120, and t/18:00 instead of t/1800!

Perhaps we could include an assertion for invalid days in month, for example 31 Apr is invalid since April only has 30 days, something similar to leap year check! (does the exception catch this actually?)

This should evaluate to delete_session John Doe 1 but should be delete_session n/John Doe i/1

HAHA this one abit ocd but perhaps make all the points not end with a dot for uniformity, otherwise lgtm!

think you forgot to remove the comment right here

Are these commented codes rough work? Might be better to remove.

that's right!

I'm not sure if the bracket filtered feels abit out of place. Maybe something like Listing students' emails based on current list might be better? Hahaha, maybe someone else can phrase it better!

Nice catch on the missing delete_student!

I think the header can be "Fees"?

Then under action "Student fee by month", what do you think?

I'm assuming the method is named parseStudyLevel to be uniform with the rest. However, for study level, it isn't exactly 'parsing', since it's String -> String. As compared to say email, where it's String -> Email.

Perhaps without changing method name, we could change the description to "Sanitize/Clean studyLevel input"? or something along that line. Don't think it's a big issue tbh, but what do y'all think?

Same goes for relationship as well!

I think this might violate the 'explain WHAT and WHY, not HOW' @ textbook.

Same comment as above (regarding WHAT and WHY not HOW).

Honestly, i don't have a clear idea of how to phrase as well 🤣

One way is to remove comments, since it's pretty self-explanatory (as per textbook), maybe someone else has a better suggestion? @AY2021S2-CS2103T-T11-1/developers

Minor change: Student instead of student

Do you want to mention about how the filteredStudentList is updated as well?

I think 'UI shows updated student list' comes before 'Logic saves the address book to the storage', according to the code:


commandResult = command.execute(model);

  try {

      storage.saveAddressBook(model.getAddressBook());

  } catch (IOException ioe) {

      throw new CommandException(FILE_OPS_ERROR_MESSAGE + ioe, ioe);

  }

You can double check!

How about a test case to consider when all/some parameters are null?

new Tuition(null, null, null, null)

Perhaps {@code Session}?

I think @yungweezy had Java 11 in code block in one of his PR, guess we gotta decide when we merge eventually?

Should we change 'user' to 'tutor' instead? Might be more "relatable"

Suggestion to rephrase: The Home tab gives tutors a quick overview of important matters. This includes their upcoming tuition lessons, as well as tuition fees receivable for the past 3 months.

ok!

Should help be placed below together with clear and exit instead?

This is not related to your UG, but practicality wise, isn't it funny to have us accept same name but different cases? HAHA

Not too sure if the 'Overlapping session will return an error' is necessary. But the 'takes care of overlapping session' also sounds very ambiguous (like we have some algo or something).

Perhaps phrase it in a way like 'TutorBuddy takes care of overlapping session for you by giving a gentle prompt, so you don't have to worry about it'

I think don't need to quote 'sample' haha

probably could rename it to boolean hasOccuredAtDate, since the name seems to clash with the method name.

same for this as well, suggest to rename to hasOccuredAtTime

Thanks for figuring this out! neat!!

I'm assuming it's (firstInSpan.numOfDayTo(lastInSpan) / interval.getValue()) + 1. might be better to put brackets!

recommend to rename to tuition1 and tuition2!

Perhaps would be better if dd MMM YYYY, so it'll be 29 Mar 2021. more reader friendly!

Seems like the sessionType is hard-coded for now. Perhaps create a variable in SessionCard.java for sessionType then hard code from there instead? To reduce confusion later on!

So the time is a tab itself 🤣

This is not urgent, but perhaps we could shift the date/time to the extreme right? Would look nicer!

Perhaps don't make it a tab! But yes can make an issue, not urgent!

Might be better to flip points 2 and 3, so that it looks more 'uniform'

Good to have a space between examples and bracket

So, Examples (if applicable)

Yeah same, think it's cuz it's within a >div>. Might need to replace clear with >code>clear>/code> (not too sure if it works)

Same soln as above, worth a try. @JonahhGohh

Riding onto this thread for another reason: should it be indices instead of indexes? HAHA

I think can remove 'filtered'?

"Returns an unmodifiable view of full list of students"

hey @nowknowing, was the function outputting incorrect results prior to this?

ah, you're referring to the case where it'll break the condition immediately if it doesn't meet !startAfter?

This is more of aesthetics, but would be great if we can do sth like:

sessionType.setStyle("-fx-background-color: >color>");

and give different colors for R & I.

Then, add padding for sessionType label in the fxml.

Just some aesthetic improvements, not necessary if too rush!

Would suggest to abstract:


populateTuitionList(studentList, tuitionList);

sortByDate(tuitionList);

populateUpcomingTuitionListView(tuitionList);

into another function. seems like you're repeating these 3 lines both outside and inside the listener.

might want to consider using tuitionList.sorted(...) instead. Might be cleaner, just like how I did it in calendar. but this is fine as well!

If this function checks for whether it's within today, tomorrow and the following day, do we need to pass in the parameters today and dayAfterTomorrow? cuz probably can use LocalDateTime.now() and LocalDateTime.now().plusDays(2).

Unless this is generalised to a "check within data range" kinda function.

Unimportant feature: maybe can add padding as mentioned above.

right... i see where you're coming from. i doubt there's an issue with code quality, just that i personally feel that it's abit odd to be named isWithinThreeDaysRange and we have to indicate today+2days (dayAfterTomorrow) date as well haha

if you're ok with it then feel free to merge!

on second thought: MUST the dayAfterTomorrow be today+2days? will it break if another dev inputs a random date? maybe assertion will be good here then.

Probably can run a validation to check if endPeriod is after startPeriod? or maybe an assert since this won't be used publicly.

Not related to code, but is GetPrev3MonthFeeCommand, the number 3, within the naming convention? If it's fine then ok! Just afraid they point it out.

I would think Converts to the local date time format from supplied {@code Month} and {@code Year} might be better.

I would think if this is used as a generalized "convert from Month & Year to LocalDate" function, then the naming could be something like 'convert to local datetime of start of month'?

maybe getMonthFeeByPeriod? getCurrMonthFee seems to imply the current month, which is today's month till next month, while this function takes it start period and endperiod. just for clarity!

maybe execute_correctMonthlyFee_success() would be better.

I'm not sure if we should hardcode this, maybe run some codes to calculate Alice's fees for feb 2021 then concatenate it with the expectedResult?

I'm just afraid someone amends the TypicalStudent's sessions and this will screw up. What do you think?

nice change!

seems to be quite a chunky function. im unable to think of any better implementation right now, but making it less 'chunky' can be done for 1.4 right?

The words in bracket seems quite distracting to the actual command. I almost thought it required n/ i/ only, perhaps move the explanation down?

Same point as above.

Not too sure if this is mentioned before, but is time really needed? since the recurring sessions should have the same time for all.

(doesn't affect functionality, but looking at a user experience pov)

Not sure if should change to include sessions as well? so 'lists all students and sessions'

Would it make sense to check for negative monthly fee here, and as well as in your MonthlyFee.java?

maybe a different object check as well?

assertFalse(year2021, year2020)

Actually now that I think about this again, maybe we should build a new temporary student from scratch, add it to the list of students temporarily, then feed it through GetMonthlyFeeCommand and compare the results with a 'hardcoded' result. Not too sure how it'll improve efficiency though, but just a suggestion! shouldn't be an issue if we continue with this current implementation.

was thinking we can build a new student so we can hardcode the results HAHA since ALICE might be susceptible to edits in future. but it's ok, let's keep it this way!!

Missing a gap between [n/NAME] and [p/STUDENT_PHONE_NUMBER]
The sentence for edit_student seem to truncate on my side, i think there's a way to wrap text (?), refer to screenshot below!

Think this concerns the UG as well.

In the individual section, add_rec_session is:

add_rec_session n/STUDENT_NAME d/START_DATE e/END_DATE b/INTERVAL t/TIME k/DURATION s/SUBJECT f/FEE

In the summary, it's the one you provided. probably gotta decide on one?

recurring* typo haha

sorry, referring to line 123 only.

Some english: when the user first opens** the application

Not sure if we should rename voluntary session to free instead? While reading it, thought it was a new kind of session HAHA

Also, not sure if we should justify why we chose 0 - $10,000, feels like we're doing it just not to get penalised HAHA maybe specifying the range is enough. either way works!

Actually on second thought after reading your codes below: maybe can rephrase it to, accepts FEE within an acceptable range of values between 0 to 9999.99 (both inclusive)

Probably we can do a 9999.999 check as well for 2dp?

thanks for helping!

does this and the remaining hashcode test cases somehow increase coverage? hahaha

Actually not sure if we should use 'calculating', maybe 'display'?

sorry ah, what's this referring to? 'save time by creating multiple sessions', are you referring to recurring?

i think maybe: 'so that I can update cancelled tuition session'? haha

maybe the so that I can part can change to:

have an overview of my hectic schedules at a glance

should we be specific and mention session inputs instead?

same comment as above, maybe mention specifically 'session inputs'?

actually do we need to create an extension for students don't exist?

Also have to verify whether session exist maybe?

Same comment as above.

i think should be Today button instead.

The chunk (from line 114 to 138) is commented out using HTML >!-- --> tags! So should be irrelevant for now.

Yup, I agree. something we can keep in consideration beyond v1.2.

Oh and as for the comment out, the chunk (from line 114 to 138) is commented out using HTML >!-- --> tags! So should be irrelevant for now.

Commenting out in the middle of list items creates a bit of a weird gap in between. I'll take your suggestion and comment it out at the bottom, so we can restore it easier next time!

I think can imagine the listener as something that's running in the "background" and always monitoring the ObservableList>Student>, so whenever there's any changes to the list of students, the code within the block will be invoked. As for the change.next(), if there are multiple changes made, they're represented as a 'separate change' (list of changes), so change.next() loops through it (might not be 100% correct in this part).

The ListView>Session> is actually bound to the ObservableList>Session> sessionList, so whenever there's a change in the sessionList, which is shown in this block of code you commented, the ListView will update as well.

(might not be 100% correct)

Amended in next commit!

I think that's how it's supposed to be, just like in JsonAdaptedStudent

Will be done in 1.3!

No sir, it should be students.deleteSession(student, sessionIndex);

Amended in next commit!

It's activity and sequence diagram! hahaha

Oh yes, i also found the indentation weird as well. Will make the change, thanks!!

Whoops was copied wholesale 😂 will make the change, thanks!

Ok thanks!!

ok got it! will make the changes

actually used cmpSessionDate to shorten code 😆

will make the change, for both cmpSessionDate and a!

got it!

looks good to me as well, nice catch, will proceed to merge.

Made changes mentioned by @yungweezy @enhao25, merged! 🎉

@samleewy I think the comments change and parse method name change, I'll create a new issue so that we can discuss. For now, maybe you can approve this first to fix the trim date bug?

sure!

LGTM!

What do you having this condition as "valid command input format" instead? I feel like "command exist" is not very clear 😅

@JonahhGohh ok will change, thanks!

Not a code review, but perhaps can link it to your Issue #84 to close.

Tom was added first with:

start time: 12:00

duration: 1hour

Samuel Lee was added second with:

start time: 11:00

duration: 2hours

Should conflict, but didn't. KIV.

Thanks for the hard work on the Calendar feature. The UI looks amazing and the feature seems to be working well. Can't seem to find any bugs.

One thing to consider is that find_student also filters the calendar view. We might need to mention this in our UG also.

OH RIGHT. the find_student will filter the calendar view as well.... Doesn't feel ideal 😂 Will see if I'm able to do it separate from it.

Thanks for the hard work on the Calendar feature. The UI looks amazing and the feature seems to be working well. Can't seem to find any bugs.

One thing to consider is that find_student also filters the calendar view. We might need to mention this in our UG also.

OH RIGHT. the find_student will filter the calendar view as well.... Doesn't feel ideal 😂 Will see if I'm able to do it separate from it.

I added a PR for this #148. I saw that u did something as well ah. But then I just created a method for it so that everyone can use it ah.

@enhao25

ok! will change to your method after the PR goes thru. thanks

Github doesn't allow me to add comment on unchanged lines 😦 but i noticed that you passed in logic into your CalendarView constructor.

Since you are only using logic to get the full student list, how about using the ObservableList>Student> parameter in the constructor and using logic.getAddressBook().getStudentList() in MainWindow.

This also standardizes with the other code in the fillInnerParts() method.

@JonahhGohh yep! I made this change in the latest commit together with @enhao25's getFullStudentList(). If everything's ok then i'll merge!

LGTM! Tried testing the calendar feature on my computer and works nicely! Codebase looks good also.

I think this issue was brought out recently in the group chat regarding overlapping sessions. But I think it exist as an issue already and is not part of calendar.

Hence, no issue and approved!

thanks!

@enhao25 am guessing this relates to the duration enforcement check that we were referring to.

An alternative might be to remove in UG for the "fast typing" criteria? Not sure how that'll affect grading

Even though the reporter didn't particularly point out what was not understood, I agree with this.

Perhaps shouldn't use term such as "spawn". And gotta find a way to make them visualise it better. Perhaps through images?

I'm not sure if it's allowed in 1.4?

Yes it was a "feature" for emails. I think we should just remove it for safety reasons. will do it!

Wanna do a quick test to increase coverage?

done! the report's not showing here, coverage seems to have went up after introducing test case.

If possible, please show the appropriate screenshot? thanks! @Winniehyx

The team believes the description is clear enough.

resolves #230

resolves #231

resolves #232

@yungweezy are there plans to address this issue? if not you can close it.

Issue's screenshot does not correspond to the issue title. closed.

Is this done @enhao25? If yes we can close!

Actually just thinking what would happen if we put the time as 23:592. This is because when trying out the iP, I noticed that one of those that I am reviewing failed this test, so you could include 1 more test with this value to ensure that adding extra values to the timing will not cause any unexpected behavior ah.

Yeap! I think that the test case should fail with these values.

Hmmmm honestly I tot that changing the values for amy bee here will will affect places like the CommandTestUtil.java as well and fails the test case. But seems like it passes the test case. Seems like they are not linked then. But just in case next time there is some error for this, we might need to check back ah.

Should we comment out find_session here instead of deleting them?

Ohya actually is find_session part of v1.2? Cos now that I think about it, its quite weird for find_session to include the Index. Like it wouldn't make sense for me to look through the whole list of session and try to get the individual index and then run find_session again, cos the information we give from the session list and find_session would be exactly the same. It would make more sense for it to be just find_session s/STUDENT_NAME. But if this is not under v1.2, I think we should comment this out first before we discuss again?

As per the above, this seems to follow the find_session s/STUDENT_NAME instead ah, should we comment this out first?

Ah ok! Didn't see that the comment header start at line 114.

Great!

Hi, just want to check as the previous line ": Deletes the student identified by the index number used in the displayed student list.\n" already has an \n, does having an additional \nParameters here cause anything weird on the UI? Might be better to just keep one.

Hi, just checking if this is something extra that you did that isn't really related to the UI. Can I check if the purpose of this code is to check if the equals method works as expected?

Hmmm using student instead of s, might be better in this case

Hmmm is these commented out withsession intended?

Looks good! Just wondering if there could be comments here similar to ModelManagerTest.java equals method, to better allow the others reading this code to understand the test cases here better.

Hi, just wondering, since the AddressBookParser is in `` in the next line, we could possibility AddressBookParser here for consistency as well.

Haha based on what jonah said, actually why you changed also ah. I tot its part of Logic, isit because you did the delete_student command previously?

Hi, perhaps you could copy the diagram over to a folder with your name instead and restore the original file ah.

Hmmm I think line 154 to 155 and line 157 to 158 are duplicates ah.

O.o damnnn u did both. Haha ok sorry. Let me go approve ah

Actually I think this part is abit confusing for me, aliceInTuition when calling new Tuition() has a sessionIndex of 2, however, we assertNotEquals that getSessionIndex() is 2, isit because of the difference between the zero index and one index?

Same comment as the getSessionIndex() above.

I think there is additional space on to LogicManager, but small problem ah.

Actually you could include ../style.puml instead, so you don't have to make a new copy of the style.puml in your folder ah.

Only one comment, I was thinking the indentation for the addSession(withSession previously) was abit weird and should have the same lvl of indentation with withStudyLevel instead. Do you think it would be better if we did that?

Actually outside of scope, but this comment here seems abit unnecessary with ////, I think we could just use // instead, so that it won't be flagged as a "bug" during PE dry run.

Hmmmm actually using TAG in this case might not be intuitive as we do not have a tag parameter in our entire application. If we are to include this here, maybe a different parameter and including the edit_student in the UG would then be more useful.

Using KEYWORDS during find_student as the example might be better than using tags here.

Looks good, however, do remember to add this command over to the TOC and the command summary at the end of the page for consistency.

Hi, just wondering, is "to the TutorBuddy" quite werid, I tink its copied over from single session also. I think changing over to "to TutorBuddy" removing "the" would be better. What do you think?

Hmmm maybe using "class" here might not be suitable as a class is usually associated with a group 1-many tuition. Just putting as "Or efficient way to calculate your incomes?" might be better.

Hi shion! I think you have updated the class at some other places. I think updating it here under class income will be good as well. (E.g. Lesson incomes instead class incomes)

Yo actually what is this for ah?

Hi, understand the the testing is still a work in progress, but I think it could be better if we didn't use System.out.println() when we are merging to master. Using assertions might be better.

LGTM. But was thinking if we can be more explicit that the interval is in terms of the number of days.

Hi was just wondering what could does >p> mean. Isit a typo?

Hi, just checking, for this implementation, we run super(session) to create a standalone session out, but then it doesn't seem to keep a reference to the created session anymore. Can I check if that is the intended effect?

Hmmmm already, actually didn't use super often so not sure how it would work out. We could keep this in mind and when the rest of us work on features that uses recurring session, see if we are able to perform all the actions we want, even w/o keeping a reference to it ba.

Actually not sure if other groups will nitpick this, but we could give s1 and s2 a more meaningful name such as sessionDate1 and sessionDate2. Will be longer, but at least we prevent other group from nitpicking these small bugs ah.

Hi, maybe we could add a //TODO: tag here, so that we would remember to come back here in the near future and work on this.

Also I am just wondering if there could be a way (Probably through a command) to add a recurring session into to application, so that the reviewers can checkout and run the PR to perform manual testing as well, to better understand your implementation. Not sure if you want to work on that first before we reveal and approve this to ensure that the implementation passes some light testing. If not it might be hard for me and jonah to test if our feature works if we couldn't add recurring session inside to the addressbook to test.

LGTM, I think "40" is missing a space, to be "40 "

Maybe you would want to pull upstream first and merge inside, I believe that choon wei added a functionally that previously adding session that clashes. (E.g. If a session that starts on 2020-01-01 12.00 that last for 120mins, we can't create another session that is between 2020-01-01 12.00 to 2020-01-01 13.59) Although, with recurring session, this is much harder to achieve, because we need to take into consideration from the start to end date, if adding this rec_session will clash with future individual sessions as well. Not sure if you want to push the 2nd part into a separate issue as it seems like quite a big implementation.

Ohya one of the possible issue is that I think the storage has no way of identifying now whether a session is a recurring session or a standalone session. I tried creating the recurring session, close the app and open it again, and the recurring session becomes a standalone session now. Might need to take the storage into consideration, either in this iteration, or as a separate issue.

Hi thanks for the hard work. One of the bugs I found was that if I were to put a value where the end date and start date doesn't match, instead of showing an error message, an exception occurs. I think for this, it would be better to show some form of error message to the user instead.

Hi, so sorry, but I am not sure where the error is.

However, if you run the command:

add_rec_session n/Alex Yeoh d/2020-03-03 t/12:00 k/90 s/Math f/40 b/7 e/2020-03-17

then close the application, open the application again.

Run the command:

delete_session n/Alex Yeoh i/>number of the recurring session>

You will notice that the output will be "Deleted Session: Date: 2020-03-03; Time: 12:00; Duration: 90; Subject: Math; Fee: 40.0" instead of "Deleted Recurring Session: Date: 2020-03-03; Time: 12:00; Duration: 90; Subject: Math; Fee: 40.0; Interval: 7; Last Date: 2020-03-17".

Hence, the although the storage is storing the interval and last session value inside the json file, I think when the system reads from the storage, it creates a session instead of a recurring session. Might need to look into that.

Just some minor consistency issue, this could end with a . as per your other javadoc sentences. Using populates instead of populate here might be better according to the java coding standard.

Hi, was just thinking that maybe displaying date and then time could be better in this case, just a suggestion ah as it feels more intuitive for me, although is debatable.

Hi, was just thinking that maybe capitalizing the first letter for each of the sub section would be better. "the result.." to change to "The result". This is the same for 1 and 2 as well.

Nice! Was thinking if it might be good to use >div style="page-break-after: always;">>/div> as stated in https://se-education.org/guides/tutorials/savingPdf.html for us to ensure that the introduction section always starts at a new page. Might be good to include this at before the start of a key section (E.g. Before Intro, Commands and Command Summary)

Abit OCD, but I think most of the examples don't end with ".", might be better to remove it as well.

Just thinking that edit_student before delete_student might be a better flow. Since a user can add a student, edit that student and then proceed to remove it after.

Just wondering if writing the key features in point form would be better to catch the attention of the user.

Actually abit OCD, but as per the java coding standard for javaDocs, maybe adding a full stop to all of the javaDoc comments might be more consistent.

Hi, was just wondering is using sessionDateComparator instead of cmpSessionDate might be more meaningful.

Replacing "a" for the "a -> a.." to something more meaningful will be helpful for the developers as well.

Maybe can use "Must" instead of "must" for consistency.

Hi, was thinking that maybe a variable name such as consistentDate1 might be more meaningful here.

Hi, maybe using something like "getIntervalTest" might make it more explicate that its a method for testing.

Hi, I think you have missed out on writing the description for the return method here.

One of my PR changes the method from .addSession to .addSessions instead, we might get some conflict because of that.

Similar to the review above.

Hi, actually I am abit confused between this isConsistent method compared to the isValidEnd method based on the description. One mention that it returns true if it makes a valid lastSessionDate while the other returns true if it is consistent with the lastSessionDate. The 2 descriptions seems very similar in my opinion.

Hi maybe this can be session instead of s. Just worried that using s instead would violate the java coding standard.

Maybe it would be better to include this difference in the description as well. Because I think if u didn't tell me this, I would not have known from the description alone.

Nice! Seems to work well for recurring sessions with multiple dates. However, I tried to use delete_rec_session on a recurring session with only 1 date and it returns an exception, maybe you want to look into that.

Maybe we want to include what we did "By spliting up the remaining sessions into 2 separate sessions.". I have a feeling that this delete_rec_session command will be quite confusing for the users / developers. Will need to explain it carefully and update the UG accordingly.

Hmmmm for me this description is quite confusing also. Maybe something like "Removes a single {@code Session} with {@code sessionDate} from the recurring session and splits up the remaining sessions into 2 separate recurring sessions. We identify the recurring sessions to perform this action using {@code sessionIndex} and {@code name}." would be better?

Maybe including the description here about splitting up the remaining sessions into 2 (All the sessions that happens before the deleted session are in one recurring session, all sessions after the deleted session are created in another recurring session) might be better?

Actually not related to the documentation, but why do we need time here again ah? Cos once we have the student name and the session index, we would have known the time already right? There can only be 1 time right.

Looks good! Do remember to include this in the TOC and the command summary as well!

Ok sure! Got it!

Yeap! Looks better! Thanks thanks!

Possible long slap here, the other group might state that this is a code quality violation, so do take note.

Same here, possible long SLAP.

Image might need to be updated to the one with the monthly fees UI done up

I think the message for the help command can be changed to "Displays a help window of the different commands available on TutorBuddy and a link to the user guide."

Hi, was just wondering if the ArchitectureSequenceDiagram has been changed to match any command, if yes, do put it into a folder with ur name and rename the image src accordingly! Thanks!

Actually I think we do not have to edit the tutorial codes ah. It probably shows up here cos of refactoring.

Yeah, I think as per the tutorial yst, having a class diagram of a single class might not add value in this case.

Hi! I would suggest adding this to your folder. Maybe deleting the old DeleteSequenceDiagram.png might be good also, if its still in the file.

Hi, I was thinking if we could add in some example, "...number of education levels (E.g. Sec 2 / Secondary 2 / Computing / CS1101S)"

Hmmmm is "Rationale" supposed to be "Highlight"?

Maybe removing the "be" from "should be fall under" would be better.

Haha, not sure if it is possible to abstract further. But then as attached below, when grading our project, having reasonable SLAP methods and not having deeply nested method is part of the consideration in grading. So it might be better to try to split up the code and attempt to reduce the nesting here also.

https://nus-cs2103-ay2021s2.github.io/website/admin/tp-grading.html#2-project-grading-implementation-15-marks

Actually the method name of "AddSessions" and the description that we "Set" the session doesn't really match. Maybe changing the description to "Adds any number of sessions to the current student's session list." or something might be better.

Maybe we want to include the rationale of why we do it this way, (To avoid the 2038 problem which can found here)

Hi, actually not sure where this bug occurs, but when I was testing I noticed there is a weird bug now. As seen below, I added a 1970 session to TutorBuddy, but then in sessions, it displays the date is 1971 instead. Its the same for other values where it +1 to the session. Storage still shows the correct value, so not sure if the +1 only comes in in the UI. Seems to happen in master also, u might want to give it a try.

Ok ah I will change the values in the file back to the original code, I have no idea why this file is in our directory also.

Updated.

Waaaa nice catch man! Updated it accordingly already!

Ok good catch! Have updated the test to include these 3 cases.

Haha alright! Updated

Haha LMAO, but I think its fine tou, it allows the reader to understand that its filtered, and can be the full list also.

Alright, updated to Listing students' emails based on current list instead and also updated the TOC

Haha yeah I tot of before, but then I think at most there will only be 2 commands, one to get monthly fee for a particular month, one to get past 3 months fee. So not sure if it should be a section by itself. Although I think doesn't hurt to change ba. I will make the changes first then.

Actually not sure if its ambiguous, I think if we really want to be specific "Student fee for a particular month and year" would be more accurate. Will update to this version first.

Nice catch!

Took the comment and added the information

Nice catch! Updated as required

Hmmm ok, seems like ur use the filteredStudentList in your explanation also, so I included them as well ah.

Ah ok! Seems logically, updated it already.

Ok good suggestion, the only common place for both code base is on model. Hence, I have abstracted out the get fees code over to model. Do have a look, the output should still be the same. Thank you!

Ahhh right! I have changed it to 3_month_fees instead.

Alright! Change from that to "Shows the totalled fees per month, for this month + previous 2 months" instead.

Yeap should be correct. I copied over from https://github.com/nus-cs2103-AY2021S2/tp/blob/master/docs/UserGuide.md. On github, it shows as per the picture as well, however when its in the webpage, it should looks as what we expected.

Updated.

Hmmmm I followed https://nus-cs2103-ay2021s2.github.io/tp/UserGuide.html ah. I think the reason why they did that is that it is more sequential ah. A person who starts must know how to "get help" before even starting to learn about the commands. After trying out all the commands, he / she can then clear the application and then "start" actually using their own data for the application. Thereafter they can exit the application. This seems to be quite a logic flow. What do you think?

Haha yeah ah. But I think if we want to change, we need to update it at alot of places though. So I put it here as a "feature", so people can't dispute with us, saying its a bug ah.

Updated

Yeap sounds better! Have updated.

Anw if you want, we could create an issue, then if we have time then we can work on that ah. If not then we will just go along with this?

Haha right! Thanks thanks! Have updated in the latest commit!

Haha right! Will remove it! Thanks thanks!

Ah right! It will make the code looks nicer ah. Have done so in the latest commit! Thanks!

Alright make sense! I just put an assertion here ah

Actually this command has been removed, so it should be fine ah.

Updated to be getFirstDayOfMonth().

Changed to Gets the first day of the {@code Month} and {@code Year} in local date time format. instead due to the change in name.

Yeap! Sounds better!

Haha ok! This code is moved to feeUtil, but then hearing ur advice, I have put an assertion that numOfSession >= 0 (Sometimes can be 0 depending on the period given). In this way, if we want to debug, we can just activate assertion, but then it wouldn't return an exception during normal activity.

Haha ok sure! Updated.

Hmmm ok sure! I have made the amendments, feels like I am doing a calculation outside, and then a calculation inside the command and comparing them. But ok ah, don't think it will ever fail now.

Haha nice catch! Changed that in the latest commit liao!

O.o hmmmm, we sort of built the ALICE student from scratch also in typical students tou. I am not sure if creating another new student at this point for calculation would have any difference from using existing students for calculation. In regards to hardcoding the answer to check, I am not sure but then I don't really see hardcoded values in test case also, so not sure if its the correct way to do it ah. Thats y eventually I changed to this that seems to follow what the other test cases in AB3 do ah.

Yeap sure! Added.

O.o right! But its an illegal exception error instead, did that in the latest commit.

O.o actually I made some updates, and just check during the parser method before the session is even created ah. See if this version is ok.

Nice! Updated in the latest commit!

Updated to "TutorBuddy only accepts FEE within an acceptable range of values between 0 and 999999.99 (both inclusive) as we do not expect a single session to cost more than $999,999.99 or more." as per suggestion.

Good suggestion! Have added the check and it is false as expected.

Ahhhh yes! Good suggestion! Did that in the latest commit! Will push it up after it has completed the check!

Right, this sounds better! Have updated it in the latest commit.

Ah right, now that I read again, retrieves doesn't sound right in this case, I have changed to "displays" in the latest commit

Ah right! Nice catch. O.o hmmm in this case, we might not need to include the all the different commands for students inside the DG then. I tink the rest of the sections is good, just that the implementation sections could be restructured, but not sure how we should do it also tou. Should I remove those other student's command section first?

Haha yeah, I originally did this, then I saw that our previous version had the 2 and 3 separated, so I went ahead with this. Since u agreed that combining is good also, I tink I will do that ah.

Ok! But I tink it is still good to specific that its student and session data, hence I change it to 3. TutorBuddy is populated with sample students and sessions data

Hmmm also can, I guess people can't say that having more information is a 'bug' ah, so I just put ah, seems safer.

Ok updated in the latest commit!

Yeap! Sounds good! Have updated in the latest commit.

Ok! Updated in the latest commit.

Nice catch! I have updated it in the latest commit.

O.o I tink that aileen has mention that calculates in this case is better for the user to understand what the feature is doing. I will just keep it this way if you are ok with this.

Hmmmm I think cos we are using a general step that is same across the rest of the use cases also, cos you will see this in other use cases also ah. So we probably don't need to specific what type of inputs, since it should be general enough to be use at other places also ah.

Same reply as above.

I tink previously step 2 is split into 2, it checks for student info first and then checks for valid input. But then we feel that the "checking" part can be consolidated into 1 single step and just classify it generically as "detects an error", cos when students don't exist, its technically an error as well. Hence this is what we have in the end. Or do you feel that we should still spilt them up again?

Same as above ah, cos if we want to add the check if the student / session exist, then we need to do for all liao ah

Same comment as above.

Yeap sorry man! The "save time by creating multiple sessions" is supposed to be for recurring session, have updated it accordingly.

Ok! Sounds better! I have updated it in the latest commit! Thanks!

Ok nice catch! Have updated it accordingly.

LGTM.

The Student Commands need to be updated after the addition of the Tuition class #40

Ok great! Should we merge this first? Since we are doing this in phrases, I think it makes sense that we merged inside after a functionality is done, compared to merging it when tuition + session + student is done together. I believe choon wei would have to reference this changes to work on the tuition class as well. Delaying the merging could mean that there will be alot of conflicts when we ultimately try to combine everything together.

LGTM!

So, this will only be an issue if the user is using a 32-bit system?

Yes I did a rough search and it seems that it is possible that 32-bit system running java might have the 2038 error. Hence I think setting an upper limit to >=2037 would be a good compromise.

Tested it and works well!

I like how you compared the dateTime with the compareTo() method, clean af haha.

Regarding the 3 month command, I was thinking of using it for the Home fee section. So not too sure if we need a command for it.

Haha I agree ah! For the 3 month command thingy, I was also thinking that we might not need the command. So haven't added it to the UG yet. Probably can keep the command for testing purposes, and remove it after the UI that uses the 3 month function is done.

Ok! I think it shouldn't affect much, so just leaving it as fees should be fine.

closes #81

Done from https://github.com/AY2021S2-CS2103T-T11-1/tp/pull/118

Thanks for the hard work on the Calendar feature. The UI looks amazing and the feature seems to be working well. Can't seem to find any bugs.

One thing to consider is that find_student also filters the calendar view. We might need to mention this in our UG also.

OH RIGHT. the find_student will filter the calendar view as well.... Doesn't feel ideal 😂 Will see if I'm able to do it separate from it.

I added a PR for this #148. I saw that u did something as well ah. But then I just created a method for it so that everyone can use it ah.

LGTM! utterly minute also debatable so ignore if dont think so, but getFee might benefit from being inclusive on both inputs. looks like its change > to >=. oh but also the caller

Ok ah. The reason why I didn't make it inclusive end is because it is easier to get the months fee. For example to get Mar fee, I can put 1 Mar start, and then plus 1 month to 1 Mar to get 1 Apr as the end.

If it is inclusive, I will have to do it such that the end period is the end of the month, but then some ends at 28, 29, 30 or 31. So its much harder to do that. So for the purpose of monthly fee, I would tink this way is better.

Thanks for adding this!

A slight issue is that I was thinking of using this populated data to be UI images shown in the UG.

I think it would be better to show some Individual sessions here instead of all recurring session?

Haha ok! Actually david li has 1 individual session. I have updated one of Bernice's recurring session to session instead. See if its ok now.

Haha right! Should change that

Yeap! Have solved it already ah! But should probably add the constrait to the UG also ah

First part is the issue of the tester that they never read the UG properly. Second part on having a constraint on the fee is valid.

Resolves in #176. Only had to add in the constraint to UG.

Stated in notes about command format about what would happen when there are multiple value of the same parameter.

Not sure if this will be solved after limiting the duration value.

Possible limitation of the function?

As per the recommendation, we might want to set this as a known limitation and put it in the UG.

We should update the UG to better represent that delete_session also works for recurring session, just that it deletes it entirely.

Resolved.

It can still be added in if the tutor wants to see it as a past record / use the fee feature.

Examples commands are there for new user to try.

They are not the same person. One is John Doe and the other person is John, they can be brothers, and are not the same person.

Good suggestion to change to the tab after entering the respective commands. Not sure if this is possible.

User did not see the UG carefully where we explained about reminders.

Don't really know what the person is saying ,but then I tink the description do seems ambiguous. Cos our reminder is for the today's session + next 2 / 3 days session as well, but then I think this description doesn't really describes that.

This unknown command is due to add_sessionn/John Doe, by combining them together without any space, the application won't be able to determine what the command is. Hence, the unknown command result is expected.

As per testing on my computer, it does show that the student index is invalid.

And also, the image doesn't represent the issue at all. Unable to replicate what the user means.

Possibility of having command to switch tab, if that is not considered a feature. If not nothing else we can do at this point.

It is "made for freelance tutor" and "optimize for fast typing user". Description seems clear enough already.

We do not want to restrict the flexible for study level. So the users can add something like "University" or "CS1101S" if they are TA's in school. Since TA are also technically tutors.

Actually I tried also, and somehow the reminders are not working currently.

Seems like having a "better" error message now might help us to resolve some bugs.

As our program is for any tutors, e.g. primary school / secondary school / music teacher / university TA, it is not feasible for us to limit the scope of study level. However, we could include this constraint in the UG.

Same suggestion as before, to navigate to the tab when keying in these commands.

Actually idk if this is a good "feature" that we should just include in the UG instead ah. Did @samleewy made it this way when you did the email command thingy? If so, might help to add in to the UG ah.

@nowknowing Your suggestion for adding suggestion day (If feasible) might be helpful here.

Resolves in #176

No login is necessary. Hence having the same email is not an issue.

Suggestion for command to bring to the tab.

The user probably has an unreal computer resolution. Not sure if it is possible to make it more "scalable" I guess.

Resolved in #176.

Resolves in #176, such a long duration is no longer possible.

Feels more like enhancement to the help window. Although I think the current version is not bad already. I think is possible to not tackle this issue for v1.4.

Resolved.

Opps I did it in one of my PR #255 cos it was related to #185. Didn't know there was this duplicate. Maybe u can check if it is ok?

Resolves with #176

Resolves at #176.

As a student in primary school might not have an email, it is possible for them to use their parents email instead. Hence, we would allow duplicate email in this case and we would not check for it.

Add in as a known limitation under add student.

Feature enhancement that is not possible in v1.4.

Future enhancement that we can consider beyond v1.4.

Duplicated with #256

LGTM

as response to why it doesn't flag,

its cos currently the overlap check is called only through commands.

We have to edit the add(session) methods to call the similar hasOverlap methods, in JsonAdaptedStuent

Ok great!

Thanks for the suggestion, however due to the feature freeze, we will not be working on this feature upgrade for v1.4.

Thanks for the suggestion, however, all changing tab suggestions are considered features and will not be added in v1.4.

Not part of v1.4

Right, I did this already! Thanks for pointing this out! Have closed it already.

I think this phrasing would be better.

in a university to keep track of people they have crossed paths with. It is optimised for use via...

I think putting my full name here will be better! (consistent with the other names)

Fang Junwei, Samuel

perhaps we can change the phrasing of the roles for all of us to In charge of .... e.g. In charge of documentation, In charge of Integration. Currently the role sections sound a bit weird for all of us.

Perhaps Tests instead of test would be better here.

typo in MIT Licence

We should consider ordering the glossary alphabetically. I think that was the initial ordering.

Missing period.

I think this is fine for v1.2 but let's add an issue to add support for different date formats, especially since output format and input format are different.

Is there a need for taskType?

Seems like a hacky way to keep track of subclass name and might not be best practice. We should instead be looking to utilise polymorphism to distinguish the different classes. If absolutely necessary, this should be an enum with final access modifier so there is no chance to change once assigned.

Currently isDone boolean might not make sense, given that we have split task into completable and (possibly recurring) events. This would imply that only tasks that are a Completable should be completable. Perhaps this should go in the completable class instead.

I don't believe there is a need for the toString method here since it is overridden in all it's subclasses. The body of this function will never be called. Might be better to make this an abstract method with no body.

In the original model discussed, Completable was an abstract class with subclasses todo and deadline (or possibly a deadline with optional date field). Is there a reason for the change?

Missing a period.

"Interval should be one of: ..."

dd-MM-yyyy

add requireNonNull(event);

should require non null here

Is there a need to return new EventList? Would it be better to return this instead. If immutability is desirable we can change it to only be able to access an unmodifiable event list.

Add period after each sentence, and perhaps give a short description of the param.

put the return inside the try catch block. try { return Interval....}. In general, good to avoid returning outside the try catch block unless necessary as it's easier to read (usually if you have to it might be better to abstract out the try catch block in a method).

same here, return inside try catch block.

Let's use yyyy instead of uuuu for better compatibility (with for e.g. simple date parser.)

Let's call the encode/decodeDate methods in commons.DateUtil class instead. Feel free to add the date formatter for that one so it matches dd-MM-yyyy.

This doesn't display very nicely when printed in UI, let's add some newlines and whitespace.

use requireAllNonNull method instead

great! for anyone else checking getZeroBased() method checks for negative indexes alr 😃

is creating a new project necessary?

Would it be better to move this check to TodoList for better abstraction.

I've set the observable list to track any changes to the participant list, returning a new project might mess this up. I'll check on my end and change this to a mutable version if needed.

Missing check for projectsFolder, but no worries i can correct in my next pr since it's my mistake.

blank line

might be better to name the test parseCommand_addDto_success since we are only testing the success scenario here. As per https://se-education.org/guides/conventions/java/intermediate.html, we should only leave our the expected behaviour if we are testing for all scenarios.

I think it would be better to add a check whether two objects which are equal have the same hashcode. This fulfils the second point of the hashcode contract as stated in https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Object.html#hashCode().

Also fyi it's not really necessary to check that different objects have different hashcodes (not part of the hashcode contract) but i think it's ok to leave it in this case!

Should also check that same object -> same hashcode.

check for equals too! this is more impt than not equals as it's part of the hashcode contract.

Minor comment, maybe can use the indexes in typical indexes.

same here check for equals!

same here

check equal objects same hashcode

here too

"The update project command and the update contact command are relatively straight forward."

This line doesn't really add much value, can consider removing

typo in projecct.

Also can consider styling it. UpdateProject command is executed

typo "abd"

Not very sure what is meant by "We must ensure that the implementation of each individual command are correct.", maybe can rephrase.

Demeter's law! Probably find for now since we did similar things in other areas, but I think we should file an issue and 1 shot change all.

different deadline here

typo here

Square brackets are for optional parameters, the parameters here do not seem to be optional during testing.

UpdateProjectCommand should be in caps

@param index The index of the project.. would be better

Typos in command name.

Period at end of javadoc.

period at end of javadoc

This message should be for UpdateProjectCommand.

Please use the name of the updated project instead. The toString method of update project does not look good on the UI.

Let's also standardise the naming of parameters with the addP command.

End sentence with period, class names should be in {@code} to standardise with other comments as much as possible.

Same here

This message can be improved, please refer to deleteE command and standardise the formatting with that.

was PREFIX_INDEX used for anything previously?

Parameters should be optional, refer to EditCommand. There should be at at least one field provided.

index should be non null as well.

Please use the Index Class instead

Add a method to Project, this line violates demeter's law.

projectToUpdate would be a better name

should be AddContactCommand

should be groupmate in projects

groupmates

Groupmate

groupmates

group mate builder

groupmate builder

typo should be time

time repeated twice

If it's weekly maybe better to show the day instead of the date.

We look forward to seeing what you accomplish with CoLAB with a clean and inviting UI. Think this part doesn't flow very well, can't see the link between the two statements. Can we shorten this to We look forward to seeing what you accomplish with CoLAB and throw the second part somewhere else where we talk about the ui

Thinking of moving these commands into their own individual section and create a section for today. While today section will only have one command, we can use that section to explain what today means and what information is shown there.

Thinking of moving these 2 sections into projects

agreed. just realized the original AB3 does not use spaces consistently, might be worth addressing this in a future pr?

agree with this, will make changes and update the pr

thanks! @vevek

I couldn't get the StackPane to have 0 min height with other methods but you're right, it looks a bit odd here. Let me look into this properly.

agreed

agreed, will check the other images and relabel them accordingly too.

Using the american spelling color instead for consistency

resolved by setting minWidth/Height as necessary. This stops the panes from fully "disappearing" when resizing panes.

Current resolution updated to 1280x720 for better compatibility

Waiting for your PR @vevek, which would have implemented the required types.

Not my comments, copied from person haha

can confirm no issue here, if target and edited are not the same, and current list already contains new edited project, then the project is duplicated.

This was copied over from person class. Has same functionality as RuntimeException.

https://stackoverflow.com/questions/16241333/specify-a-value-can-be-a-string-or-null-with-json-schema

i believe null values will be converted to "null" in json, but i agree there should be a better way.

following the structure of addressbook,

addressbook contains personList contains persons.

similarly,

ProjectFolder contains projectList contains projects.

good spot should remove the space at the end

yeap surprised my checkstyle didn't catch that. thanks!

ok i might have been wrong on this, i think null should work. i'll change it on my end.

Completable utilises polymorphism. Alternatively, can have an attribute that is null if it's a todo.

This was copied over from the AddCommand. I agree with you, maybe we should open an issue and fix all of them at once?

Similar to comment above

yup good spot.

Require non null doesn't return a boolean value. Also I think it's better to leave it as this, seems much clearer to me.

This was copied over from AB3, what do you suggest instead?

I think the messages have already been abstracted out to one class for messages that are not specific to a class. We should stick to this for now, can consider other implementations in the future

Oxford comma is a stylistic choice, I think we should standardise with or without. I'll reword the to prevent ambiguity.

Using COMMAND_WORD allows the CommandWord to be changed easily.

This test checks that the createFile command does not throw an error when the file already exists

Not repeated one for persons one for projects

see above

dp refers to elevation as per comments, i think is fine for now. If not it'll be DP_COLOR_LOWEST, DP_COLOR_SLIGHTLY_HIGHER, DP_COLOR_SLIGHTLY_SLIGHTLY_HIGHER, which is not sustainable

yeap good catch, this should be changed

No need, only once we implement edit event list. (YAGNI principle)

I want to try an immutable design for events, todos, deadlines in another PR

good call

Actually, now that i think it i think it's ok to leave it like this. I feel CompletableDeadlineCard should deal with UI elements (what to display when the item is completed), and Todo class should stick to containing fields related to a todo object (boolean value of whether it's done or not).

This so in the future if we want to change how a completed todo is supposed to look we just need to change the UI

alright i'll make a quick change

Agreed, thanks for being thorough.

Changed it to contacts to be more consistent with the other level 3 heading (projects). Do you think this is ok?

ID was left out intentionally, copied this method from another handle object. Purpose of this is to compare this handler object to another completable deadline, which doesn’t have an id. I’ll look into changing the naming for these methods to clear things up.

This one a bit tricky. I decided on UiCommand since the Ui works with a generic UiCommand (it doesn't know about the subclasses).

but not sure which ones clearer

How about I edit this to mention calling the overwritten method using polymorphism? Will that be better?

Ah ur right, good spot!

yes, only can tick off using mark as done.

ID is not used in the overview section.

sure

Card to display UI elements (either tick to empty), deadline class will not do UI related stuff.

So each card has 2 constructors, one with an ID (if we need to display the ID so user can select it) and one without, for the overview section where no id is required.

Why not have ID's for both?

I'm afraid users will get confused. I also don't want the users to be able to run commands on tasks in the overview section, as this might lead to confusion.

Good spot haha, will update the other occurrences too.

@vevek I went ahead and changed occurrences of REPEATABLE to EVENT, I think this makes it clearer.

This is handled by throws statement in the method header. Would it be clearer if i explicitly caught and then threw it again?

issue will be resolved in #215, together with other commands that have been updated recently

Yes, i've made more space for the day label. Tried both, i decided this looks nicer.

Spotted this, left it because it was the original implementation. I'll go see if i can change this real quick.

fixed

Think this will take a little longer to fix (requires changing type of backing list & related methods). I suggest we push this to 1.4 and focus on 1.3 deliverables what do you think?

Use setter instead of constructor here so that display panel can be tested in isolation (without being dependent on main window).

Changed

This is consistent with the other view commands, changed because it looks better next to those. If we want to revert maybe someone can take another look and change it for all.

Fixed, problem was some headers have space in between. I've changed all to have space

I feel its clear enough from the first line (the description of a deadline, event or todo). Seems unnecessary. Adding it here would mean we have to add this to the other commands as well.

I believe we should leave this here and update only after PE.

Reason: not updated in v1.3.2, inconsistent error messages might be a bug.

damn it thanks for the save 😦

can will add it

I rephrased and put as a tip instead, if you still think info is better lmk

Was a bit torn on this part. I feel since we rename it's a little more obvious. I didn't want to word this is a negative way, but rather show how this is a feature rather than a limitation. I'll spend a few mins to see if i can reword this.

If i put this in the FAQ would it be better?

it's not a tip though is a feature flaw and i don't want to highlight it in the features. I feel naming it separately and talking about how we can find contacts using group mate name gives a clear indication that they are separate entities. The parameters they take in are also different and they can check the FAQ if got any questions

seems like the ci is failing due to checkstyle issues


ERROR:../docs/UserGuide.md:213: no newline at EOF.

WARN:../README.md:15: trailing whitespace.

Just realised you accidentally changed the user guide instead of the readme haha! Might want to edit the title 😃

Updated user guide with view and undo/redo command and changed some references of AB3 to CoLAB. See #9.

@samuelfangjw Looks great! Please add the changes you have added to features to the table of contents.

Done! Forgot to update the table of contents when resolving the merge conflict. How does the latest commit look?

Tutorial PR irrelevant to project.

Which images are you referring to? @vevek

@vevek XR claims credit for finding 😂

LGTM.

haha thanks but it's still a draft pr! i'll make some edits tmr and change the pr status when I have something decent 😃

Are you able bring back the v1.1 milestone?

can add to v1.1 (there is a closed tab when you click on milestones). if someone wants to do it now i think is ok to change the milestone to v1.1, else we can just throw it to next iteration.

let's add a confirmation message in case users accidentally clear all

Will figure this out one of these weekends, need a pc to replicate bug.

Need to merge #51 before merging this PR, also need to request to use TestFX library on the forum.

latest commit fixes #58

Team decided not necessary.

Looks good to merge. Minor errors. I suggest adding comments to all the methods now so that it's clearer and won't be a bigger hassle in the future.

Which methods are you referring to? There is no need for javadoc comments on getters and setters. Method with @Override tag inherit javadoc comments from superclass, and there is generally no need to add a javadoc comment unless the behaviour has been modified or there is something of note. e.g. equals, toString, hashcode.

I will work on tests and other features over the next few days. If no major issues suggest we merge this soon so other team members can start working on their features.

Lowered priority to low as this does not affect correctness of current code and is not time sensitive.

Great! Please try to finish at least some of the tests, our codecov score a bit low at the moment. Yes, the UI is not ready yet, I'll do a simple one up later.

I'll take a look at this in a couple of hours, think I saw a few oddities but have to take a closer look.

In addition, as pointed out by @Eriksen2411 there should be a blank line between the first line of the javadoc and the params.

Ready for review, currently UI a bit lacking but I think it would be better to improve on the UI in another PR. As for tests, a large section cannot be covered now because they involve the UI. Will be able to do it once we merge #61.

Tests were failing because tests were adding and modifying the same project list. (our list is not immutable, maybe issue for another time). I've solved this temporarily by creating new project for each test.

Ready for review

General hashcode contract states that

When hashcode is called repeatedly on an object, should return same result unless object has been modified.

Two objects that are equal (according to equals method) should return the same hashcode

Different objects do not have to return the same hashcode, although it's good if it does so.

Wah I never knew there is such a contract. Will do it tomorrow!

For the third point I think it should be the other way round. Objects that are not equal should return different hashcodes as far as possible.

I think it should still be pretty safe to check for different hashcodes for different objects since it should be quite unlikely to collide. Do you think we should remove this check?

Yup, no harm checking since very low chance they collide (int can only represent a finite number of things!)

Some minor style issues.

Thanks for pointing this out, wasn't aware there was a style guide for md files. Will look through the style guide again and update.

Let's standardise contacts for contacts in the contacts list and group mates for contacts in the project.

Updated, please take a look thanks!

Currently, I've changed the UI elements to reflect the new groupmates name. However, most of the methods, commands and classes still reflect the participants name. I think better to change in another PR, I've created an issue for this #154.

Done for now, will continue looking another time.

Maybe 1024 * 768

same as #194

Removed in #199

Resolved, changed to deleteC

Thanks! Will work on adding tests in 1.4.

This includes tags, some weekly repeatable events so testers can test all the features

Is fine to leave it for now.

Expected behaviour, not a bug

We should specify clearly in UG.

Expected behaviour, not bug.

Possible Display bug

DG bugs not included in PED.

Clarify meaning of post.

Duplicate of #289

update to Undo success

reason for not updating message to more user friendly message -> no major changes allowed in v1.4

Bug supposed to be fix, need to investigate.

Standardise, among contacts, groupmates and projects.

Display bug

duplicate of #289

unable to replicate

tested with > 100,000 1's

Nothing wrong with command

display bug

Command format is clearly stated in UG.

Command format is clearly stated in UG

Feedback to user does not say wrong format. Keyword here is valid date.

Lower bound for phone numbers is 3 digits e.g. 999, 911

Change to no contacts to display

Apply predicate to contacts when contacts button is clicked

change predicate when button clicked

Nothing wrong with undo implementation in this case. Expected message shown. However, message could be improved.

Already fixed in #281

closed in #332

the purpose of this example is to show how to use the command, not show that optional parameters are not allowed. the example used should showcase the whole command instead of just part of it.

bullet points starting with uppercase letter

should we remove the parentheses?

"confirm crucial commands with a confirmation message"

2a1

this backtick should be at the end of line

missing triple dash

missing full stop

and Prompts

format should be delete schedule

find

change back to Prompt: by module/day/week

removing the 3 lines starting from this line fixes it

for the tick

double whitespace 👀

task

FindTaskCommand

task

tasks

you might have forgot updateFilteredScheduleList, i'll merge my pr first

might wanna change the usage because we are not deleting by index

the ellipsis at the end looks like it's asking for more parameters but in fact, the TAG parameter is supposed to be spread. i'm more towards explicitly defining [t/TAG] as 0 or more TAG arguments expected

as an argument

i do not see your activity diagram in developer guide at all. did you forget to include it?

what is this for? as well as endTime

kiv

should we move these messages to commons.core.Messages? similar approach can be used for #94 #95

should we add an assert statement here that throws if endDate.isBefore(startDate)

change to return equals(otherContact) maybe?

don't just check the name, there are people with the same names

change to Contact's

should we change to [A-Za-z][A-Za-z ]*?

names shouldn't be alphanumeric because underscores do not make valid names

Contact

Contact's

should we do "\\+?\\d{3,}" :3

contact

editedContact

editedContact, contact

contact

??? just use UniqueContactList

contacts

contacts, contacts

change to UniqueContactList

same as above

contacts, contacts

contact

contacts

what is this class name, change to NameContainsKeywordsPredicate

check this file thoroughly and use an import statement to shorten this code

this is not what i meant... IF YOU REMOVED isSameContact CHANGE UniqueContactList ACCORDINGLY


public boolean isSameContact(Contact otherContact) {

  return equals(otherContact);

}

please change this method to the snippet above and revert UniqueContactList

change variable name

"Names should only contain alphabets, spaces and hyphens, and it should not be blank."

refer to the comment in Contact.java

keep this String, will resolve the conflict in #94 instead

i was thinking of moving constants to commons.core.Messages, going to do the same for #94

if this is reopened, revert this line. fixed in #100

#100 should provide source.startTimestamp()

let's use [day/week] so it's uniform with user guide

we should check trimmedArgs first before we instantiate a ListEntryCommand. would going with something like this be better?


if (trimmedArgs.equals("day") || trimmedArgs.equals("week") || trimmedArgs.isEmpty()) {

    return new ListEntryCommand(new ListEntryFormatPredicate(trimmedArgs));

} else {

    throw new ParseException(

            String.format(MESSAGE_INVALID_COMMAND_FORMAT, ListEntryCommand.MESSAGE_USAGE));

}

resolving, deleting the class will introduce breaking changes

will fix in future prs

thanks for the helper method, will revamp Entry#setTimestamp

will request for more changes, approved for now

might wanna change this to MESSAGE_INVALID_ENTRY_INDEX

should be "its"

if can, capitalise Teaching Assistant

the plural of index is indices

should we have DEFAULT_TAGS so we can feed it into the ctor in line 30?

what is this line for?

based and redpilled

wanna do import static seedu.address.commons.core.Messages.MESSAGE_INVALID_... instead?

lovely

in this pr, i don't see this method being used anywhere. can i assume that removing this breaks the tests?

let's change this to MESSAGE_ENTRY_START_DATE_IN_PAST

also use "end date and time", "or time" is kinda weird

heh, i look at it like "date and time" is a phrase. anything ig

entry list
entries listed
list

choose your poison

will modify it as EntryTagContainsKeywordsPredicate

sure, will fix

wip

reopening. missed project description and credits to se-education

closed via #11

refactor UniqueTaskList to NonOverlappingTaskList

obsolete, refer to #80

the EntryNameContainsKeywordsPredicate is broken, will use the one in #97

permanently closed

meme

closed with Contact class refactoring

updated regex with Contact class refactoring

closed with Contact class refactoring

changed to strictly 8 digit long with #181

lel why are these changes not done along with #191?

closed with #181

invalid issue anyway

thank god for equalsIgnoreCase

#181

invalid issue

Please add "by their name". Your sentence is hanging right now

literal "abc" should be the constant NAME_FIRST_PERSON

please put this in a final variable like final String nonExistantName = "WHATever it is";

I think? this is fine, but I'm not certain. Double check best practice maybe?

Good good, Nice to see you not having magic literals.

Maybe put in a variable with a descriptive name first like String nameOfPersonToDelete

Should this be an invalid name, or would rejecting a number suffice for this test?

LGTM, although I personally would prefer 'their' instead of 'his/her'

it should be delete NAME, not delete name. All Caps for variables I think

Class is wrong and variable name is wrong

AddressBook ab should be ContactList cl

getTypicalAddressBook should be getTypicalContactList

addressBookStorage should be contactListStorage

Method name again

readAddressBook method is wrong

method name is wrong and probably wrong for many test case code

variable name differentAddressBook

comment has reference to ReadOnlyAddressBook

value = "addressbook" is probably wrong 😦

addressBook variable name

Class name AddressBookStorage

Comment is unchanged

method name

variable name

bad comment

variable name addressBookOptional and method name readAddressBook

method getSampleAddressBook

method name

comment is bad

Also method name

variable name addressBookStorage

getTypicalAddressBook

method name

saveAddressBook is bad

setAddressBookFilePath 👎

method name

getTypicalAddressBook is a thorn

method name 👎

method name and variable name 👎

I think this one and this one alone should be unchanged given that it references an external project

More bad method names and variable names

comment "Converts this address book into the model"

I would prefer if you have hash code account for both carBrand and carType

Method variables test1 and test2 should be descriptive, like testBrand and testType

While good to see, is it best practice to have a feature PR and a bug-fix PR mixed together? Worried we might be penalized for bad PR practice

Does "+Subaru" produce the array ["","Subaru"]

Could replace x with customerCar, but its not exactly block worthy this close to deadline. Fix soon during 1.4 please.

Could replace x with customerCar, like in the other filter.

Good catch

Should not be default condition. Explicitly check for PREFIX_NOT and if you reach an else branch, throw an exception.

Did you OK this with the writer of AddressFilter? Want to just make sure.

Is there supposed to be additional spaces here?

Please put something here or remove it entirely, for the @return tag

Did you OK this with the writer of CarFilter? Cause this is probably different from the intent of @OhJunMing

I suppose that this is better than my current implementation, but after you commit, I will provide a potentially better version.

Or at least try to

Also, please rename the function levenshteinDistance to subsequenceDistance. Its confusing and misleading otherwise.

Good job here

Also good job

Did you mean to change this? I think here, they were trying to align the descriptions

This is um... confusing? Can I clarify whether this is a placeholder for v1.4 work?

Good job! Very interesting

I probably would have missed this myself

Small comment, please add a TODO here for me to write new test cases here pls;

Example TODO: Write new test cases for the overhauled command

Probably want more test cases if possible. Add a todo here pls

Not sure if we need new test cases here or not 😕

Good job here

Same here.

Acceptable

LGTM

Are these debug code left over?

Are we just leaving this debug code in?

I mean I suppose we could, but I want to make sure, given the other debug code you left in

Is this the solution? Could you explain how this solution works?

Will do later

Will put the trimming function in the ParseUtil class.

Attributes are "Car" and "CoeExpiry"

This is meant to fix the issue mentioned at https://github.com/nus-cs2103-AY2021S2/forum/issues/262

Perhaps standadise it to ITEM_NAME.

Same for here 😃

Our list takes in an optional parameter, so may consider removing it from this line.

our list should be able to in an optional field, location.

Should consider changing edits to updates 😃

Should be deleting an item instead 😃

Check google docs for delete method for StoreMando 😃

One suggestion I have for these JSON files is that maybe we should rearrange the sequence to match our display sequence to make things more neat and tidy 😃 so instead of the current name, quantity, exdate, location, we put name followed by location and so on based on our current display.

Some variable changes are still seen here and there

For this part just let Fazil know to change this to standardised locations, because this one he may overlook thinking that it's correct cause Apple Banana etc are what we using for item names.

For this when it is showing all items will it also work as normal?

It May be too technical for a user guide

Perhaps its better to say 'Expiry date of an item is optional'

Why is there an additional catch NullPointerException?

understand that for this file the sequence in which what is placed first does not matter, but for readability and consistency of our code base we should perhaps standardise it, following the google docs sequence

I think "Quantity should only contain numbers..." will suffice, can remove the "numbers" after Quantity

This may be a violation of Law of Demeter, cause browserutil calls a method that calls helpwindow's string. Maybe can consider shifting the USERGUIDE_URL to BrowserUtil instead 😃

Instead of calling 2 booleans, maybe inside BrowserUtil class create a boolean to check for these 2 booleans, since at this class we don't have to know the details. Maybe can create a boolean called canOpenBrowser 😃

Agree with this, but if its functional we can leave this to v1.3 as well. 😃

Personally I will prefer trimmedArgs = trim()

Then in the condition, we use equals ignore case instead.

What's the set of names we following from now on? For the original ab3 it was ALICE, BENSON, CARL, DANIEL, ELLE, FIONA, GEORGE. What's the pattern for ours?

Agree with kums!

Agree with Fazil!

I feel that this shouldn't be an exception condition because we should instead just ignore whatever that's not the first arg. So reminder 6 haha should just take it as reminder 6. on the other hand reminder haha 6 shouldn't work but it has been considered in ur try catch method below.

Whats the reason for parsing it as long instead of int?

With my suggestion below, this will become unnecessary

for this whole parsing right, perhaps you may wanna think about changing it to a prefix kinda thing. Say reminder d/3 reminder w/2, with that you will be able to use preambles and also prefix isPresent to do most of the checks here and I can foresee the code to be neater 😃

how will the >a name = "delete">>/a> look like in the user guide page?

perhaps change to 'NUMBER' instead, because in our user guide only command words are small letters in format I think 😃

will 1 day and 1 week work? or even 1 must be days and weeks?

if 1day and 1week work then that's the best. Else here's my suggestion:

change the implementation such that 1 day and 1 week will work.
make it extra clear in the user guide (1 more sentence behind it) to emphasise that day and week will not work. 😃

There will be a need to update this part of the user guide because now there is quantity asc and quantity desc 😃

also this, it should be expirydate, emphasise to the users too that it is case insensitive. 😃

There will be a need to look into this section to double-check, examples will be reminder and sort. 😃

Can we add one example for weeks as well? 😃

I think u just need the first line to be in if else statement, the rest should be outside as one right? 😃

Maybe instead change it to 3 positive path conditions in if elseif, throw in else. 😃

maybe change from 'remember items' to 'keep track of items' 😃

Should it be 'make the most of StoreMando' or 'make the most out of StoreMando'

What will >a name="start">>/a> show in User Guide page?

Will this hyperlink still work after u added '3.' for 'features' below?

Can we make this example more legit, perhaps change to l/kitchen cupboard 1(somewhere more normal) ... e/2021-04-01(a date that is more updated as of our user guide edited date)

Is there any part mentioning that '[]' equals to optional? because even though tag has '...', in edit for example most of our parameters only have '[]' 😃

I think this info about the index being positive is not required because it has been stated very clearly in the sentence before this that 'The index refers to the index number shown in the displayed item list.' 😃

same issue with the previous examples, which is likely to be the same for the rest of the examples. Please look into this! Thanks! 😃

Same reasoning on this just like the previous comment. 😃

Why is this not bold anymore? How will it look like in the user guide page?

u did the assertion then here no need the if alr right 😃

I think SortQuantityCommand shouldn't be taking in a boolean 😃

1 suggestion I can think of is to create 2 separate classes handling asc and desc. I think there is a more elegant way though 😃

Can remove this assert because now the number of days can take in any number 😃

maybe consider declare 2 final long at the start, so next time if we want to change the day can be easier, currently is like magic number 😃

I think better to put like private static final long EXPIRED_NUM = 0 etc 😃

are the lines required for proper display? oTHER 💡 etc got such lines?

If you are putting a line break then i suggest you give it #### for the sub headers 😃

This one no need already. Can change to

TIME_UNIT must be either days or weeks.

day or week accepted when number is in the range of [-1, 0, 1]

This example abit too specific, by the time people read it it won't make sense already

I think some of these test cases are too repetitive, I understand that it is to test for boundaries but i don't think this many test cases are needed. Maybe just boundary for 1/2 months etc. Same applies to other checks in this file 😃

I think Prof Damith mentioned something about there's no need to check for different types because it simply will not be the case. I understand that in original AB3 they had some tests checking types but I think we can omit all of such test cases. 😃

Yup that is the format we agreed on.

Intro to the feature

Sequence diagram

Steps of implementation

Activity diagram

Design consideration

this wont work, need to revert back to original layout

should standardise one spacing between each section 😃

This part should not be changed, it is not part of the implementation

No sequence diagram found for this implementation

maybe can consider reduct the usage of 'then' and 'will then'

I think can change to GUI

put a spacing between portfolio and this sentence, so will be in a new paragraph 😃

You should remove Project management section from your md 😃

do not put >br> in your code, that is against the coding standards for md files 😃

Design considerations for both features have to be added

I think instead of saying 'between -366 to 366', 'from -365 to 365' may be better 😃

Fixed 😃

Resolved. 😃

Nope it was not fine, thanks for spotting!

Yup I will remove this file now. 😃

Better Model class puml is not in use as of now. 😃

It looks like this now, the hidden arrows wont be displayed.

Thanks!

This will need to look into it further in v1.3b, we will take note of this! thanks!

Yup thanks Fazil!

Understand, will make changes on that! Thanks!

Will add more test 😃

Alright I will try 😃

I think this is fine because I'm calling the itemlist in model itself and not somewhere else right 😃

no, it basically takes in all the words in the args, so say " 3 day ", it will become "3" and "days" 😃

Will be adding for the team I reviewed for in the next iteration 😃

alright 😃

alright will change this!

Alright, will get this changed!

Will fix this 😃

I copied this from our module recommendation, not sure which should be the correct situation

Ok will do!

yes it is still a limitation

Alright will update this

will do!

😃

Sure will make the change! 😃

will make the change 😃

we do have that in the UG alr, it was updated by @kumsssss in the previous UG PR 😃

The search is case-insensitive, so 'B' matches the 'b' in table of mahjong table.

The error message matched correctly according to this feedback.

This was designed on purpose, we do not want to restrict the users on such inputs, all we can do is give them a warning message, informing them that the item has already expired.

Suspect that the user executed find on a sublist that did not contain burger, we need to fix this in the UG, informing that commands are being performed on the displayed list and not the full inventory list stored in StoreMando.

This was a design choice by the team.

Keyword expirydate has been given in command format expirydate.

Yes that is a design choice by the team, items with the same name and location will be treated as the same item, regardless of tags.

This is a design choice by the team, we should not restrict the users with such input constraints.

Like how it was mentioned in the UG, warning will only be shown if the item differs in letter case.

Should the command be find instead of search?

Would it be better to name the field expiryDate to date? I think it would not be as ambiguous and would be easier to understand.

Instead of first checking if the expiry date format is correct using regex, he parses the input right away and catches DateTimeParseException to determine if the specified input is a valid expiry date. I think it will still work as intended.

Should this nonNull check for expiryDate be removed?

Should this be "Sorts the items from the inventory" instead?

Would it be clearer if we state "sort quantity will display the items in the inventory in ascending order of quantity."?

I think we can provide example usage similar to how the other commands provide it currently as well.

I think it is fine to leave it as it is as this is just a custom comparator. Perhaps, the naming of the class can be better.

Would this message usage be misleading and give users the idea that both tag and location can be specified? Would it be better if the message usage is [l/LOCATION]/[t/TAG]?

Would it be better if it explicitly states "user-specified number of days from the current date..."?

Perhaps, you can try checking both conditions for trimmedArgs and numOfArgs in one if block and throw a ParseException to avoid repetition?

I'm assuming this is not case-sensitive. Does it mean that "Weeks" would not match "weeks"? If that is the case, we have to clearly specify this in the user guide.

I think this way of checking would break if the user keys in "reminder 3" with 2 spaces instead of 1. This way " 3" your argument would be " 3" which would cause a number format exception which would be caught and eventually be thrown as a parse exception. Are we going to be strict about this? Currently, the other commands don't seem to take into account additional spaces in between prefixes and command word.

Can you clarify the way you are parsing?

I agree with Jay as well. I think it would be less ambiguous and would be standardised across the commands.

Does this violate the law of demeter since you are getting an object from item and accessing its field?

I believe Item should provide a method that retrieves expiryDate directly.

AB3 used address book and it's name interchangeably. In our case, our UG uses StoreMando and inventory as the two terms to refer to the app. Would it be better if you change all the usages of address/location book to inventory instead?

As mentioned above, this could be "causing another modified inventory state to be saved into the storeMandoStateList."

My personal opinion is that the welcome message should just be "Welcome to StoreMando!". Just a suggestion to consider.

I agree with Kumaran. I think it should be written as "User searches for items that are expiring within the next 3 days".

I think this should be written as "User inputs a negative number".

Perhaps, I think this step should be removed.

I think can it would be better to phrase it "User requests to delete all items in a specific location".

I think this should be "prompts the user for a correct location".

Would the benefit be clearer if we specify "I want to clear all the items in my room at once so that I do not have to waste time manually deleting all the items in my room"?

Should this be "StoreMando prompts the user for the correct input"?

Should we be writing this as "with the aim of helping users manage their items effectively and efficiently". Since this is a more description of the project, I think using the same tone as user guide would not be appropriate. What do you think?

Similarly, I think we should avoid using first person in this section and write it more formally.

I think we should personalize all success messages as a whole to differentiate the individual features rather than returning a generic message for all clear/list/sort command types. Maybe this would be a good place to start and we can improve on this in the coming iteration. What do the rest think?

Personally, I think this does not follow the single layer of abstraction principle. Perhaps, one suggestion would be to create a method (ie; clearLocation) in the class responsible for managing the lists and call the method here.

Yes, I think this would not work with additional spaces as well using equals.

This method name states that parsing an empty argument would throw parse exception but you are testing for parse success. Perhaps, you might want to change the method name.

Maybe you can consider adding spaces between prefixes and test all possible valid inputs.

Can we abstract it out further? This method calls setItems method of model class and retrieves model's own attribute to pass back as a parameter. I think we can create a method to abstract this out further.

Can you clarify how is the parsing is handled? Would this break if there is an additional space passed in?

It would be better if we create a method like "refreshExpiringItemsPanel()" to adhere to the SLAP principle in this method.

Can you clarify if this would break in the event of an itemList of size smaller than 7 being added in?

Is there a way where you can prevent method chaining and check the expiry date?

Would it be better if it is "which allows users to view items that are expiring within a certain number of days as specified by the user"?

Shouldn't StoreMandoParser have the grey highlight as well?

Should it be "Determines that the command given is a ReminderCommand"? Also, I think we should standardise the use of string/command to specify user input.

I think it would be clearer if we specify "parse the arguments provided in the user command" or something alone those lines.

Should we grey highlight method names as well similar to execute above?

I think it would be better to break up this line. There seems to be too many things going on in one line.

I think it would be better if we include the sequence diagram before the implementation and use the sequence diagram to explain the implementation instead. It would be easier for the reader to understand the implementation.

I think StoreMandoParser should have a grey highlight as mentioned above.

It seems as though lines 3 to 7 have an additional space in front which you may have added due to the grey highlight. I think we might need to check if the additional space is actually needed.

One suggestion as mentioned above is to include the sequence diagram above the implementation.

Should it be "shows how the clear by location feature works"?

Is this incomplete? If not, I think it is best to omit the section altogether if there is nothing to add.

I think it would be clearer if you state "The overridden execute method of DeleteCommand will be called".

It would be better if we specify what the actual result would be. In this case, it will be a command result object.

I'd suggest including the link of all the PRS that you have reviewed and given input on.

Perhaps, the line "You can reach me at the email mohamedfazil@u.nus.edu" should be in the following line.

Should this be "An item can have 0 or more tags."?

We will need to update this to include locationlistpanel and reminder panel.

Is this limitation still valid?

Should this be "Users would be able to retrieve a specific item more efficiently."?

Would using find be confusing for readers since we already have a find section before this?

Also, I think it is better to state "All items that have already expired or are expiring within the next 7 days are shown".

Similarly, we have to mention about expired items being shown as well.

Would it be better if we follow the user guide and state "All the items are sorted in chronological order of their expiry date"?

I think this should be "expiring within the next 3 days".

I think we should also add in a section to explain the difference between similar and identical items. Maybe, we can add a section for that or define them in the glossary.

If you have not, I'd suggest to review this section as well. If you have done this and found that no changes are needed, ignore this comment.

Fixed

Fixed.

fixed.

Agreed with Wei Hao. I think it is fine to leave it as it is since there is no fixed input format and prefixes can be specified in any order.

Fixed.

Thanks for the suggestion. Fixed.

This follows the original setup. I think it's fine to leave it as it is for now.

We can leave it as it is for now as mentioned above.

Value was used to standardize across all the fields an item model is composed of. I think it would be more consistent if we leave it this way.

I think we can display the warning in red color in our GUI instead of using all caps to warn. I feel it would be friendlier that way.

Fixed.

I think it is still fine as the class MainWindow has helpwindow as the immediate neighbour and I'm passing the URL as an argument to the displayWebsite method in BrowserUtil.

Thanks for the suggestion. Fixed!

Upon further thinking, I have shifted it as per your suggestion as it was more practical. Thanks and fixed!

Alright, fixed!

I think both are fine but I'll change it to make it clearer.

The anchor tag will not be displayed and only the hyperlinked quick start will be displayed.

I have updated the features section header to contain the anchor tag. Thanks for pointing it out!

Yes. This has been included in the existing user guide and I did not make any changes to it. Therefore, it is not highlighted in this pull request as a change.

Fixed!

I think it is better to be as explicit as possible in the user guide and there is no harm in doing so.

As mentioned above, I think it is fine to leave it as it is. Perhaps, we can get the opinion of others as well.

The subheaders will appear in bold when displayed in HTML so it will still be fine.

Thanks and fixed.

Yes, I have changed it.

Noted on that and I have fixed it according to your suggestion. Thanks!

Noted and I have fixed it accordingly. Thanks!

Fixed.

Done!

Fixed and thanks!

I think we should keep Mainstream OS in the glossary as mentioned in our NFRs

Perhaps it would be more consistent if we used 8 spaces here for indentation as well.

Should we revert this back to 8?

Perhaps we could make dd-MM-yyyy a constant string, since it is also used in line 40

Same here for HHmm

Indentation should be 8 spaces

Same here indentation issue

Indentation issue as well

Same here for lines 132, 133 and 136

Duplicate opacity styles

Duplicate opacity styles here as well

Indentation issues on line 22 and 24

Not too sure about this, but should this be private static final?

Let's standardise to double quotes for all strings

Should be okay to remove the old getMeetingList() and getDateList() which returns empty lists right?

I think this can be removed?

I think we should add spaces around the ->

Extra empty line here

I think BIRTHDAY is fine here, or perhaps DATE instead of DATETIME

Could we add a "*" multiplicity to Event? Might be good to use labels here as well since there are 2 links to Event: dates and meetings

Would be good to standardise the term css to be always in lowercase

Do add a space between the hashes and the title itself, as I'm not sure if jekyll can parse the markdown properly without

Add a * before the example here for consistency with the rest of the UG

Would be better if we used the theme's colours here

Should be subtract-debt i believe.

Do add a newline after this line

Would "provided" sound better here?

Copy nit: "Although optimized for Command Line Interface enthusiasts, the intuitive interface allows anyone to get started with it immediately."

Copy nit: "This document walks you through the User Interface and Features present in FriendDex".

Copy nit: "Your Computer's operating system (OS) needs to be Windows, macOS or Linux, and the OS version you are using should still be supported by the respective companies."

"please refer here" sounds a bit strange. Perhaps "please click here"?

Since the file is deleted, I think we should just remove this line from the gitignore as well.

Maybe use logger instead?

I realised your new theme files do not have the .json extension. Not sure if that's intentional

Remember to update the documentation to include the new personStreaks param

I don't think you need to handle this case anymore as I've removed the time param from the requireAllNonNull check in Event's constructor

Nit: Extra space here before the full stop

Is the %1$s not needed for invalid date? Should we also remove it then for invalid time?

Probably no need for a new variable here. Perhaps just deadline.equals(DateUtil.ZERO_DAY)?

What does this part do? Will this display streaks for people with no meetings yet?

Can we rename the param test?

Just realised this test and the previous test is exactly the same.

Can reword to "Meetings are records of past events, and should not be in the future. Meeting description should not be empty."

copywriting nit: "The Streaks dashboard shows the number of consecutive times you've met your goals of meeting your friends up till today. More information on Streaks is available here."

Can you move this to the alert block below? (Line 191)

Similarly, place this in an alert block as well.

Can we remove the "the" before the dates?

"on the 13th March" -> "on 13th March"

"on the 30th April" -> "on 30th April"

This line is a bit fierce.

"A streak is the number of consecutive times you've met your goal of meeting a friend. Your streak increases if you've met a friend before the goal deadline. Simply put, if you have a high streak with a friend, you've been really consistent with meeting that friend! Refer to the Goal Deadlines section for more information on how deadlines are calculated."

Is this "will be added" or "will not be added"?

Is this double casting necessary?

If i'm not wrong this section can be simplified to:


if (current != null && bytes[i] != current) {

    break;

} else if (i == magicNumber.length - 1) {

    return true;

}

Agree with ivan that we should add a space after the super(FXML) line for consistency

This internalIllegalValueException seems to be used in quite a few places. Can we abstract this exception out?

Can remove the / at the end of the line

Can we change this to Adding a person to be more consistent with the rest?

Can reword the error message to "There is no need to add people to \"%1$s\" as everyone is included by default."

Can reword the error message to "\"%1$s\" cannot be deleted."

model.setGroup will update currentGroup already so line 41 is not needed

Capitalise Everyone

Re-add the new line here before merging! Will break on jekyll

Could you add a >br> here before "Test"

Hmmm the idea is that it could be used for any kind of special annual date, not just anniversaries. Any other ideas?

We can't simply compare LocalDates as we're not taking year into account here, since the events are repeated annually.

I'm unable to put them in their respective classes because it requires the Person's name, which is not stored on the Birthday and Event class.

yeah its just a label now no styling yet

I realised in some places I named it UpcomingDates while in others they were UpcomingEvents. Actually, I just realised in logic it's still called UpcomingDates. I think I'll just revert and switch it all to UpcomingDates.

Ok will do. Anyway I think i'll leave it as UpcomingEvents for now. Might rename all in another PR

Nope. All this does is check if the detailedPerson is the personToDelete and if so, switches the tab to the upcomingEventsTab.

The limitation of such an implementation is that if they are not on the detailedPersonTab, (i.e. streaks tab) the details panel will still switch to upcomingEventsTab.

Okay but need to reword. The current description is inconsistent as just one section later we use it for "Java 11".

@Assyarul Has this been resolved in #58? I think we can close this if so.

Right, my bad I realised my Mac had "Prefer tabs: always" toggled in my sys prefs. Will update the screenshot

I'll work on this

Both @ivantjh and I have been using Big Sur throughout the development of tp and have not encountered this issue at all. Unable to reproduce this as well.

Intended. There shouldn't be a restriction on what a user can consider as a description of a date.

Duplicate of #117

Duplicate of #129

🤦 our UG example says meeting instead of add-meeting @ivantjh

Should AddCommand always return to the all person view?

Yes. As a user, after adding a new person, the natural intuition is to check that the new person has been added. While we have a confirmation message, it would be better to switch to the all persons view so that users can visually confirm that their new person has been added.

If they were still on the groups view, visual confirmation would not be possible as it takes another command to add the new person to the group.

Should DeleteCommand still stick to the groups view?

Yes. Similarly, after deleting a person, the natural intuition would be to verify visually, by comparing the current list of people with the previous list of people they saw. If the person is no longer there, users can rest assured that the person is deleted.

If they were initially on the groups view, with 3 people. They would expect to see a new list of 2 people. Switching them to the all persons view would throw them off slightly as they are now presented with a list of potentially more people.

Duplicate of #165

This has been resolved by disallowing future dates for special dates.

Fixed in #216

Fixed in #229

Closing as the implementation of this feature might lead to additional bugs, which is not ideal based on our timeline.

It should be optional for radd so can you update it?

Ah, I was referring to adding the brackets i.e. [r/ROOM] for optional tag

missing javadocs?

Missing param description?

@throws NullPointerException?

Is to be to a typo?

Missing punctuation and capitalization for "issue"

Missing punctuation and @param description should be "Target index of the issue in the filtered issue list to close." (separated from the param name)

Missing punctuation and @param description should be separated from param name

If possible, please add javadoc for this method!

Missing punctuation

Missing punctuation, param description should be separated from param name

Missing punctuation and captialisation of "string" and "if"

Missing punctuation and capitalisation

Missing punctuation and captialisation

Missing punctuation and captialisation. Param description should be separated from param name

Missing punctuation and captialisation. Param description should be separated from param name.

Missing punctuation and captialisation.

Missing punctuation and captialisation. Param description should be separated from param name.

Missing punctuation and captialisation.

Missing punctuation and captialisation. Param description should be separated from param name.

Missing punctuation and captialisation.

Missing param tag

Missing punctuation

Missing param and return tag

Missing punctuation

Missing tags

Missing tag

Missing punctuation

Wrong class name?

Done!

Good catch!

Will do in later iteration

Done!

Good catch!

Done!

Good point!

Done!

There is only one field so field is chosen

Good catch, updated!

Done!

Updated!

LGTM

Do remove the trailing whitespaces in order to pass the build checks

Is this needed?

I think would be nice to remove the comma to standardize

Additionally, can you help to remove Line 8 as well (I think not relevant)

Sozz, i realized the bolding looks a bit weird, would be good to keep the bolding within the same sentence.

For this portion, I think would be better to use the one in @weixue123 's branch, so might need to merge it in first.

refer to this portion

Would be nice to have spacing between CHIM and the full stop

Are we keeping this portion? Can refer below for the modified command in @weixue123 's repo

code portion

Use the static method getCheeseType instead of the constructor (wanted to make the CheeseType a bit Enum like so we can also use == for comparison)

Add whitespace

Would be good to leave it as private and use the static method

Do specify the type of each date, currently it doesn't show what each date represents

Same for order

Any reason to prefer this over null?

Is it possible to increase the padding? The cards seems a bit too packed

Would it be possible to use enums instead?

add assertion error here

Remove debug statements

Possible to extend DeleteCommand to do more. for e.g. help to do the basic checkings such as index out of bounds and so on. If not enough time, its fine

(must be a valid phone number)?

use .equals instead

would be good to do new Phone(customerToDelete.getPhone().value) to ensure that it is comparing by value and not just by reference

Would you be double calling the method (because you call it in Delete___Command.java as well). Would suggest that you call it from outside instead of here.

Possible use case is, in the future if we allow deletion of customer with all of the customer's order, the panel should only change to the customer panel and not the order panel

Just a suggestion (but up to you), you can consider using "Assigned" and "Not Assigned" instead

use .map(x -> x.toString()).orElse("-") so that it does not throw null pointer exception

sorry forgot to update this in properly in previous commit

Additionally, do add isAssigned to .equals as well.

Do the cheeses need to be updated to have the isAssigned attribute?

yeap something like that

seems like a static method because it doesnt seem directly related to the object

Would be good to set the panels inside the commands instead.

Was thinking in the future, if we for some reason modify a cheese's ID, and have to update the order too, then the view will be changed to the order panel (instead of the cheese panel)

The logic is good 😃 possibly can do 2 things

Sort by maturity date too (to ensure that the assigned cheeses are matured)
Can just use a counter to count the cheeses instead of using decreaseQuantity(), seems a bit sketchy haha
I think the setCheese should be done else where maybe in the command (using model.setCheese()). The getUnassignedCheeses should only get the cheeses without updating anything yet

Additional whitespace here

I'm not sure if it would be benefitial for us to set quantity's value to private (because it is already final so we can't rly change it anyways). But if you do have a purpose for it, then I'm alright with it

Hmm, curious, does equals on the hashset not work?

I think I found out why (my part also affected by this), have to make sure that all the ids have the same hash. Will be updating in my branch

Was thinking that CheeseId should not be doing things for the sake of the stub (i.e. not know of the existence of the stub). Can just specify that it returns the next Id?

Add newline before Example

Same here

Do update the toString method for cheese (now showing optional.empty)

Currently, there is one issue with this. Steps to replicate:

Use find command to Find Customer B
Delete Customer A
The customer phone number provided is invalid.

I would suggest to use the getCustomerWithPhone to find the customer instead, filteredCustomerList is a bit unreliable

Instead of doing this, would it be possible to have a method, e.g. getOrdersForCustomer so that you don't have to change the filter all the time? I'm afraid similar bugs as the issue mentioned before may appear

Same as the comment in #37, don't think that we should change the UI portion just to delete the cheeses (although functionaility-wise it is exactly the same, just the organization is a bit different)

Would suggest to use the getCustomerWithPhone method in AddressBook instead of filtering the whole list

Do resolve conflicts

Same here

this not needed here? seems like a repeat in OrderPhonePredicate

Method should be private, you may want to use the getCheeseType static method

Hi, may I know the link for the diagram

Also can consider removing the [In Progress]

This looks gd

Should the sequence diagram contain the strings? it seems like a bit out of place

Mini issue: JavaFx is JavaFX

Should the sequence diagram contain the strings? it seems like a bit out of place

Also the CHEESE_LIST what is it suppose to represent?

Sure, I just pointed out because there seems to be no explanation for it haha

I think the first asterick is for bullet point

is it java -jar chim.jar?

Any reason to remove?

maybe can bold the word all

Change Expiry Date and Manufacture Date to caps and ``

Will bring up a proposal for this in the meeting

My bad, the class should be used in Order, will add in in next commit

3 Things

This portion of code is to test the EditPersonDescriptor (which is not a part of the model, but only used inside Commands, hence this should be in the right place
Regarding invalid dates, will add a few in the Dates class
Regarding invalid cheese types, currently there is no way for a cheese to be of an invalid type (because it just needs a name), unless we check for empty String

Would be nice to standardize but might not be necessary (will have a lot of existing codes to update)

Will bring it up in meeting tmr

I think would be good if it is the 1st case (less bugs when they smoke test)

Which would you suggest to drop? If we want, we can just keep expiry and manufacture date (then I can add one more case in the AddressBook to ensure that the Cheese's manufacture date must be after the order's order date)

I think this might cause some trouble on our side cause imagine if Order shows all the cheeses that are assigned to it (and also cause order needs to check that the cheese is of the same type).

I think, we can possibly disallow cheese deletion if the cheese has been assigned? (cause I think delete cascading will be bad for this)

Will discuss on Saturday

I only didn't include the arrows for updateFilteredCheeseList (it returns void), the rest are included

The AboutUs image is not working... I think you would need to rename it to laurenlhy.png (currently its named laurenlhy.png.JPG)

Hi, you can check out the branch telegram-github-notifier on the master repository. It seems that the build isn't working there as well.


Forbidden: bot can't send messages to bots

Actually do you want to squash some of your commits, before merging. But other than that, everything seems fine.

Yea, I think would be good to squash to about 3 commits

I rebased the branch, gonna merge it in soon

Closed in favour of #20

Do remember to modify your code to support the toggling of views once #20 is merged in

There is one class of ModelStub with no useful methods, and the rest of variations are extending from it and overiding methods important for testing. We could make it abstract though. What else do you think we can do. The idea is we have two kind of test suites: 1 with using the actual ModelManager and 1 using just the stubs.

I probably can't think of a better way to do it, but I'm afraid in the future it might get a bit messy because of the so many variations

So for the architecture diagrams, nothing has changed actually, so I will use the same diagrams as before. For the edit commands implementation, I might add a sequence diagram, but that would be very similar to other commands like Add and Delete. I would feel that an object diagram, to explain the dependencies between the models would be more relevant to my content, but that might be covered under the model designs?

But you would have to come up with something that you have worked with before, so I think would be best to add the sequence diagram

Should the sequence diagram specify the arguments?

For the EditCommandSequenceDiagram, do include the command string

hihi, do resolve the comments in gdrive too

Duplicate of #54

Duplicate of #55

The findcheese command can be used instead to filter and count the number of each cheese.

New features will not be considered

Issue of ID being different from the Index of the list

Delete cascading is an expected behavior

Do rebase and i think it is good to merge

Do rebase the branch, seems like there is some overlaps

Same, do rebase the branch. Also check if the other messages are correct

maybe block letters? follow the format of the other fields

can consider removing the extra blank line?

I think this JavaDoc comment can be further refined.

Can I check why you think it is better to not differentiate code/command line keywords from normal words in a sentence?

Would it be better to display all the possible parameters?

Do you think it would be better to give the user instructions on how to initialise/use our application? Or are there reasons why you think this should not be here?

Could you check if there is an & delimiter for the subsequent keywords?

Would it be clearer to the user if we used markdown to format the keywords here too?

Do you think a person should have a tag describing a policy if s/he has no policy number?

Do you think it would be more consistent if you ended this line with a fullstop, just like the above lines?

Do you think we can use more suitable tags given the insurance agent-client relationship?

Would it be more consistent if the policy number format followed that from above? It is not very consistent with the policy number formats written in the Quick Start section, and the Features > Add section (there are 2 different formats in 3 different sections).

Also, there is a spelling mistake for the t/premiunplan. Do be more careful next time!

Do you think it would be good to clarify on the maximum number of flags that can be used in each command execution?

As Yong Shen has suggested in my PR, do you think it would be be more intuitive to the user if we rename policies as insurance policies instead, so that the 'i' flag is more suitable?

I was wondering if it would be good to clarify if a keyword is bounded by '&' delimiters (if any)? Else, some users might think that keywords are words and mistake a search for 'Hans Bo' to return the same as 'Hans & Bo'.

As in the above comment, perhaps we can add in an example where we should find alex david to show the difference between the 2 types.

Just something minor: would be good if in our documentation we can clarify that our search is case insensitive.

Would it be clearer if the regex was stored as a constant so that another developer would better understand what you are trying to split by?

I realised that this List>String> is used in all the subclasses. Perhaps we can consider shifting it to the parent class in the future?

Just to check, this test checks if the address contains "12345", "alice@gmail.com" or "Alice" right? If so, perhaps it would be better to clarify that the person's address does not contain any of these keywords and thus the match fails? Else, it seems like we are testing for all the fields mentioned.

Same comment as the other file!

I like that this is so succinct, but others who are less proficient/new to Java might find this hard to digest, since it condenses a few steps into one. Do you want to consider writingn this on separate lines?

Do you think it would be more readable if these two strings are abstracted to static final variables?

Do you think it would be more appropriate to name the test to describe that you are testing reapeated unlocks/mutability rather than just "equals"?

Would it be more appropriate to name this variable POLICY_ID_CONTAINS_ANGULAR_BRACKETS rather than POLICY_ID_CONTAINS_CARROT? Since carrot can refer to ^ too.

If I'm not wrong the # symbol is placed after a class name to show that the method following the # belongs to a class. Perhaps it might be clearer to do so such that other developers will know where to find this method?

Do you think it would be good to give an example? Not everyone might understand what MM means.

Same for this too.

Do you think these variables should be publicly accessible by other classes?

Might be good to color code too.

The links for the colored words do not work.

Might want to check with Boon Hong to include a writeup for meetings.

Do you think it would be clearer to shift the "E.g. ..." to the next line? Else someone who is looking through it quickly might mistake it to be "for. E.g." to mean "for example". Perhaps can consider using "For example" instead of "E.g.", since this is part of a sentence.

Capitalisation issue: "What information...", but "what information..." is shown.

The spacing between this bullet and the next is less than the spacing between 2 consecutive bullets in the previous commands.

Actually, would it be good to put the table here? Since we are describing the features.

Should json be capitalised?

I think he already added.

Do you want to consider removing the fullstop from the picture caption? Just looks a bit weird to me. If it's fine for youm can leave it in.

I think we can add in a line saying that duplicate indices e.g. "1, 1, 1" are not allowed.

To be consistent, if we are not putting spaces between examples, we should remove these here too.

Perhaps we can use - instead of - ?

I think this should be indented to the 2nd level, if you compare with examples from the other commands.

Image should be indented to be aligned with the start of the text of its corresponding text block above.

Same for this image; identation issues.

Maybe we can bold "may not use multiple attributes"? So that it looks better. Just my opinion

The link for the Return to Table of Contents is somehow indented, when it should be on the outermost indent level. Can you see if you can resolve it?

Also same for the find command examples, we can remove the >br> tags if we do not want to leave lines beween bullet points without images.

This yellow looks a bit pale. Is there a darker shade of yellow we can use?

Should we have a tutorial on how to launch the terminal applications in the current directory? In the event that someone is not tech-savvy, but uses the lock functionality such that they are forced to unlock the application through the terminal.

Might be good if the inputs and the mapped commands are in code markdown, rather in quotes.

I was thinking that it would be better to link to the User Guide itself. Perhaps I should change the description of the URL. Or would it be better to directly link to Quick Start?

Great suggestion! Thanks!

I was thinking if I name it getPolicyUrl, another developer might mistake it to return a String rather than an Optional. What do you think?

Good point. I've changed it!

Good point, I didn't notice that.

Each new line is meant to separate the logic from the other lines, so that each "section" gives me 1 variable/object that I would eventually pass into the assert function. I felt that it looks cleaner that way. What do you think?

Okay, thank you!

How should we define it actually? I was thinking the same thing, but couldn't think of how to define it properly.

Okay, changed!

Okay, I changed the positive integer line to the following:

The index must be more than 1, and less than or equal to the index of the last item in the displayed list.

Is this clearer?

Okay, added!

Okay, added.

Hmm okay, I think I will be adding a section to talk about the fields that can be added for each contact.

Thanks for spotting this!

Can you clarify what you mean by this?

Okay yes, thanks!

FLAG uses the identifier of each attribute to help the program identify which attribute you are referring to.
For more information about the identifiers for each attribute, refer to What information can we store for each client contact?.

Added the above 2 statements, hope they make things clearer.

Okay, I've added the below 2 statements for clarity:

The data file is stored in a zip file inside the data folder in the same folder.
If you previously set a lock for ClientBook, the zip folder can be unzipped with that same password.

This is a default constructor in the CommandResult class and is not related to the BatchCommand. Perhaps we can suggest to remove it/add a new constructor in the next iteration?

Good idea. I've edited to include this change.

I searched online what the coding standard should be, and it seems like I should have commented to say that this is a fallthrough case. I've provided the link here if you want to take a look. https://www.oracle.com/java/technologies/javase/codeconventions-statements.html

Updated! Thanks for the catch.

I will be doing the test for the new command in the next iteration.

Finished documentation too, so shall do a proper full PR.

Looks good for this week! Except some images are not properly rendered on the website.

One more comment: for Insurance Policies, can we also add into the UG saying that they are uniquely identified by the PolicyID and PolicyURL pair? So this means that the user can enter 2 policies of the same ID, but link them to different documents.

This is currently being done in the code.

If you have any alternatives, do let me know so I can update the code accordingly.

I noticed in the code that duplicate input for tags are simply ignored. Perhaps in the UG we might want to add that duplicate/repeated input will be ignored for tags and policies? Since these two can accept multiple objects, as compared to repeated address/names/phone numbers, where we simply choose to take the last input.

How about "a client cannot own 2 policies with the same policy ID and URL."

Perhaps "... with the same policy ID and URL pair"?

Trailing white space

!aliasesOptional.isPresent() -> aliasesOptional.isEmpty()

Might want to follow the addressbook initialization


initialAddressBookData = addressBookOptional.orElseGet(SampleDataUtil::getSampleAddressBook);


initialAliasesData = aliasesOptional.orElseGet(SampleDataUtil::getSampleAliases);

Missing javadoc for aliases param

Should we document this unchecked exception?

!jsonAliases.isPresent() -> jsonAliases.isEmpty()

Return value of parseTagsExceptLast not being used and Javadoc missing. May want to consider returning void?

References found in:

AddCommandParser#L100
EditCommandParser#L129

Will need to add PREFIX_REMARKS from PR #77

Duplicate chunk found in AddCommandParser#L84-105, may want to refactor it out?

Can be replaced with positions.sort(Comparator.comparingInt(PrefixPosition::getStartPosition));

Can make aliases final

May want to make the happy path prominent: https://nus-cs2103-ay2021s2.github.io/website/se-book-adapted/chapters/codeQuality.html#make-the-happy-path-prominent


        if (helpWindow.isShowing()) {

            helpWindow.focus();

        } else {

            helpWindow.show();

        }

Sure!

Got it, maybe later on we can implement a sample alias in

Agree, https://nus-cs2103-ay2021s2.github.io/website/se-book-adapted/chapters/codeQuality.html#avoid-magic-numbers

Should be LogsCenter.getLogger(getClass());

input is not used

Should this test be ensuring that all items in the list starts with 'a' rather than just index 0?

Might want to test to make sure that empty spaces returns an empty list:

[null, ""]: non empty list

[" ", " ", " "]: white spaces return empty list (is this the intended behaviour?)

["e", "ex", ...]: non empty list

I've also realised that the method getAutocompleteCommands in Logic.java isn't documented.

Slight typo here. Other than that, LGTM.

Why is there empty line here?

Any reason why you decided to keep a List and Map instead of converting the map to List?

Might want to use CommandTestUtil.PREAMBLE_WHITESPACE

e.g.


assertParseSuccess(parser, PREFIX_NAME + PREAMBLE_WHITESPACE + "Alice"+ PREAMBLE_WHITESPACE + "Bob", expectedNameFindCommand);

Might want to use CommandTestUtil.PREAMBLE_WHITESPACE

Unused variable

@Test tag formatting

Hmm using .equals would mean that ["first", "second"] would not be equals to ["second", "first"]. Is this an intended feature?

Maybe using .containsAll would be more appropriate in this case

Why is job title removed?

Needs a \n behind

Might want to use the unicode char: … (U+2026)

Better to use containsAll. See https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/129/commits/bb6c1b9119e98e5f757b1811b8712731482ac534 with corresponding tests https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/129/commits/3c0d56828bffbc1b266fe65ee53a1f3585137632

Missing \n behind

Unicode ellipsis?

Might want to add a simple test taking clear as an example


    @Test

    public void parseCommand_clear() throws Exception {

        assertTrue(parser.parseCommand(ClearCommand.COMMAND_WORD, emptyAliases) instanceof ClearCommand);

        assertTrue(parser.parseCommand(

                ClearCommand.COMMAND_WORD + " 3", emptyAliases) instanceof ClearCommand);

    }

Hmm would using streams be better here? (Tag -> String -> Collections.join) Is there a reason why builder is used (for performance?)

Might want to check different Set<> equals here. Example:


        // different indexes -&gt; not equals

        assertNotEquals(DeleteCommand

                        .buildDeleteIndexCommand(Collections.singletonList(INDEX_FIRST_PERSON)),

                DeleteCommand.buildDeleteIndexCommand(VALID_INDEXES));

Might want to check different Set<> equals here. Example:


        // different indexes -&gt; not equals

        assertNotEquals(DeleteCommand

                        .buildDeleteIndexCommand(Collections.singletonList(INDEX_FIRST_PERSON)),

                DeleteCommand.buildDeleteIndexCommand(VALID_INDEXES));

Possible code quality issue here, deep nesting: https://nus-cs2103-ay2021s2.github.io/website/se-book-adapted/chapters/codeQuality.html#avoid-complicated-expressions

While following the user guide for add followed by tab, I found out that auto complete only works if I have a space. Might need to highlight that in.

Does this mean that the results will not be sorted by similarity anymore? Meaning that the order in which find returns will be based on the original order of the list?

If that is the case, I don't think "dictionary order" would be applicable here since it means alphabetical order. Maybe not mentioning that the items will be sorted will be clearer?

It works even with the .md tho

I accidentally added this duplicate @ ce88d0f01172233e0097c0b35f3d39f32c7a4180

Ah yes, it should be true if it will be shown and false if it should be hidden.

What do you think of rephrasing it like this:


/**

 * Returns predicate that determines field control visibility.

 * @return predicate that returns true if prefix linked control should be shown

 */

Added more test cases @ 1e159f4e080ebf9107aa3e93e24bb7c8b32d70a2

This line should be checking for same object


    @Test

    public void test_predicateEqualsCheck_allEquals() {

         ...

         assertEquals(addressArgs, addressArgs);

         ...

https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/70/commits/1e159f4e080ebf9107aa3e93e24bb7c8b32d70a2#diff-0d3609fd2c6dc142dc264b379879b18ceb04ec5efcd9e1ba87f410b4070f4b4aR47

I think it should be in this format. See: https://developers.google.com/style/code-syntax

Maybe I'll update it to { shown | selected| INDEX ... } what do you think?

I think it should be in this format. See: https://developers.google.com/style/code-syntax

Maybe I'll update it to { shown | selected| INDEX ... } what do you think?

I think [-t TAG]... means you can have multiple tag flags while [-t TAG...] will mean you can have only one tag flag but multiple "arguments" after that.

Updated in latest commit. Do check it out.

For this, there is an image indicating that it is highlighted. Do you want it to be listed here?

Updated in latest commit. Do check it out.

Updated in the latest commits

LGTM, but perhaps might want to rename PR to something more appropriate. See #52

Git Commit Name Convention

We will stick to conventional commit style, but we will capitalize the first letter after the colon.

Recommended examples:

docs: Update readme.md
docs: Update README.md

The general consensus is that if it conveys what this commit does, it's fine.

Git Branch Naming

Naming of the branch doesn't really matter as long as it makes sense.

https://se-education.org/guides/conventions/git.html

If a branch is related to an issue, it is recommended to use the format {issue number}-some-keywords-from-the-issue

Recommended examples:

docs/69-update-readme
feature/22-add-storage-backup

Pull Request Naming Convention

No specific PR naming convention, as long as it conveys information on what that PR does.

Can use conventional commit style or write your own short description.

Seems like the changes in PR #65 are working. I have closed the v1.1 milestone since there's no more issues related to it.

In ModelManager, should line 107

updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS); of

public void addPerson(Person person) method

be updated/removed to ensure the filter is persistent even after adding a person?

Other than this, everything else LGTM for Logic component.

This line should not affect the filter after adding a new person

I realised that the help text for add command does not include spaces between the flag and the value. I'm guessing the edit command will have this issue too

Sort order for list changed after doing a find command. Should list command show the original order?

@oeiyiping will you be updating the diagrams for your changes to Remarks?

https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/108

Seems like the config still doesn't work well. Might want to disable codecov/patch

JAR released: https://github.com/AY2021S2-CS2103T-T12-3/tp/releases/tag/v1.2.1

Fixed in https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/121

@justgnohUG are you taking this issue? Seems like it is related to #124

Since everyone has already updated their section of the DG for week 10, I'm closing this issue.

You can check your tP progress here: https://nus-cs2103-ay2021s2.github.io/dashboards/contents/tp-progress.html

Closing issue since it is implemented in PR #121

@darkdestry-t have you completed the assertions? https://nus-cs2103-ay2021s2.github.io/dashboards/contents/tp-progress.html

@tanboonji Fixed issue in commit f660e46, do check it out

Looks good overall, aside from the following matters:

1. Out-of-bounds index does not return any error message in ABB, and there is no other indication that the input index is invalid.

   Might be good to reference the error behaviour in `delete` command for consistency.

2. Some minor docs issues.

3. I feel that it would it be good to include a disclaimer in ABB itself and/or in the UG stating that the `email` command is only valid if the user has an OS mail app, and is logged into a valid account in said mail app. What do you think?

For point 3, I'm not exactly sure that is within our control? I've tried on Windows (logged in), macOS (logged in), Ubuntu (not logged in, Thunderbird installed) and on Ubuntu.

On Ubuntu, it will first open up the default browser (FireFox) and subsequently opening up Thunderbird, prompting me to login.

So I believe that on most OS, if the user is not logged in, the mail client will prompt the user. I feel that I don't have to document that down.

Closing since we are not implementing this

Just a suggestion, perhaps for future reference, would it be better to highlight the whole card as seen in the blue highlight of a Person Card?

PS: Interesting usage of JavaFX PseudoClass

I was thinking of doing that, however I feel that it may conflict (visually) with the active state. Maybe we could add in a new icon somewhere to indicate that selection status?

While testing @ commit 72cdf3e623021fb07025ad089c1f9dfd58f05bb7, I found some bugs

1: Is the find command supposed to be deleted in this scenario?

2: Does the autocomplete allow me to cycle through the flags?

Resolved in PR #119

Fixed in #129

Fixed in PR #140

May be related to #205

Am able to confirm that this issue only occurs on Outlook for Windows.

Clients that are able to handle comma separated emails are:

Mail for Windows 10

Mail for macOS

Outlook for macOS

Outlook for Windows will result in:

The current issue with Outlook for Windows is that is is reliant on semicolons as a list separator (source: https://stackoverflow.com/questions/12120190/what-is-the-best-separator-to-separate-multiple-emails). The only way around that is to manually enable "Commas can be used to separate multiple message recipients" in Outlook settings.

Fixed in PR #208

I found out that this was documented by removed by https://github.com/AY2021S2-CS2103T-T12-3/tp/commit/5b85d8d7c087364a4887be12dd705d4ad1566e09#diff-b50feaf9240709b6b02fb9584696b012c2a69feeba89e409952cc2f401f373fb

i agree with yi hsuen. But for final consensus, lets discuss in the meeting as there is no rush to do so

Yes I believe so

invalid? Since these are AddressBook tests and everything should be related to ModuleBook3.5 now

same issue? Maybe the pull from upstream wasnt done properly as the current master has no invalidPersonAddressBook and is invalidTaskModuleBook

testing for AB3, not ModuleBook3.5 😕

LGTM! but i agree with yi hsuen. should just be a small fix 😃

should be "returns a"

Just a small fix

Maybe can paraphrase to "sorts the list of tasks according to the deadline of the task. Tasks with deadlines approaching soon are displayed at the top while tasks with no deadlines are displayed at the bottom"

maybe next iterations we can avoid null but looks good for now!

good catch haha

maybe can save the condition in a boolean to make it clearer instead of having the comment? just a small suggestion

was gonna say the same but yes lets discuss

nice!

can we use enum? just a suggestion

just a small issue.. can be a bit ambiguous (name can be interpreted as name of task / name of module) so can be more specific. looks good otherwise

should follow the given format e.g. deleteTag 1 t/tagName

agreed

listOfModules (should be plural). Small issue though

idk if extra lines in between if blocks are adhering to 2103t standards.

not sure if its better to mention the return like this or use '@return' instead. Just a small issue

Looking at the other parse methods in the various commands like add, ArgumentMultiMap and tokenize is used instead of this way of split. Although valid, maybe for consistency sake can use that?

im not sure if trimming is necessary here as in ModuleBookParser's parse command, userInput.trim() is already called with the matcher. Good to double check there haha

Yes i agree with @QY-H00 here. Was going to mention that highly likely law of demeter is violated here. Although, if u think the violation is justified, its fine (according to prof, can justfiy for convenience sake at times). If not, i think its better to add a method in!

think there is too much method chaining going on so may be good to change this implementation? Up to u if you think otherwise.

I think the naming of the variables can be clearer here!

do you think javadocs required here? since they are public methods?

unecessary else block?

nice catch!

I see that u have an array of valid modules in ur ModuleManager class... I think it will be good if we specify the valid modules in the UG.. if not, it might be reported as a bug later on haha

referring to this in the comment above!

shouldn't each assignment be on the same line?

hmm correct me if im wrong, but youll be adding the raw workload of each task to the module? Maybe, as a better indicator for modules, we can calculate the proportion / fraction of the total workload for each module? I think that wll be a more useful number for the user? Maybe the rest can pitch in here too

maybe can remove this commented code out

nice haha

just a minor suggestion, to change 1,2,3 to low,medium, high for clearer communication through code

Minor suggestion: can use for-each loop instead but no biggie

nice use!

wah didnt know this existed haha

think would need to add tests in ModuleManager instead later for the removal of these later

looks good!

think need to change this java doc!

nice avoidance of using magic literals!

should we mention learning portal here? cuz that is like a subset of what moduleBook3.5 sets out to do?

are the numbers here intentionally changed to all 1's??

Should be 'Recurs the 1st task in ModuleBook3.5 every two weeks'..?

Should this be 'deadline is behind' instead? (or am i confusing myself haha)

good catch!

oh damn another nice catch HAHA

ok will do

done

Yes. I think there should be a notRecur command to remove the recurrence of the Task. I think i will work on that Monday after clearing other assignments haha

resolved

closed. Didn't run CI

Done. Waiting to merge in master DG after review

done

no changes for storage. LGTM!

Overall LGTM. Just added some comments pertaining to previous ongoing convos.

LGTM

Merged upstream repo into current repo for recurring-command:

Failing testcases (that have been commented out):

JsonSerializableModuleBookTest: toModelType_typicalTasksFile_success()
StorageManagerTest: moduleBookReadSave()
JsonModuleBookStorageTest: readAndSaveModuleBook_allInOrder_success()

hmm i definitely agree with you that we shouldnt stay in the middle.

When implementing the recur command, I thought it was a good to have a command on its own because:

Personally, i would have more 'one-time' tasks than recurring tasks if im using a a task manager. E.g. we would only have 1 assignment 1 in a module. So for recurring tasks, realistically speaking, it should be made into a command rather than just a normal field like 'workload' for example. This is also a justification we can give for the criticism on 'why does recur have to be a command on it's own' if we get it?
With regards to your 1st problem, I am not quite sure as to why the book will stop updating weekly? If a task is recurring weekly, it will refresh the deadline every week regardless, no? Might need some clarification there haha sorry
The second scenario is actually a v important consideration. One possible implementation can be when a user marks task as done, we can update the deadline (and remove starttime maybe), so that the user can see the next deadline already? what do you think? Another possible solution would be to maybe add a next deadline: field in the task card which is way simpler i think?

For the refresh command, i think it is a bit unsafe to add a new command with only a day left because I think quite a few changes would need to be made? and we only have (only a day at most) to implemement the feature? I am scared that it will be too tight for v1.3 deadline?

Overall, I am still fine with either though cuz for me, both ways work fine and (i think) either way can be justified hahaha

looks good!

LGTM

resolved in previous issue. solved by @QY-H00

linked to refresh command?

think its been caused here:

the checkArgument in the constructor of the Tag

@yhtMinceraft1010X @QY-H00 @figo2127 what do u guys think?

ok thanks @yhtMinceraft1010X 👍🏼

linked to #136

LGTM, but I think the AddCommand still has commented out code.

roger that. Will remove in next commit!

[resolved]

refresh command

invalid

Do we keep this? Remarks isn't in our milestone but I suppose we could

Should this also be parseStudentCommand?

getAddStudentCommand

also just curious what is k

Should we use the studentIndex-Session index here too?

Actually there's no use of this toString() method currently, right

Add session to sth?

I guess also do the folder with your name

Coming up, will have to edit this to serve Recurring Sessions as well.

TODO for me

Im understanding that getPrev3 month is getMonth applied to every student, and for 3 months. I guess it'd be considered less "repeated code" if this method was built on getMonth. possibly using getMonth's methods from within getPrev3?

Might be consistent with the other commands if not capitalised. eg "past_fees" / "3_fees" / "3_month_fees"

"Shows the totalled fees per month, for the past 3 months." Or something of the sort could be somewhat more accurate.

super neat, hadn't thought of putting it at model!

MIght be good to mention somewhere its 1-to-1 only

1.imo shld mention 1-to-1 here.

2.provide" -> "get"/"receive"/"retrieve"

either quick or at a glance, not both. or simply use the word" reminders for upcoming sessions" or sth. may be hard to understand what 'quick overview of scheduled tuition sessions at a glance' means

The link here not working on mine

As with the following displayed session list

This looks like the same thing to me as onSessionDate (but without the assert), with different input.

Perhaps rename both methods to reflect this difference in input, or just let them be overloaded methods

And for the former, call onSessionDate(new SessionDate()) from within

I like you use the word build better than just 'on'

Long method. You may want to change filterOneWeekTuitionSession to 3DaysTuitionSession and use the former implementation if that shortens the method.

yeah im suggesting you overload the method to allow localDate input

i.e.

rename onSessionDate(SessionDate sd) method to buildSessionOnDate(SessionDate sd)
make a

public Session buildSessionOnDate(LocalDate date) {

SessionDate sessionDate = new SessionDate ......

return buildSessionOnDate(sessionDate);

}

but i guess not exactly necessary

calling recurringInterval.getValue and all the check logic is a bit breaking some rule/principle i believe. student shouldnt have to deal with it. maybe bring component of this method to some new method in RecurringSession.

i guess like

list.set(this.shortenToBefore(date), index)

list.add(this.shortenToAfter(date)) --> can utilise firstSessionAfter from within

with may be better than change since immutable. but this is debatable

try

daysBetween = 8,

interval1 = 3 and interval2 =7 and vice versa.

They should both be true, but this gives false in former case

gcd(interval1, interval2) | daysBetween >--> there will be an overlap at some point

this is because ( i think) there exists some overlap if n only if

daysBetween + (interval1 x n) = interval2 x m

The diophantine equation ax+by=c, has solutions if and only if gcd(a,b)|c.

gcd(interva1, interval2) | daysBetween, means daysBetween is divisible by gcd(i1, i2)

So i think this should make sense :

 public boolean isOverlapping(RecurringSession otherSession) {

    if (startAfter(otherSession.getSessionDate())) {

        return otherSession.isOverlapping(this);

    }

    int daysBetween = getSessionDate.daysTo(otherSession.getSessionDate);

    

    if (daysBetween % gcd(interval1, interval2) !=0) {

        return false;

    }

... followed by time check

EH We actually can get the smallest postive n or m i think

why's there a otherSessionEndDate for single-session? Doesn't a class start and end on the same date

daysFromThisSessionStart

daysFromOtherSessionStart

keep consistent to param name possibly

BUG! must be && we keep doing while both conditions are true.

if any one condition false, we get out of while loop

Nonsense i said

we put this outside the method, at the top of the class?

to use in every other method for test

Yea I think like failure cases and all that

Improves coverage to do that right i hope

oh right! so i guess it has to stay as it is rn

Should receive/would receive.

"Would have received" may wrongly suggest to reader that only past sessions would be included in fee calculation

my finance better

an error

i think similar accross

Ah yes i agree probably highlight

comment should explain what sessionIndex is

agree with enhao. possibly can abstract out this else clause

add test for this method

thanks for making all single recurring change to session too!

can use existing methods like buildSessionOn() instead of new Session ....

ooh sorry yeah let me just undo the change i simply refactored

omg yes sry thanks for pointing out

No it's not intended because I didn't (and kind of currently dont) know what problems this may cause.

Not intended as in never questioned it

What problems might this cause/ what recommended way might there be?

Was thinking since its extending Session, the parent's method to access Sesssion contents are inherited

no idea myself leemme delete

right!

yep!

Yep thanks. actualy given your comments I think there was also no need for this to be a static method.

Will replace with a .equalTime(SessionDate sessionDate)

yep will do this

Thanks, did in the coming commit

Right ive got to make a RecurringSession json. to save things into if Session instanceOf RecurringSession.

Just done so, I think should be working

Yeah ive pulled upstream. ChoonWei's method doesn't check for Recurring session so there arent clashes.

Yep will do as a seperate issue

Ok found it will fix

actually no idea

Issue is solved by adding type information in json, as necessary for deserialisation polymorphism.

Thanks have added this as a new separate issue

ok, in coming commit!

no it wasn't wrong. outputs correct either ways because isConsistentDatesAndInterval does the calculation as well.

That ensures days between (date 1, date 2) is >=0

but i guess its simpler (less computation) if use startSafter(sessionDate) and more consistent

ok will wait for that to merge first then

yeah the only difference is if it checks the date vs both date and time

Right totally forgot. Will do so in coming commit

No man trying to solve merge conflicts w copy and paste led to a disaster

Will do so in next commit. when plantUML comes alive

I'll just leave it in there n not use the png

i edited their architecture seqeunce diagram and overriden it so its deleted

nvm not gonna do so now

yes i have

can use it one day in the components perhaps

i think i actually screwed up with my master branch at some point, so will just redo/copy paste over the relevant changes when I manage to pull from our shared master.

Actually you've made all these changes alr right.

Like the images you show under Logic component. will just delete these changes here

Good catch, I tried on the master branch this seems to be a problem from there

I don't mean readme. i mean't the aboutUs page

There seem to be missing the switch case for delete_session in AddressBookParser.java, which makes the command inexecutable.

I added the switch case myself locally and tried to execute the command when the student has no sessions, seems to throw an exception, IndexOutOfBoundsException, which was out of the application. Maybe you could test it and let me know if you face the same issue too?

Other than the above, the rest looks good! thanks!

I think I've fixed it.

Still have issues with building TypicalStudent with StudentBuilder.addSession(). Which is why testCases are commented out.But this at the moment is another matter.

Would it be better to integrate the Session class diagram in the Model component? I think it would add more value there instead of being a standalone. (We can show the association with the Student class there)

Also, would it be better to make each feature distinct instead of combining it into "Session" feature to preserve the current formatting?

You are probably right about the Model component; it would be good to be together with Student. I think i'd take SessionClassDiagram out of the DG for now.

About the feature:

I did this because creation then a deletion does not each sound like a different feature (if feature is the word used) rather only difference in the command, which may not even need 2 seq diagrams like there already is, i felt. we shld discuss

@yungweezy not an issue cos The newly trying to add session should occurs on fridays, it indeed is overlapping. But we can edit ug to specify it’s any overlap, across students as well

anyways

I think if we change implementation to the specific overlap version (in pr from me) can error message when the overlap will first be

I don’t think should cap the tuition fee

Will ask hi how he did it

LGTM. Although I think u bundled up the entire session command to be a section itself. Student we might not be able to do that, given that we have abit too much command for the student feature already.

Ive reverted to all that was originally in junwei's so unbundled it

Remember to change the prefix to what we discussed

addTask title -d description

Just want to check if there is a need for this class or can we store the description as a String within the Task?

Same question as Description Class. Should we store it as a String instead?

Are we supposed to update the person list?

Also might need to change the comment here, other than this small issue can merge

Should this variable should be renamed to MESSAGE_INVALID_PERSON_DISPLAYED_NAME?

Lets standardise the naming to be XXXMemberCommand to make fixing easier

Think we can rename this file to DeleteMemberCommandTest to standardise the file naming

I think we should make a Util file for the names and import them instead of hardcoding the value here. This makes it easier for maintaining. For example, the TypicalPersons java class in the testutil directory is an example of what I mean

Same issue about hardcoding values

I thought names should not have prefix?

Should we follow the format of the actual phone number -p 95652233 (with spacing)

I think we should follow our prefix convention using -. For e.g. -a

I think this should be changed to invalid name, try including some alphabets mixed with numbers

I think you forgot to change this

I think you might be missing the task status for the Card

I think here we can return the created LocalDate?

Typo?

Nice refactoring!

Is this a variable name? If its not should we standard the comments of hey matez to Hey Matez? to HEY MATEz?

Same thing here, should we standardize according to our app name?

Same question here

I think you missed this folder. But can merge after changing

typo lol

Here too

should be hey matez not address book

Shouldn't this be HeyMatez?

Should be UndoTaskCommandParser

Should be LogicManager

I don't think Model is needed here if you import it

Same here

Same here for Messages

Same here

If we need to we should import the Predicate directly

Same here, we should import Messages.MESSAGE_INVALID_COMMAND_FORMAT

Same here

Same for this file

Should be Find instead of finds? Same for displays?

I think @code refers to the class? Not sure about this

Typo?

did we limit it to just alphabets?

Close PR due to extra commits

PR Merged. Modifed and Reused Person class. PR #65

Just have 1 small thing to check on, which is the updating of updatedPersonList when we are updating tasks. The rest LGTM

Add task status to edit of task
Updated UG
Add space behind prefixes to enforce spacing

Update UG and Javadocs
Update jar filename and log filename

No longer implementing feature

Renamed addressbook.json to heymatez.json

Not implementing

Tag Class converted to Assignee Class

Settled by Tasha

Not for merging. For Task Grading Only

Duplicate with # 206

Not an issue

Missing the in front of task index

Will only put for some

State in UG for allowance of number (allowing of nicknames). Phone number bug overlap with # 203

To state in UG that certain command such as edit / delete only applies to current displayed list

Related to # 225

State naming criteria in UG

Listed in our UG "For features which use the INDEX field, the INDEX you specify must be a valid number displayed on the list of tasks.". Can consider ignoring @rachelljt

Update UG to make it clear. Delete only on filteredList to prevent accidental delete without user realizing

Fixed after changing prefixes

Change result message to no tasks found. Only findTasksFor on full name match

Check and update Introduction
Check and update Feature List
Check and update Quick Start
Check and update Features command Format
Check and update Feature Instructions
Check and update Data Storage
Check and update FAQ
Check and update Command Summary
Include screenshots

Check and update diagrams for Architecture Design
Check and update UML Diagrams (There is some update to original AB3 UML)
Check and Updating of User Stories
Check and Updating of Use Cases
Check and Updating of NFRs
Check and Updating of Glossary
Check and including Code Snippets (If required)

should be [-t TAG...]

same here, should be [-t TAG...]

and im not sure whats that special char. but if its intentional then no problem!

Cancel, not a typo

For the ... , are multiple tags searches allowed? Doesnt seem to be allowed atm

rename to sortPersonList since not the filtered list being sorted

suggestion:

This one our userguide currently is "tags" too but would "tag" be better?


    public static final String MESSAGE_USAGE = COMMAND_WORD + ": Lists all tags and the count of persons tagged in the Hippocampus. "

Prefer like that haha but this one up to you


        model.getAddressBook()

                .getPersonList()

                .forEach(p -&gt; p.getTags()

                        .forEach(t -&gt; tags.compute(t, (k, v) -&gt; v == null ? 1 : v + 1)));


        boolean noNameAndTag = noName && noTag;

want to use .contains for search tag too?

just to standardise with other parser classes if you want haha


        ArgumentMultimap argMultimap = ArgumentTokenizer.tokenize(args, PREFIX_FIND);

        

        Optional<String> keyword = argMultimap.getValue(PREFIX_FIND);

        

        if (keyword.isEmpty() && argMultimap.getPreamble().isEmpty()) {

            return new TagsCommand(tag -&gt; true);

        }

Add new line


            + "person tagged in Hippocampus.\n"

Swap error message


            } catch (DateTimeException err) { // date in wrong format

                throw new IllegalValueException((Birthday.MESSAGE_CONSTRAINTS));

            } catch (IllegalArgumentException err) { // birthday year exceeds current year

                throw new IllegalValueException(Birthday.MESSAGE_YEAR_CONSTRAINTS);

IllegalValueException was correct haha

IllegalValueException is the one caught by storage. Or else an invalid date in the save file will not be handled and program will terminate


                throw new IllegalValueException(Birthday.MESSAGE_CONSTRAINTS);

I think she was following the wording of constraint for address field. Do yall think it would be good to change that too? or we can leave both too

I believe the == check here was intentional cos it is checking the exact object (the static string).

Otherwise LGTM

For marking event as done (in the event branch)

I simply used list.contains() since that uses .equals() to check.

May be slightly less efficient time complexity wise, but could be more readable. Which do yall prefer?

If prefer this then LGTM, i can update the other


    private DeleteContactCommand createDeleteContactCommand(String args) throws ParseException {

        String[] strIndexes = args.split("\\s+");

        List<Index> indexes = new ArrayList<>();



        for (String s : strIndexes) {

            Index index = ParserUtil.parseIndex(s);

            if (!indexes.contains(index)) {

                indexes.add(index);

            }

        }



        return new DeleteContactCommand(indexes);

Here can just leave it as DATE.

Since to the user, event date is basically a date (unlike birthday where they are extra restriction).

Or if decide to keep, put it as one word EVENTDATE, or else it seems like 2 arguments


            + "[" + PREFIX_DATE + " DATE] "

Might have missed out this? Not sure if it affects other stuff, but after i changed it looked better haha


.list-view {

    -fx-background-insets: 0;

    -fx-padding: 0;

    -fx-background-color: derive(rgb(243, 229, 231), -10%);

    -fx-border-color: white;

    -fx-border-width: 1;

}

Alternative to probably make it simpler and slightly more efficient


    private void checkIfHasTags(Person personToCheck) {

        Set<Tag> personTags = personToCheck.getTags();



        for (Tag targetTag : targetTags) {

            if (personTags.contains(targetTag)) {

                editedPersons.add(personToCheck);

                return;

            }

        }

    }


Toggles between Dark and Pastel theme


     * Constructs a {@code GuiSettings} with the default height, width, position, and theme.


     * Constructs a {@code GuiSettings} with the specified height, width, position, and theme


    public static final String MESSAGE_USAGE = COMMAND_WORD + ": Toggles PartyPlanet's theme between Dark and Pastel.";


            commandResult = new CommandResult(String.format(MESSAGE_SUCCESS, "Pastel"), false, Theme.PASTEL);

Optional: can be private?


    private void setThemePastel() {

Optional: can be private?


    private void setThemeDark() {

Missed out in initial suggestions


 * Toggles the theme of PartyPlanet between Dark and Pastel.

This makes sort_upcoming unable to work with asc/desc.

Isit intented? If so then just remember to document

Same for list

Make sense! just making sure it isnt an oversight

This makes sort_upcoming unable to work with asc/desc.

Isit intented? If so then just remember to document

Same for list

Oops comment was meant for PR 180, shifted over

Suggestion to use setOnKeyReleased then no need use a generic event handler.

Also to combine duplicated event handlers


        commandTextField.setOnKeyReleased(e -&gt; handleUndoRedo(e));

        history = new InputHistory();

    }



    /**

     * Handles key combination releases.

     * Exceutes undo command if CTRL + Z shortcut is used

     * Exceutes redo command if CTRL + SHIFT + Z or CTRL + R shortcut is used

     */

    private void handleUndoRedo(KeyEvent event) {

        if (undo.match(event)) {

            try {

                commandExecutor.execute("undo");

            } catch (CommandException | ParseException e) {

                setStyleToIndicateCommandFailure();

            }

        } else if (redo1.match(event) || redo2.match(event)) {

            try {

                commandExecutor.execute("redo");

            } catch (CommandException | ParseException e) {

                setStyleToIndicateCommandFailure();

            }

        }

    }


        if (orderType.isEmpty() || comparator == SORT_EVENTDATE_UPCOMING) {

            if (!stringSort.isEmpty() && comparator != SORT_EVENTDATE_UPCOMING) {

                stringSort += "in ascending order. ";

            }

            return comparator; // default


        if (orderType.isEmpty() || comparator == SORT_BIRTHDAY_UPCOMING) {

            if (!stringSort.isEmpty() && comparator != SORT_BIRTHDAY_UPCOMING) {

                stringSort += "in ascending order. ";

            }

            return comparator; // default


   * To retrieve existing values, use the autocompletion workflow specified [below](#autocomplete-tab).


                stringFind += "\n\u2022 Requires exact event remark: " + String.join(", ", allRemarks);


                stringFind += "\n\u2022 Requires partial event remark: " + String.join(", ", allRemarks);

Note that _ is part of \w and thus allowed too

The static block here seems unnecessary. I get that is following the format of the lines above. Perhaps can refactor that too


    public static final EEditCommand.EditEventDescriptor DESC_CNY = new EditEventDescriptorBuilder()

            .withName(VALID_NAME_CNY)

            .withDate(VALID_DATE_CNY)

            .withRemark(VALID_REMARK_CNY)

            .build();

    public static final EEditCommand.EditEventDescriptor DESC_EASTER = new EditEventDescriptorBuilder()

            .withName(VALID_NAME_EASTER)

            .withDate(VALID_DATE_EASTER)

            .withRemark(VALID_REMARK_EASTER)

            .build();

To avoid "magic numbers"


        expectedModel.setEvent(model.getFilteredEventList().get(INDEX_FIRST_EVENT.getZeroBased()), editedEvent);

Same as above


        expectedModel.setEvent(model.getFilteredEventList().get(INDEX_FIRST_EVENT.getZeroBased()), editedEvent);

Maybe is just the phrasing confusing. So in the latest commit I phrased the main info as

If provided with tags
- Delete every person who is tagged with the specified tag.
- If the person is tagged with another tag, only the specified tag will be removed. The contact will not be deleted.

Then for these examples, I left it as

delete -t colleague -t cs2103 deletes contacts with tag "colleague" and contacts with tag "cs2103"

Cos the happy path is to delete the contact. Then ONLY IF it is tagged with another tag then the contact is not deleted.

Did not change, discussion is below

Edited but phrased a little differently, check latest commit


    public static final String MESSAGE_DELETE_PERSON_SUCCESS = "Deleted the following persons: %1$s";

Yup makes sense!

Edited, info in comment below

Could not find a simple way to make tags the outer loop for containAllTags().

So kept persons as the outer loop for both All and Any, for readability.

However, made use of TagsContainsExactTagPredicate as suggested for better abstraction (demeter law)

LGTM

Also update userguide to include this command

Yup I considered this but thought it was too inefficient to scan through all whole list to see if all tags specified exists.

Perhaps I can add some kind of static set in Tags to keep track of all tags that currently exists

I implemented a similar feature in my IP so I can probably PR later and see if yall like it

Actually, since year not really important for a birthday, maybe we can store it in a MonthDay object instead. Then no need request year input at all.

Perhaps can also change display of bday in a form of "11 Dec 99" instead of the current 1999-12-11.

Alternatively, idea to put the logo as a background. Altho tbh I dont have much idea how to do it haha

Added a min height so for aesthetic purposes

Is partial search not going to be the default?

Yup that might be better. Since we implemented partial in the first place cos it would be more commonly used.

Even if decide to keep it as exact by default, i think would be good to minimally make it non case-sensitive.

I think we agreed that memory not really a concern atm since undo history doesnt carry over across sessions.

But i think no harm adding later on!

Yea I dont mind. I feel like even ~10-15 undo is probably more than enough.

But i think wait til event branch is integrated with the history too

Throwing error is one way, and the ~easy way out~ other way would be to simply document this _behavior feature (i.e. only the last sort prefix given is used), just like for the add command. Which do you prefer?

"If a parameter is expected only once in the command, but you specified it multiple times, only the last occurrence of the parameter will be taken.

e.g. if you specify -p 12341234 -p 56785678, only -p 56785678 will be taken"

Yup our UG already states this case. So alls good!

Implemented --exact and --any as suggested above

delete -t a -t b deletes any contact that has tag a or b

delete --any -t a -t b same as no flag

delete --exact -t a -t b only delete contact with BOTH tag a and b

Currently contains bug stated in #162 . Will follow the solution of list

closed as branched out from wrong branch

Split checkToBeDeleted() into

containsExactTags() when --exact flag used
containsAnyTags() otherwise.

Methods above no longer modifiesdeletedPersons list. Addition to deletePersons carried out in execute()

not a bug

Final functionality as follows

Before: delete -t TAG [-t TAG] was "delete all contact with specified tag, unless they have other tags"

Now: delete -t TAG [-t TAG] delete contacts (in filtered list) that has the provided tag

delete -t a -t b deletes anyone who has both tag a AND tag b, and display persons deleted

If no one deleted, return message These tags do not exist in persons listed. No person removed.

Flag --any

If this flag is specified,

delete --any -t a -t b deletes anyone who has EITHER tag a OR tag b, and display persons deleted

If no one deleted, return message These combination of tags do not exist in persons listed. No person removed.

Tested, works well. Note the cosmetic issue:

Latest commit throws error for this issue, updated PR message above

Perhaps we can do this one-shot during our upcoming meeting.

sounds good!

Optional for @pyuxiang Can update DATE and BIRTHDAY with all valid formats (since we allow many different ones)

Rephrase message slighty

"All requirements above met." -> "Results meet all requirements above."

"At least one requirements above met" -> "Results meet at least one requirements above."

To also check output of tags list, when list command is invoked.

@pyuxiang , for list tags will not be case-sensitive right?

Only enforcing for delete -t and edit --remove to avoid unintended deletion.

However, for list still case-insensitive for convenience of searches

Duplicate of #240

Rephrased error message as suggested by @pyuxiang

The same behavior persists for add and eadd as well, are we fixing those?

@pyuxiang Unfortunately for those commands i think is inevitable. Cos wouldnt make sense to not show the contact that u just added.

unless, one way could be to retrieve the predicate and .or() the added user?

Maybe create an issue if we decide that this is a bug

Im not really sure for the full range of accepted domain types. But some suggestions.

For smtp.google.com., is ending with a . valid? if not can domain regex to "[\\w-]+(\\.[\\w-]+)*$"

Enforces that . must be surrounded with one or more \w

a.b.c allowed

a.b.c., .a.b.c rejected

For false positive - . isit cos - need to be surrounded by letters, if so can "((\\w+(-\\w+)*)+\\.?)+$"

This enforces that - need be surrounded by \w. basically using same idea as above

a-b.com allowed

a-.com, -a.com not allowed

If combine both condition above, "(\\w+(-\\w+)*)+(\\.(\\w+(-\\w+)*)+)*$"

The new message is clearer, though do we want to standardise with the other invalid index message? eg. 0 and 20 are both "invalid indexes" but show different error messages. But both works lah

Technically not same case leh, cos 0 is not valid index (same case with -1, abc etc) but 20 is a valid index that is not in the addressbook.

Thats why 0 causes "index invalid" but 20 causes "person index provided is invalid"

But idk maybe can somehow make clearer haha

By specification if I recall correctly, just cannot start with hyphen. Also not too sure what the email address domain part includes a hostname (for the mail server) - if it's a pure domain name, then hyphens are not even allowed. Also dunno if a single period is allowed.

Essentially just playing very very safe here in case someone want to find fault with our validation. If we want, can add a [^\W_] right after the @ to enforce alphanumerics.

Makes sense. i think either "(\\w[\\w-]*\\.?)+$" or "([^\\W_][\\w-]*\\.?)+$" works. whichever u feel more readable. i didnt test tho haha

Edit: oh wait got diff. first one allow u to start label with _, second one doesnt. Use whichever is more appropriate

For this, i think the easiest fix is to just update the UG that a max value for INDEX is 2147483647

could change contacts to household items

I also think it should be changed back to VALID_NAME_AMY for now just for consistency.

Since this test is a returnsFalse, maybe you shouldn't include an assertTrue inside. Perhaps you could write that in a separate method?

Maybe warning can be in all caps?

U could try using assert throw like in the test right below this. U could also specify what the Exception you are throwing actually is.

Could add some tests since you removed these 😃

I think u can use the above two lines to print the number of items listed. One has the s in items while the other doesn't to differentiate between single and multiple items being returned.

maybe you could say within the next 7 days instead of in 7 days.

similar to the previous one, maybe you could say expiring within the next 2 weeks

u could try using equalsIgnoreCase() like I did for sortCommand

I feel it should be StoreMando since we referring to our app.

The table still displays fine right??

Should these be like UniqueItemList instead of UniquePersonList? Maybe can change this in the future.

I think we can just delete this file also right? If not, can just remove the Level 3

What does this look like?

I think can change this back.

Can just delete the test. Don't need to comment it out

"User wants to search" or "User searches" maybe? Instead of saying expiring soon, can say expiring within the next 7 days or next 2 weeks?

should be 3a right?

same for this

it should be 1b for this i think

can change this back to location? thx!

if user keys in command "clear", will he get the message "All items in the specified location (if any) are cleared"? Personally, i feel like it should say "Inventory has been cleared".

i think this won't work if item location is like "Kums room" and the command is "clear Kums room". Maybe you can try it out and see if it works.

the item location has a lot of white spaces in between Kums and room.

Should a test be added for this?

can add same expiry date also just to make it clearer.

Maybe you could remove it if there's nothing to include

I think keep it generic as list feature should be fine.

Since you have the sequence diagram here already, you shouldn't have it on top as well like Jay mentioned.

list got no index right? i think should say validity of the user input.

same as before i dont think its validity of index.

Perhaps it could be phrased as "If the device is connected to the Internet, StoreMando will automatically open the User Guide in a new browser."

I think we can suggest to double click then if it doesn't work, user can alternatively open their terminal in the directory where the jar file is and enter the command java >jar file name>-jar

I think you can remove this header. There's another one at line 1001

ohh okok then follow the recommendation

i think itll clearer to say for example, "at least 7 days" instead of "for 7 days".

for this I feel you should use within instead of in

Maybe could use chronological order instead.

Maybe you could consider just having this variable declared in the individual subclasses of the SortCommand as they're each used by only one of the subclasses.

I feel like this overlaps with line 656. Maybe can consider removing it?

I can't comment above but perhaps you should do this for add and edit too for the quantity limit if you are doing it for reminder.

I felt like the VALIDATION_REGEX does not help to check if the date given by the user is a valid date. So, I used LocalDate instead to check if the date is valid, which can be seen in the subsequent lines. Hope this clears things.

I will add it back. expiryDate will not be null anymore.

I chose to do it this way as I cannot guarantee Long.parseLong(test) will not throw a NumberFormatException. So, I made sure test is made of digits before I check if it is a non-zero value.

Ok. Changed as stated.

alright!

ohh ok i get it. I'll change it. Thanks!

Oh yea I'll remove it! Thanks!

alright will change it!

oh yea my bad

sure will do!

ok will change it

if I'm not wrong, it only takes in days and weeks as TIME_UNIT. I just went to check the reminderCommandParser. I think we can leave it as it is now and change later if we make changes to the feature.

alright will do so!

ok!

yes it will still work

alright will do so!

ok will make the changes

ok changed it!

they will all appear in the same line so I don't think it matters

yes i changed it. thx!

ok! I've made the changes

Slight change in phrasing:


    * The user should take no longer than 1 hour to learn the different functionalities of TutorBuddy from the user guide.

Maybe can change it to like that to be more specific?


    * A user with above-average typing speed for regular English text (i.e. not code, not system admin commands) should be able to use most of the functionality in TutorBuddy faster using commands than using the mouse.

We do not actually need this file. It is from the tutorial for tP from week 6. I don't even know why this is here. But I guess the change is harmless.

Actually, I was thinking more on the lines of public Tuition(Student student).

I think passing all parameters of student will make the abstraction level of Tuition class 1 level too low.

How about

'Student student = new Student(name, phone, email, address, studyLevel, guardianPhone, relationship);

Tuition tuition = new Tuition(student);'

Should we name this DeleteStudentTuitionCommand for more consistency?

Similar to the AddStudentTuitionCommand, we are operating on a tuition object here and not a student object.

Instead of returning a new Tuition object when we call edit_student, what about returning a student and replacing the student in the Tuition object?

Because the command name is EditStudentCommand which does not really make sense to return a new Tuition object.

I was thinking of tuition.getStudent().getName() but I guess this works well. This is just a design consideration but you can check out "Law of Demeter".

TuitionTest replaces StudentTest. What tests should we have here now?

What is this hashCode() function for?

I think the javadoc comment here should change?

Woops, I was using my iPad to review just now, and I might not have seen the code accurately. No issues!

Oh ok, let's leave it then!

Do you mind explaining the listener part and what the change.next() does? I a bit catch no ball 😅 .

Also, which is the part that calls the view to update the session list every time a session is added?

Good suggestion! The isValidSessionDate() should assertFalse correctly to this test case.

Since we have the isValidSessionDate() check now, we do not need this try and catch block anymore since it is a guarantee that we will receive a valid dateValue and timeValue in our SessionDate constructor.

There are a few changes to other files regarding this issue as well. I will do the changes once this PR is merged.

Is this method needed?

Can we use the showStudentAtIndex method for our session command test cases or do we need to find the exact session in the session list?

Ok! 😄

Should this be AddressBookParser instead?

Hmm, since you mentioned that the AddStudentCommandParser creates both a Student and a AddStudentCommand, would it be better to also mention that the AddStudentCommand executes with the Student object?

Should be "Clears all entries in the program: clear"

Is the "Tip:" meant to be bolded?

or is this the intended outcome:

ohhh ok nice

Sounds good. I'll change it on my end.

Here the command should be add_recurring_session?

Maybe can add a javadoc comment for a description of the CalendarCard class?

Same as above, missing javadoc comments

Did you forget to remove this? 😄

I think can do what Samuel did and abstract this out to an addListener() method.

I think it makes it look neater. I will probably do this for my components as well.

Is the removal of t/TIME gonna be done by 1.3 or is it a 1.4 thing?

not too sure if this condition is needed since this is already checked in hasSession() method.

Same for the other boolean condition below.

maybe can explain that in the javadoc comment?

For line 127, should we put this between a >div markdown="block" class="alert alert-info">:information_source:>/div>?

What do you think of rephrasing it to "Calculates and displays" ?

Feels to me that "retrieves" does not really explain it well enough here?

On line 249,

"Filters the student and session list to only include student(s), and their respective session(s) whose student name contains any of the given keywords."

Is this part an err? Doesn't seem to describe the GetMonthlyFeeCommand.

What do you think about combining 2 and 3. I feel like they are the same since check whether the user exists is part of the input validation?

If so, then 2a and 3a below can also be combined to just

2a. TutorBuddy detects and error in the input.

2a1. TutorBuddy displays an error message to the user.

Use case ends.

How about:

TutorBuddy is populated with sample data.

Would adding "and a link to our user guide" be good here? Or is it too much information?

If you agree with this then maybe can standardise to other use cases as well also.

How about changing "see how well I am doing financially" to "manage my financials better"?

For line 407, How about changing it to:

As a potential user, I want to see the app populated with sample data on the first run so that I can try using the features easily

Thanks for the catch. I think I might have accidentally refactored all names without noticing. Please see the updated commit.

Ok, I will add 23:002 and 23:592. So to double confirm, 23:002 and 23:592 should throw a SessionException, right?

Yup, thanks for spotting that, it should be k.

@nowknowing it's the prefix for duration (can be seen in the CliSyntax class in the Parser package).

I chose "/k" because "/l" was already used for STUDY_LEVEL in add_student.

If y'all have a more intuitive prefix letter, do suggest!

I use the sessionDate.equals() here instead of session.equals() because I think you created an equals() for Session class already right? @samleewy

I guess i could improve it by bringing the targetSessioDate in the outer loop, since there isn't a need to declare the targetSessionDate in every iteration.

Ok, thanks for the suggestion. I will add some comments to the test cases to make it clearer. 👍

HAHA omg 🥴

Thanks for spotting, will make a change to this.

What do you think of making it like this?

Returns true if session {@code Session} exists in any of the students in the unique student list

I think this takes away the ambiguity of referring to either the session variable or the Session class.

Good point! Can you give an example of how you would phrase it? I'm not sure how best to change it.

Yup! I agree with what you said, idm changing to what you suggested instead. Personally, I think code clarity is more important than uniformity in this case.

Thanks, good catch!

Done!

Yup a lot of inconsistencies now. I was thinking of just quickly merging all the UG PRs then I will go through again to standardize.

Good suggestion, I will use that! 😄

I think we can just keep 'user' for now, and standardize it later once everyone merge? Because I think some parts of the document might have used 'user' also.

Got it, I will make the change. Thanks for spotting!

Can idm also!

ok!

Ok updated!

Yup it is hardcoded. No worries, I will be working on displaying this info immediately after this is merged since the recurring_session is also merged alr.

HAHA ya... T_T I tried damn long to make it go to the extreme right but I just couldn't do it. Maybe I'll create an issue for anyone who wants to try 😆

Kinda followed the original StudentCard from AB3.

I think we just keep it? 😅

Good point, ill add it in

nice catch!

Good catch!

hmmm because I put commas at the end that's why it's left like this.

or should i just remove the commas?

Added!

I decided to remove the commas and capitalize

ok!

I personally think it looks neater displaying all in one paragraph 😅

seems to work. ill refactor all to this format

i googled and it says both also can but "indexes" is a more English way while "indices" is a more latin way haha

actually right, i tried to use your onSessionDate() method but because I needed to pass SessionDate in as input, i found it very troublesome to use it. My this build method has the added benefit that it uses the time info of the recurring session, so i don't have to retrieve it, create a new SessionDate and then pass it into the onSessionDate() method.

Yes i'll try and clean this method up

ohh ok, that's a good idea! I will change it to this.

hmmm, but i'm kind of using these variables above as well.. if i create them in the method then I'll have to create them twice..

yes, the way I created is hardcoded to only show 3 days. If they change it, then the program will be buggy. I will add the assert statements thanks!

oh yes thanks for catching this. I think we should have it as START_DATE instead of just DATE

this large chunk of code here is to allow wrap text because TableView does not support wrapping at the parent level and I need to go down to the children

Are we adding more tests to DeleteSessionCommandTest?

hollup if we abstract this method and put it at the top of the class, then won't we be using the same edited addressbook for other test cases as well?

Sure!

Removed. I was actually intending to replace the github logo, but the github logo makes more sense in this case.

Add test cases for time 23:002 and 23:592 and both throws a SessionException as expected.

I also noticed all the commands that @enhao25 changed to name it as ____StudentCommand got reverted. Is it intentional?

So there will only be 1 TuitionCommand which is the AddTuitionCommand right? The rest like list, delete, find, etc are still StudentCommands?

I will add test cases for AddSessionCommandTest and AddSessionCommandIntegrationTest later today #61.

Should not cause any issues.

closes #49

Yeap LGTM. Just 1 small comments on adding comments to the equals method. Previously in the group, I think shion also mention that changing the session to store student instead of having student store session could be a possible idea. If we somehow decide to do that, not sure if some of the test case needs to be changed. However, at this point, it might not be time efficient to change, might need to discuss this future when we meet tmr, to see if there is a point in doing that. Else, looks good

I think regarding this, wouldn't it be better to just have these test cases now and modify them later if we were to introduce the functionality?

@samleewy I think the comments change and parse method name change, I'll create a new issue so that we can discuss. For now, maybe you can approve this first to fix the trim date bug?

I think having at "Fees" is fine.

LGTM, tried out the new UI and its looks great to me. Only has some minor suggestions for you to consider. We could possibly change the reminder to show for the next 3 days instead of the next week instead, once calendar is up, as it wouldn't make sense for both to show the dates for the next 1 week ah.

Can change also, but the main difference is that the calendar should show the week (Mon - Sun), whereas the reminder shows one week from today.

Added benefit for having a Calendar is that it would allow the user to have a sensing of the frequency of tuition sessions for a particular week.

But I agree with you that reducing the period to 3 days improves the functionality of the Calendar.

To add on:

add_rec_session n/STUDENT_NAME d/START_DATE e/END_DATE b/INTERVAL t/TIME k/DURATION s/SUBJECT f/FEE

vs e/ and b/ at the back for the actual command message for add_rec_session

Oh ps didn't click on the latest commit 😅 . Let's merge then!

Good idea 👍

Should we do it for the Home page as well?

I think I can try to truncate the fields to fit the size of the box.

Will update this in the UG to state that all names are case sensitive

It is stated in the user guide that the user can use the help command or press >kbd>f1>/kbd> to view the command usage.

This is also not a Feature Flaw.

#240

Ok will update the image and the Reminder description accordingly.

I think this one can add an explanation to UG to make it clear.

All changing tab suggestions are considered features and will not be added in v1.4.

New issue created to inform the user to change to the tuition tab to see updates from commands. #267

Closes #202, Closes #197.

LGTM! Thanks so much for your contribution to the project! Especially the UI, really well done! 👍

Thanks! 🥰

Great work by you as well!!! 💯

I think there might be some settings in your editor that are automatically modifying whitespaces/newlines of the code because this is actually a tutorial file.

Same as the above comment, awkward whitespaces in the method header comments.

Can consider removing this since we are not checking for duplicate endpoints or it might eventually get flagged as dead code.

Find command was only applied to names in AB3 but ours is likely to include all fields in the search. The test here may be referenced for implementing tests for our version of the find command.

Might want to be careful of this. Our application might not need this additional check as even having the same method/url may not mean they are the same if the data being sent is different (i.e. data in request body in a POST request)

To add on, I think it's possible to check for duplicates but in this case every single field (including tags) would need to match (unlike just name and address in the original AB3).

I think the check has been performed in isValidMethod below 😄

I think there's a good chance more tests will be breaking given how the header and data attributes have not been implemented yet. At the same time, I am also hesitant about commenting out all the test cases.

The consideration I have is that making several small fixes to pass them might be easier compared to having to make a single big change to all test cases at the same time. Depending on the implementation for header and data, ensuring the test cases pass now may prevent further complications down the road. Just a thought 😄

Should there be a newline here?

Might be good to populate the sample data in the correct format even though currently they are just stored as string when entered e.g for data it would be '{"key": "value"}'

Just a small point but the comments are not updated here.

Maybe instead of listing find command twice can differentiate the 2 ways to use it while listing it just once because on first glance it looked like a duplicate (similar to how run was listed).

Might help to mention that this is the second format since the previous one said 2 formats.

I think the match for ftp and file are not necessary since they are not protocols we support.

Minor typo here 😛

Need to update the links here 😄

Need to replace instances of AddressBook and Person 😄

Minor thing but "an Address" might sound better :3

Links here need to be fixed.

Should the Person reference be replaced with Endpoint instead of Method?

Looks much cleaner now! 😄

Minor typo for endpoint here.

Same typo as above.

Should it be find command instead?

Using an add might sound more correct here.

Just a suggestion but you may want to consider using the >kbd> tag so that the keyboard input are nicely formatted like this: >kbd>ctrl>/kbd> + >kbd>up>/kbd>

Nit picking at this point but some bullet points have full stop and some don't :3

Actually would it be better to use an actual url that works here? Just in case people actually paste this url to try and because it doesn't work, they flag it as a bug ._.

Good catch!

Since the method name has changed perhaps the parameter name should be updated as well

Might want to consider moving this to the miscellaneous section. The commands section currently fits into exactly one page and this extra tip will awkwardly carry over to the next page.

Parameter table in user guide now uses URL instead of Address, might be good to standardise here as well.

Double quotations need to be escaped with \ so that it shows up correctly on the jekyll page. The whitespace between colon and value should also be added to be consistent with the header format.

Might be better to include whitespaces between : and one, two and three to be consistent with the header formatting.

Just noticed this but can help to remove the 's after user.

person needs to be replaced with endpoint here (occurring at a few other places as well).

Same user issue as above (and in a few other places as well).

For the case of a shorthand would these 2 fields better be reflected as optional? It was raised as a bug report when highlighted as compulsory previously.

I think the issue for this is #526, in which the user brought up a valid point that reading the tip as it is makes the highlighting seem mismatching (since the compulsory prefix did not appear in the example that immediately followed it). I think arguments can be made both ways so safest option might be to split things up like in the find command although the difference for run is not as complex.

Do you mean metrics? 😛

I think we can put v1.4b since this is the final milestone 😄

Just to leave an update here:

The team has had an internal discussion and reviews will be left open to all members of the team (except the PR author) for now. This is slated to change as the project grows and the codebase becomes more complicated.

I actually considered this! Then I saw that the other files were not doing it this way so I thought to just follow what's already there as closely as I could :3

This was required to address the error raised: not on FX application thread; currentThread = Thread-4

I agree the animation should be further improved down the line 😄

Thank you for catching that, it's fixed! 😃

There's no check for header to be in json format. As an example, the header will be added in this format: -h "Content-Type: application/json". That said, when retrieving the individual key and value, I noticed that this was what I got: ["Content-Type: application/json"]. Hence, I trimmed the brackets and quotations to obtain the key and value. Ideally, the headers should be processed before being stored but until then this will still work 😄

Great suggestion, changed this in the latest commit! 😃

Reduce the spacing between the title (guide) and the subtitle (version number) xD

I am outside so can't update this now. I'll merge first so anyone hoping to work on the UG can go ahead and then fix the typo in another PR 😃

There... Was a previous method? xD Yea I agree what I did is actually not ideal, given more time (if we're serious about v2.0) we can clean this up in the future. On that note @JulietTeoh if you want to see how the error messages look like on the smallest window size (800 x 600) you may refer to the latest UG sent in our telegram group.

Great photo! @tjtanjin By the way, there is this slight distortion on the center-right edge of the photo, not sure if you have noticed it. If you don't mind I will go ahead and approve it.

On close inspection, I realized that you added this [[homepage](https://tjtanjin.com/)] in front of the Github and portfolio links. While I have no issues with the inclusion, I wonder if moving it to the back of GitHub and porfolio will make it more standardized? This is because not everyone might be adding their homepage link. What do you think?

I like the suggestion for shifting homepage link to the back, have updated it accordingly 😄 With regards to the image I will source for a better one at a future date but this should suffice for now 😅 Thanks!

Resolved with #75

@tlylt Thank you for taking the time to scour through the changes 😄 It is indeed a lot of updates at once and I should have provided more context in the PR message. Regarding the points you raised, here are some of the missing context (which have now been included in the original PR message as well):

The refactoring was done partly through IntelliJ and partly by hand, and during the refactoring by IntelliJ, certain imports were automatically changed (such as the one involving Messages and CollectionUtil that you mentioned). I have previously combed the files in general but a few of these change in imports were not caught (though the latest commit should have caught all if not most of them).
The change of seedu.address to seedu.us.among was a result of a brief discussion but it has not been cast in stone, so please feel free to suggest alternatives to the package names 😄
Finally, this PR changes only names and terminologies with no update to the logic at all so test cases would still need a separate update eventually :>

Hopefully these help provide more context 😄 I'll proceed to merge the PR for now and we can do a future PR to rectify stuffs if necessary, thank you!

Closed as checks failed to run when github actions went down earlier.

Resolved by #95

The image seems broken, could you double-check?

Thank you for pointing that out 😄 It's fixed now 😄

Addresses #112

Addressed by #111

The SendRequest class perhaps can be more aptly named as Request? Given that we are indeed modeling a thing that is called Request and the word Send seems redundant.

Just my 2 cents, other than that LGTM

Ok I renamed the logic classes under endpoint and renamed the execute method to send as well which sounds more apt: new GetRequest(endpointToSend).send();

Merging it since the changes are small 😄

@tlylt I tinkered around with this as well. Unsure if there is any lag reduction but I imagine we can play around with the initial text to set in the box to mask this from the users. The counter is just a placeholder, I will likely replace it with Processing Command... (the dots will change between having 1 to 3 dots to reflect progress). Just 2 key points I wish to bring up:

Firstly, although it works, the current code implementation feels rather messy because I had to wrap Platform.runLater a good 4-5 times around codes. If you had a better way to implement this, I'd love to hear it. If it helps, the reasoning behind my many uses of Platform.runLater is to deal with an error saying not on FX application thread; currentThread = Thread-4
Secondly, I did the UI threading within the MainWindow#executeCommand but this would mean that sometimes, even the fast commands like add and remove will see a quick flash of the counter (the pseudo progress indicator currently). Resolving this within MainWindow would look very messy as well. I am also still looking for a way to improve this.

I will tidy up and abstract parts of the code as much as I can tomorrow and try my best to make a PR before the team meeting so that we can further discuss this.

Great job, while you are at it, could you reduce the 5-second delay that emulates the wait time of an API response 🥺

Curious:

how did you fix the lag?

if we are disabling the user's ability to input while running the request, wondering if it will be better if we still show what he entered in the command box and clear it after the request is done? Not sure if this is the case already... for discussion only

I'll make a PR really soon to remove the wait time :3
Shifting Platform.runLater above the sleep code removed the lag (which came from the initial 1 second sleep)
Yup the entered command stays in the command box when frozen 😄

Not sure if I am getting this right, the request is cast to HttpPost for all the requests?

The setEntity method is unable to be called on HttpUriRequest and hence the casting. Whether this casting will be universal will be looked at again when more methods are added. If there is a need to then further abstraction needs to be done here 😄

Resolved in #145

Note:

User header input needs to be enclosed in quotations for example: -h "Content-Type: application/json".
Need to remove above mentioned quotations before storing.

Important:

The second change directly affects the parseHeaders method within HeaderUtil.java. When updating this, change the following line:
- Before:

headerString = headerString.substring(2, headerString.length() - 2);

After:

headerString = headerString.substring(1, headerString.length() - 1);

I think this is a great suggestion, since v1.2 is being wrapped up let's do it in v1.2b 😄

Addressed ever since Person was morphed into Endpoint.

Addressed in #125

interface as in the screen?

I think this is referring to the endpoint list on the left panel.

Sample endpoint 3 periodically returns an empty result with the following error:

"JavaFX Application Thread" java.lang.StackOverflowError

There is no known way for the user to directly cause it as of the time of writing this. It seems completely random. What is worth pointing out is that sample endpoint 3 returns a very long json result which is also reflected in the extra 1 second it takes to load the result into display.

This seems to be a performance issue and we should consider how to address this as soon as possible.

Have tried a few times and wasn't able trigger it, if it is a peculiarity with regards to this API, perhaps we should remove it as of now.

I think it's alright we can leave it there and hopefully it will appear again (happened twice to me so far) so that we can look at it. I am thinking to catch the stackoverflow error but not sure if that's actually legitimate.

Would this compromise the command line friendliness since it involves using the mouse to hover?

Might have a potential fix to this. Will look at using appendText in ResultDisplay and update again.

Another update, I tried both appendText as well as ListView instead of TextArea in our ResultDisplay. In all cases, the lag still features prominently and because the bug is not deterministic, I am also unable to tell if either of them actually fixes anything. With all that said, I have come across quite a number of threads discussing about the performance of JavaFX and in particular, it seems TextArea is not good for very lengthy strings. In fact digging deeper there's quite a lot of criticisms for JavaFX performance. With all that said, I will likely opt to catch the stackoverflow exception.

Note: I cannot tag prof damith here but I'll find time to clarify if this can actually be considered a bug of ours. If truly it is because JavaFX is unable to support such lengthy input without crashing, then hopefully it might be considered an inherited bug.

If the length of response is a concern, perhaps we can check the response length and limit that to a reasonable number such that we display a proper error message when the length exceeds that.

My concern is that this might be considered a bug as if we consider the fact that our application causes "loss of data" when calling an endpoint. Will really need to clarify soon.

Yup this is not high priority so we can try this out and discuss some time later.

Ok nvm I misinterpreted this. List command does seem useless given how our list is always showing, but without list, if you do a find command and get a subset of endpoints you have no way of going back to seeing all endpoints again. This is unless find command supports a wildcard search or defaults to showing all endpoints if no arguments are given but at this point it seems easiest to just keep list.

Closed in #232

Resolved in #166

Possible duplicate of #148

Looks good! As discussed, it would be even better if the background image scales with the screen size as well 😃

This behavior is also seen in CURL so I think it will be a good enhancement 😃

@tlylt @ong6 Is this discussion still ongoing or can it be closed?

Currently if a field is blank it states No Data, does that resolve this issue? @ong6

Closed by #259

I did a quick skim of the files and it seems that the whitespace removed from the likes of PREFIX_METHOD are instead being introduced in the strings they are being concatenated with. Am I overlooking anything?

LGTM!

Do you want to also change the example commands at the top and the command summary at the bottom? If not, I can do it 😃

Thank you for catching those, I have updated them with a commit 😄

I did a quick skim of the files and it seems that the whitespace removed from the likes of PREFIX_METHOD are instead being introduced in the strings they are being concatenated with. Am I overlooking anything?

Hi the only thing in the PR that affects code is the prefixs being changed in CliSyntax.java. For the add, edit and run, I just made the error command messages more readable, for example: from

"add -xget -usomeurl -hsomeheader" to

"add -x get -u someurl -h someheader"

Okie @ong6 introduced the whitespace in PREFIX_METHOD in this commit 5 days ago so I think's best for him to do the review.

@ong6 May I clarify on what the updates for the above commands are in the user guide? I missed this and just merged a user guide update :X

Resolved with the function to add endpoint and send them again simply by calling an index.

Resolved with the current result display showing API responses.

Resolved with the application currently having a very simple design and clear information for endpoints.

Resolved with the functionality of send command.

Resolved with the API responses being returned in result display and being stored in imposter.json.

Resolved with the current capabilities of the application to allow easy testing of APIs.

Resolved with the current API calls returning a response time.

Resolved with the support for tagging of endpoints.

Resolved with the show command displaying responses from the last run of an API call.

@tjtanjin the run and send test lowly unreliable they sometimes pass sometimes fail on my comp and I couldn't even commit my work on sourcetree.

Strange if it's inconsistent, if it happens again can create an issue for it and then paste screenshots of the error messages easier to debug 😄

Resolved since all features are now supported conveniently through command line or keyboard shortcuts.

Resolved in #280

Resolved with the enhanced find and tagging functionality for endpoints.

Duplicate of #8

@AY2021S2-CS2103T-T12-4/developers Just a note that this also remains an important issue with regards to the aspect of UI refinements for v1.3.

I think it's not stated obviously but the background is suppose to differ from theme to theme and both dark and light theme has a plain background currently 😅 To clarify the bug for light theme is obvious once you only have like one endpoint left in the left panel.

@tlylt Very detailed help prompt, looks ready to be merged! 😃

The endpoint associated with this error returns a response body of length above 800000 and infrequently crashes in JavaFX when setText is called. There seems to be no better way to improve performance for this in JavaFX (have tried ListView, staggering the setting of text etc). As this lies with performance issues in JavaFX, it is more practical to address this in our requirements where we "cap" the length of response body for a reasonable performance of the application to be less than 100000.

Thanks and sorry for the conflicts!!!!

All good xD Thanks 😄

Refer to latest issue at #310

Resolved with the now more detailed error messages.

Seems similar to what @ong6 suggested in issue #312 except his was for the clear command. Might want to entertain possibilities of solving both these issues at once.

Resolved with the current features of our application.

Yup I agree that makes sense can update it 😄

Is this going to be added in the form of a new feature?

If this gets added before the night can update the UG as well? 😄

Resolved as current application provides sample APIs.

With the guides and application near completion, ease of use has been achieved.

Possibly discuss the progress on this task in the afternoon meeting. From my perspective, I think the UG styling & structure are of decent quality, largely thanks to @tjtanjin. If all features are finalized, perhaps everyone could go through the UG at least once again just to make sure no stones are left unturned.

There were some new points brought up after the UG today. They are mostly small details and should not be a lot of work. I agree that everyone should go through the UG at least once again, before the mock PE.

There seems to be some issue with macos builds on github actions. Merging this for the moment seeing as tests passed for ubuntu and windows so that I can continue work on the UG.

Merged in case additional urgent fixes to the UG are required before PE dry run.

Resolved by #463

Just putting a note here for now:

The reason for the above difference in error messages is due to how the requests library handles these 2 URL. The former contains alphabets and thus the library attempts to resolve the IP address it is referring to so that it can connect to it, throwing an UnknownHostException. The latter contains only numbers and the library treated it as an IP address to connect to directly (aka no need to resolve hostname) but also fails to establish a connection, throwing a ConnectException. This error mis-match can be easily fixed since the former is merely a more specific error message than the latter. The decision to standardise using the latter as the common error message is to be discussed with the team during the weekly meeting.

Just a note:

The DG mentions that this application is able to support up to 100k length from the response body. This artificial limitation is due to JavaFX's textarea being terrible at handling large input. The Youtube link above returns nearly 500k lines though sadly, the DG is not included in this PE-D. That said, let's forcibly trim the response output if it exceeds 100k in length.

Just a note:

A protocol needs to be specified for the request to be carried out. The closest example that can be drawn is that typing google.com in the browser address bar automatically gets prepended with https.

Just a note:

The space between each prefix is necessary for differentiating between the end/start of different parameters input. The missing space between address field and -d above would naturally mean that the entire string there gets interpreted as part of address and thus prompting the error above. Finally, this error message also accurately points the user to where the error is (the address field) which would be more than enough for the user to notice the missing space.

Just a note:

This is an inherited bug from AB3 but still needs to be fixed.

Just a note:

All screenshots were taken to be of the same size to make the UG more user friendly (no images of varying sizes that can throw people off while reading the guide). I suppose a clearer message mentioning this might help.

Just a note:

Unlike a command example, these JSON data do not perform any actions as they are merely representations of data. The descriptions of this data would be good to have but unlikely bug-worthy. This is especially because the appendix was added to provide brief information relevant to APIs and the UG explicitly states at the beginning that users should still learn these relevant information from proper tutorial contents first.

There is actually nothing wrong with the above command format, except that the application tried to establish a connection to 1 but failed because there is no such server for it to connect to, explaining the error message given above.

The find command did exactly what it was suppose to do and informed the user that 0 endpoints could be found. Having an additional message to prompt the user to list all endpoints again would be a nice to have, but not having it does not really come off as a bug.

Just a note:

It might help reduce the clutter if the example was removed.

If a protocol is not specified, the http protocol is automatically added. This needs to be made clear in the UG.

Addressed in #535

Great suggestion, a link to the JSON format appendix should be added in the first instance of the word JSON. That said, this is more of a nice to have and not a bug as the JSON format is still sufficiently linked and explained in the rest of the document.

Just a note:

JAR file needs to be ran at least once and with data modifications for the folder to appear. It also makes sense that if the application has not even been ran then that there should be no data. This should apply to most if not all tP projects. That said, the UG can go a step further to clearly state this.

Addressed in #536

The format for adding multiple headers involve the use of multiple -h tags, not with a comma. This will be better highlighted in the UG but is not an issue with the feature itself.

Just a note:

@AY2021S2-CS2103T-T12-4/developers This has to do with the "whitespace after prefix" issue we brought up in tutorial.

The space is actually present in the error message above (copy paste to verify) and if users follow the exact same format, there would not be an issue. Not entirely sure that this needs to be explicitly mentioned given that many other areas such as prefixes also make use of this whitespaces for distinction in their examples.

Just a note:

This was discussed within the team before and the consensus reached is that endpoint with the same URL, method type, header and data might be used for different purposes (identified with a tag). Let's say the tag represents a project that the endpoint belongs to. In this use case, differentiating endpoints with tags would be relevant to keep endpoints organised for different projects.

Recommended for user to maximise the window.

The protocols used are different.

May we check what platform this is being tested on? Copy pasting the add command works for our team.

@tashawan23

I am thinking would it be better if we also add in either a ... or a we truncated it due to limitation in JavaFX at the end of the text, on top of mentioning it in the user guide?

Otherwise LGTM.

Sounds good, I'll include this in another UG PR to avoid merge conflicts since others are probably working on the UG at the moment 😄

I will update this together with #522 once UI updates are complete 😄

Correct me if I am wrong but the response field should still be there except that it may or may not contain values (depending on whether that endpoint has been ran before).

@tlylt Is the allowed range mentioned anywhere in case this gets raised as a bug

Note: need to remove the information of those data (from textarea) that has now been moved into the tags.

Try stashing your changes and running add, edit and show. They reveal more details than the send and run commands such as header, data and tag. show is suppose to show every single detail of the endpoint whereas send and run only shows the endpoint and response fields. The current changes removes these details from the textarea, giving the impression that everything is the same.

In case it was missed out, the appendix for this and Effort are already included in the DG but still needs quite a lot of touchup.

@ong6 The diagram/information are largely accurate but just some very minor considerations for Add/Find implementation:

For the sequence diagram, the return arrow from AddCommand has the label u even though it should more appropriately be a. That said, the name given to the AddCommand instance should also be a, if we were to follow the style of the addressbook.
This phrasing sounds a bit off "Upon the users entry of the endpoint", perhaps something simpler like "When the user adds an endpoint" will sound better.
The URL used in the add command section differs a lot (a total of 3), let's stick with one perhaps just google.com so that it's easier for others to read. In particular, the URL mentioned in the steps does not match the one shown in the sequence diagram.
Capitalisation in the Find activity diagram is inconsistent.
May want to add in design considerations for Find command since its function is quite complex.

That's all 😄

Hello! I apologise for appearing uninvited, I was really curious about the status of my bug reports. With regards to the editing of the data file, I actually came across this page stating the tP constraints. One of the constraints listed was Constraint-Human-Editable-File, which seems to imply that the application needs to fail gracefully when an invalid data file format is found.

Thus, I am not sure if specifying that users cannot touch the data file might violate this constraint. Perhaps it is best to clarify with the prof first? :3 I would personally be interested to know as well 😛

Maybe you can consider correcting imports with *? Could be why your code failed the style check.

you could actually just add your new property details to TypicalProperties file under testutil rather than editing the default values of property builder

Should it be property book instead of address book here?

Remember to update the javadocs here too

haha think it shouldn't matter but for future reference I think u should just add it to the TypicalProperties file ba 👍

a suggestion bc I don't think its good to initialise the variables to null:

Name name;

Contact contact; etc

consider use of split function for more concise code?

oh I see, because the toString may not contain the variable. ok nvrm then haha

okk I see that u updated the function to use length function 👍 I just found the '13' and other indexes to be random

Should this be combined into one line?

Should this be combined into one line? 120 characters per line does not apply to DG

Should this be combined into one line?

Should PersonListPanel be updated to PropertyListPanel and AppointmentListPanel?

should "the person whose name contains the keywords" from the original address book be removed?

don't think your eclipse setting files should be included

I see, ok

are your diagrams to be inserted later?

these too

should this be 'undo'?

are these to be added later?

How about 'the property list will now be in descending order based on price'?

I think this doesn't sound very user friendly? A user may not know what a parameter is

should we explain what does Option, Sales and Purchase Agreement, and Completion mean?

Don't think the user will know what does status refer to

is this supposed to be [PROPERTY_TYPE] instead?

think the 'Both done at the same time' is unnecessary? If anything, maybe 'simultaneously' will be better

I meant line 265 266, there's this [remarks], this that supposed to be the case?

I think can keep the part act the first property having highest price at the book though, although the phrasing for the first half is good now

do u think ClientBuilder should be used for this?

same for this

should PropertyBuilder class be used?

should AppointmentBuilder class be used for this?

are these supposed to be commented out?

this too

not sure if its cut off or the significance of new keyword is unclear

u mean one input? I think its unclear what one per query refers to

Valid date or should it be deadline?

probably a small issue and both are ok but it think deadline makes more sense since you are checking for a valid deadline?

fixed!

fixed as well

Fixed, thanks!

fixed

done

Fixed as well:)

Nope, if you guys are agreeable with the new LightTheme Ui, I will go ahead and delete DarkTheme.css

I would say it's not impossible but the purpose of adopting a light theme was to allow the greying out of expired property and appointments to be somewhat observable yet inconspicuous. The grey effect in the already Black/Grey DarkTheme would probably not achieve the same effect. However, if you guys are keen on a dark theme, I can consider a DarkTheme design in a subsequent update- maybe keep the DarkTheme.css file for now

oh yes ok will update this

Code style issue at ../src/test/java/seedu/address/logic/commands/RemarkCommandTest.java:40: no newline at EOF.

hey, I've fixed the bug that doesn't display postal code. However, about price, have to consult junwei on this because he is adding the price of the property as client info actually, not as part of property attribute itself

not implemented, to be considered after v1.4

@candyhy what do you think of this 🤔

I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either

can I also suggest keeping the text wrapping fixes and changes to Ui as separate pull requests? cos I think its imperative to fix the text wrapping but the Ui may not be satisfactory yet

can I also suggest keeping the text wrapping fixes and changes to Ui as separate pull requests? cos I think its imperative to fix the text wrapping but the Ui may not be satisfactory yet

created a separate pr for text wrap!

cool thanks! 👍

@candyhy what do you think of this thinking

I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either

what colour would you suggest?

I think its better to keep the background white/black. shouldn't have more than 3 colours in a Ui in my opinion

Updated StorageClassDiagram

Storage interface should extend PropertyBookStorage, AppointmentBookStorage and UserPrefsStorage too

will update this too

new StorageClassDiagram

ohya can u upload your diagrams here for everyone to see?

Need to update the documentation here

Update documentation

Add a vertical spacing here? - the auto-formatter should take care of this

Same issue with ManufactureDate, CompletedDate and OrderDate

If Order has a cheeseType property, then I would assume that one order should only have one type of cheese. Then, I think there should be some checks to ensure this?

An alternative would be to let an Order have multiple cheese types. If so, then we will have to remove the cheeseType property.

Update documentation

Add documentation

Is this class used anywhere yet?

I believe these should be placed under testutil instead (not logic/commands/CommandTestUtil.

Also, it will be great if we tested invalid dates and cheese types as well.

Standardize all comments to start with capital letter?

Should we rename FindCommandParser to FindCustomerCommandParser? In order to be consistent

Currently some funny things are happening to the customer list after we make the findcustomer command with an empty field following a valid prefix, for example, after inputting "findcustomer n/".

Perhaps we can consider using ParseException to handle the above case as well?

I think we should have two cheeseIds in this completed order? Since its quantity is 2 and we should not have been able to complete it with only one cheese.

Changing the quantity to 1 will work too

I think we need to account for the case where the input cheeseId no longer exist.

For example, suppose we have order with OrderId 3 that has been fulfilled with cheese with CheeseId 3.

The user first deletes the cheese with CheeseId 3.
The user proceeds deletes the order with OrderId 3, which brings us to the code block above.
The above for-loop is unable to find the cheese with ID 3, since it has been deleted previously.
this.targetIndex is set to Index.fromZeroBased(1), the default value.
The wrong cheese is deleted.

I think we should "unfilter" the order list here? That is, calling model.updateFilteredOrderList(PREDICATE_SHOW_ALL_ORDERS). This is so that we can iterate through the complete order list when finding orders to cascade-delete.

This is so that when the findorders feature is implemented in the future (which will cause the order list to potentially be incomplete), this command can still work fine.

Think we can "unfilter" the cheese list here before iterating through it! Rationale below (in another comment).

We might not be able to use Index.fromZerobased(0) as the base case representing that a cheese is not found.

In the below for loop, if the matching cheese is in index 0, then we will need to use Index.fromZeroBased(0) as the targetIndex.

So, need to either change the base case or the loop below.

The two ways when handling invalid data file:

Data file not in correct format -> warning -> start with an empty address book.
Data file not in correct format -> IllegalArgumentException -> app does not start.

Should we standardize this to one method??

I think we can add in a case to handle when the user keys in an expiry date but not a maturity date when adding a cheese.

Anyway, since we are at this topic: I was thinking, we may want to consider dropping certain attributes from the models. For example only, since we have only 1 week left to add features, I think we may not have the time to implement features that deal with the cheeses' manufacture date, maturity date, etc.

We can always leave the clean up to v1.4, so it's just something to think about now? Should discuss more during Saturday's meeting.

I think it's okay if the cheese ID does not currently exist?

Consider the following scenario:

User adds a new cheese (CheeseID = 1, CheeseType = Gouda, Quantity = 1)
User adds a new order (OrderID = 1, CheeseType = Gouda, Quantity = 1)
User completes Order 1 with Cheese 1.
User deletes Cheese 1 (we currently allow this to happen without changing the order to which the cheese was assigned).
User close the app.
User reopens the app and runs into an IllegalArgumentException because CheeseID 1 no longer exist.

We can also check to ensure that an incomplete order's cheeseIds is empty.

If not, the app can start without errors or warnings even when there's an order in the data file like this:

I think disallowing cheese deletion after it has been assigned sounds good - it will be just like IRL where you can't throw away a cheese after assigning it to an order, for example.

This one you and Li Quan can decide? or you want to wait until Saturday to discuss also can.

And then, actually a cheese manufacture date don't necessarily have to be after an order's order date right? Are you referring to the order's completed date instead? If so then sounds good!

I think this line of documentation regarding tags doesn't apply to EditCheeseCommand?

I think the parameter name should be editCheeseDescriptor??

Should PREFIX_CHEESE_TYPE, PREFIX_QUANTITY and PREFIX_PHONE be in square brackets too? Since they are optional

Same issue with doc here!

Do also update the UG and the DG (use cases)

The last line sounds a little confusing, is it possible to rephrase it? (the "as opposed to implementation within the different Command classes" part). or we can simply omit it if it's not important?

Trailing white space

Add --- divider and remove [In Progress]

Do add the --- divider and remove the [In Progress]

Is the diagram missing some return arrows?

Also, I think we should standardize, as a group, whether to include the argument strings in our sequence diagram

Is there supposed to be a sequence diagram here?

Do clean up the documentation a bit (typos, punctuations, etc.)

Also, take note of the trailing white spaces:

Class diagrams LGTM

May I confirm if this is the case for our project? I tried running the JAR file but couldn't find the data folder anywhere. The storage works perfectly though.

I think ORDER_DATE can only be today or earlier

okay got it thanks

Okay i just removed the bolding entirely, thought it was unnecessary (dk why I typed it this way, must have missed it).

done!

ahh I get what you mean. Made the change

It's quite hard to make changes to the UI and test them in this current branch, the reason being we cannot yet create observable lists of orders or cheeses.

Is it okay to merge this branch first? Then I can create another branch, rebase on the new storage branch and work on the UI right away.

Ignore last ^. I'll rebase on the new storage management branch and work from there.

Noted, will address this before tmr (monday) morning

Noted, will address this before tmr (monday) morning. Will probably be adding a class to Model to reflect the screens to show.

mb, fixed liao

mb, forgot to change the methods' and variables' names after copy-pasting - fixed

I did it using plant UML leh (same as in AB3) so you will have to pull the branch to see it. I will paste them here so it's more convenient to review.

I realized how ugly the panels and cards diagram is - gimme a min ill make some edits.

okay noted

It's supposed to be the enum representing which list to show. Actually we may not need to spell it out in the sequence diagram.

The updated sequence diagram.

I think we can leave the "listcheeses" argument in? I referred to AB3's developer guide and this seems like the style they are following

loooks good to me!

Duplicate of #121

Duplicate of #117

Fixed in #116

Fixed in #117

If I remember correctly, the "As a" part don't have to be a user. So in this case maybe we can do: "Cake Collate/Program". But, I tried to find this in the lecture notes/textbook and couldn't find it.

So, maybe we can omit the "So that"/benefit part instead of "(obvious)", since it was mentioned in the notes benefits can be omitted if they are obvious.

The full-stop in the benefit part caught my eye haha. Maybe standardize across the DG~

Maybe instead of "track", "execute"? Or something along that line.. Because we aren't really tracking the deletion, just actually removing it from the database.

Noticed a "/" at the end of the benefit part.

Maybe "re-adding" or "adding"? haha

Noticed full-stop here as well. Same for a few below this~

Noticed you used capital "V" for "View". Maybe standardize and use small caps. Same for the benefits part in line 264 and 267 "My" and "Details".

Maybe can leave out the benefits part too.

why got another add nub

Not sure if the AB3 allows for 2 p/

I think it does but maybe to make it clearer in the UserGuide, just put one phone number

Can you add a full stop haha

Need to change "person", same for line 29

Maybe needs changing/removed

Assuming you're asking a question?

I think it would be good to have a way to differentiate or find out if two HelpCards are the same, regardless if we ever use this equals method.

Same thing, need to change "persons", same for line 29, 48

Maybe add a brief javadoc?

Hmm, just from looking at the files changed, I can't figure out why you abstracted out fillPersonListPanel()...

Same thing here, but I am guessing because of some dependencies you needed to setRoot(root) before you setController(this)

May I know why you are deleting this? Is it because this method is not used?

Hmm.. By right the data shouldn't change while the user is in the help panel. But it wouldn't harm to insert redundancies so that the program won't break if for some reason data was changed during the transition. So, I would recommend using this fillPersonListPanel() to populate the personlist panel.

Ahhh, I see. We were told cyclic dependencies are bad practices in 1101 right? While its a bad practice I think it is still used haha if you take a look at w8 topics the first video for drawing class/object diagrams, they have cyclic dependency also: box and lid.

Maybe if you want to, you can change the resetMainWindow method in MainWindow to a static method then use a static call in HelpCommandPanel. Not sure if that is still cyclic dependency lol. Else if you really want to resolve it I guess you need an association class.. So, goodluck!

"orders" ? instead of "persons"

Same thing here, "orders"

😮 why is this here? Thought it is supposed to be changed by Pavitra's PR

If you're changing such that user can choose the range of dates then you should remove "is within 3 days of the current date" right.

You can maybe merge this two if you are not trying to differentiate the reason why there is a parse failure (since you are throwing the same exception). In a way the error message will be less meaningful but it is what the original coder(s) did too for AddCommandParser etc. We discussed this briefly during our last meeting when @pPris brought it up. I think for now we are KIV-ing and maybe changing it if we have time.

Should be "order"

Same for other usages of "people" and/or "person" for this file

Remove this if its not used? 😃

He probably needed the request here to create an order item lol. Although it is possible to overload the Order constructor.

Maybe for extensibility. Having a prefix in place now means in the future if we want to add another prefix it can be easily done.
Maybe so that user can input more than 1 request per command. Without the prefix, the user may have to use the command twice to input 2 different requests.

I think it's fine leaving it as it is now 😃

"diabetus" is on purpose or typo? lol

Remove this boi

CommandException should be removed

Just wondering why you use .value here while you used .toString() in L41?

To test "no parameters" you should include all other required fields and only leave out the parameters. I'm guessing you mean to test for the prefix here? Since you are testing index below

Same for this, you should only leave out index and include prefix.

Remember to remove the cost column~

Yup definitely! If I recall correctly Benson's details will be used specifically in some tests. So since you are adding a field as well, take note of those specific test cases that tries to extract Benson's details ya. Probably don't have to do anything about it if you didn't miss anything ~

Good catch! Will do.

Yup, there are. Nice catch again:)

Uhm because I wanted to let the user be able to search for a date using any of the format they use when they add the order + if they input the day/month/year only. Though now that I look at it I probably can do away with day/month/year since they are already included in the 4 formats provided haha. Also, yeah probably can create a method in deliverydate to get formats.

Yeap my initial concern was I didn't want to let user be able to use this prefix at all thats why I only create it in the code. Just remember I can create the prefix but not set it as a prefix argmultimap accept haha thanks

"or" search is done by the "all/" prefix which concatenate all the fields in an order to search the keywords against. So that becomes like alloforder.contains(keywords)

Add a OrderDescription class to seedu.address.model.person and edit the Person class to reflect added field.

LGTM~

LGTM 👍

LGTM 💯

LTGM

LGTM

LGTM, can always add more next time.

LGTM 👍

LGTM ~

This seems different from the ab3 alternative format provided. Maybe using the provided format would be better? Do let me know if I am mistaken.

The referenced link is here: https://se-education.org/addressbook-level3/DeveloperGuide.html#design-consideration

Perhaps the details not choosing the alternative could be added to be clearer why it was not used in the end

This is a small one but maybe add a space between valid and '''

Maybe reword the second sentence as it feels a little weird to read.

Perhaps abstract the 3 into a variable to avoid magic numbers

The tests cases seems extensive. Good work

Maybe a enum like "CommandType" would make more sense as it is somewhat overcrowding the constructor. The check could be against the enum value instead if needed

The naming seems ambiguous

This javadocs probably should be residents instead of persons

Person -> Resident

Perhaps use DuplicateResidentRoomException instead

Perhaps change the resident references in this file to resident rooms (both in comment and code)

resident -> resident room

Resident -> ResidentRoom

Removing probably no need to sort again but I think it is ok to have it here too since it probably does not affect performance much at this scale

Probably better to use the static variables from the typical rooms class

Maybe just don't catch it?

I think maybe adding 1 more test case value beyond the upper and lower bounds would make this more complete

I think this should be at the top of the file to be clear what happens

Probably no need to do this in Remove since removing from a sorted list keeps the list sorted

$categor -> $category

Maybe add 1 more space before />

Maybe expand the CLI and GUI into Command Line Interface (CLI) and similarly for GUI. Not sure if this affects the PPP too.

Will this be consistent in display error messages with the incoming fix for INDEX?

Add the spaces before the last |

This is very small, but do you want to use 4. ?

This might need a little rephrasing as we decided on a slightly different error message

The INDEX at the end of the sentence needs the `` too

Javadoc needs param and return too but can be added in a future PR

Thanks for updating my tests cases too

do -> does?

Maybe change to "each with its corresponding allocated room, if any"?

remove "is"

Maybe add the space after '>li>' and before '>/li> for the newly added point

full stop is next line after predicate

I will leave this to Colin

The inconsistency is due to the need to distinguish room.RoomNumber from issue.RoomNumber

I would like to discuss if the command history should also include failed commands. I think there is merit to mimic the same behaviour where the invalid command can be access via up and down arrow keys so that a Power User can edit the invalid command rather than retype it all.

If we do go down this path, I think a possible implementation is that each history entry will keep a field to keep the corresponding command used. Thus, if the field is null, it indicates an invalid command, otherwise it indicates a valid command.

I would like to discuss if the command history should also include failed commands. I think there is merit to mimic the same behaviour where the invalid command can be access via up and down arrow keys so that a Power User can edit the invalid command rather than retype it all.

If we do go down this path, I think a possible implementation is that each history entry will keep a field to keep the corresponding command used. Thus, if the field is null, it indicates an invalid command, otherwise it indicates a valid command.

Hmm, thanks for the suggestion. SunRez currently does not consume the user's input when a command is invalid, so a power user can already edit an invalid command easily.

I see, that makes sense. In that case, the suggested feature seems to be not needed.

Reopening as issue commands are not covered yet.

Note that auto format affected more lines than necessary

Duplicate of #203

Duplicate of #180

Duplicate of #89

I decided to just allow that and provide that in the constraint message. Will update the documentation later.

Hmm, if that is the case, then I think narrowing the valid formats would be better. i.e. MM dd hh (enforce double digits always)

Will KIV for future implementation in UG or DG

Will update UG to document requirements

Would it be possible to link directly to the quick start section as well?

Do you think "clients' contact details" will be more suitable?

Would it be better to have a static constant for each direction?

Would it be better to have static constant for each direction?

Is using "sorts" instead of "sort" better as it follows the convention used by the other commands?

Do you think that we could use 'insurance policy' instead of 'policy' because it would be more intuitive for the i/ tag that we are using? At least for this section. It seems fine when we are talking about the policy command.

Maybe you forgot to change some information after copying them from find command.

Is there a use for this logger?

Just to clarify Policy_ means even if different insurance companies have different ways to label their policies, they should all be labeled starting with Policy_? E.g. company A labels policies P#12345, company B labels policies Life#7900, the respective policy ids in ClientBook would be Policy_P#12345 and Policy_Life#75900.

Would it be better to name the method getPolicyUrl? The if-present characteristic of it is represented by the fact that Optional is used.

Perhaps a grammatical error here? Is there a reason why the original comment was changed?

Would it be good to also update the user guide to reflect this required format?

associated with a ~~selected~~ client?

Maybe "delete client contact" instead, to be consistent with add and edit.

"hence" sounds redundant when the line is read.

Could use INDEX instead of "The index", to clearly indicate that you are talking about INDEX in the command.

This line suggests that only 1 optional attribute can be added, while one of the example below shows multiple optional attributes being used. This can be confusing to the reader.

Did not state explicitly what the flags are used for. The usage is clear to us as we are the developers.

Also, would it be better to list the flags in a table? Idk

A suggestion would be "The delimiter & between keywords allows you to search for Clients using multiple keywords."

Can draw similarities with list function. E.g. "Similar to the list command, optional attributes can be added to show only certain attributes in the search result"

Aside from the example on sorting by name, do you think an example on sorting insurance policy is needed?

Maybe "After setting a password, the application" or ClientBook instead of application.

ClientBook's ~~ClientBook~~ password

ClientBook's password is removed.
Suggestion: Future launches of ClientBook will not require a password?

Currently the json is stored in a zip file regardless of whether it is locked. If its locked then there's a password to the zip file.

A suggestion: "schedules a meeting on a particular date and time with a client in Clientbook"

Is this line consistent with what is said for other similar features that require an index?

Do you think having at least 1 screenshot to display the expected response will help the reader?

This is missing in the user guide.

Do you think the field name should be renamed to meetings to reflect that multiple meetings can be inside? Please also update other similar namings in this file.

Could you abstract/SLAP some part of this to reduce the length?

Although this is the default implementation by AB3, would it be better to do the typecasting only once?

Do you think it is better to follow the existing convention? I.e name the list meetingList just like policyList.

Does this imply that delete meeting deletes all meetings? Could you explain this implementation vs deleting just 1 particular meeting?

Not sure how this works but does it validate the date? E.g. if I put 30 Feburary will it reject? It is up to you to decide if it is needed.

Does this mean you did not update the test case to accomodate meetings?

Is this meant to be in the production code or just a debug line?

Done

Have changed Tag into InsurancePolicy @ line 24. Will be keeping the JavaDoc comment to follow the JsonAdaptedTag class from which I adapted the code.

Appreciate the feedback! However that was the format that came with the incumbent code e.g. DeleteCommand's equals().

Yes, the original intent is for unlock command to work even without CURRENT_PASSWORD if ClientBook is not locked. However, in hindsight this is confusing for the user and I have changed CURRENT_PASSWORD to be a compulsory argument in the UG.

That is a great suggestion actually.

One possible way would be to encrypt a password file using a secret key within our code which when the program runs, will be decrypted and stored in program state and encrypted immediately.

The user can then enter lock without any parameters to lock using the old password.

However, I do feel that the effort to return ratio is rather minimal as it does not make our program any more tailored for our user than what already exists.

Good point there, I was looking at the same API a few days ago too. The methods ZipFile.isEncrypted() and ZipFile.extractAll() did not specify which type of ZipException was thrown. The try blocks are separated because I was using the second exception to return false, while the first try block was used to catch the error thrown when checking if the zip file is encrypted.

It was to make it clear during usage that there is no password involved as someone reading it may interpret as entering an empty password.

Fixed.

Thanks for the feedback! Turns out String.split() will return an array with 1 element when the string is an empty string. A similar problem in UnlockCommandParser has also been fixed.

I agree, I have updated the method's name to improve clarity.

You are right. Actually carrot probably refers to just ^. Will be changing to what you have suggested.

I believe the test name is correct because I'm testing the equals method to be successful when two UnlockCommand with the same currentPassword fields are tested to be equal.

That's a comment from the code base, no idea.

I think so too. Haha

Fixed.

Where? Because there is already an entry for meet in this feature summary.

done.

fixed.

Most of the commands have 1 line of spacing between consecutive examples, except for find command because it has many examples. Is there a specific command that you are referring to?

Sounds good.

fixed.

Sure it will be helpful in the case where someone who is not tech-savy actually uses our application but there won't be such a scenario because the only people who will be using ClientBook are the PE testers.

Fixed

Changed to Graphical User Interface

its used as complement to the word minus and not standalone so I used brackets instead of code

Done.

I feel that it may be too much bolding around the area.

Fixed.

Done, also updated the red color to be darker.

No idea why gradle build fails on Github when it passes on my system.

lgtm

Thanks for the review. Will be merging it

Some of the links can be updated to point to our repo. Currently they are pointing to ab3's repo.

I recommend you clone this https://github.com/swayongshen/tp/tree/add-lock and do some general testing.

I have implemented the new feature of saving the old password. When the user calls the lock command to set a new password, the password will be stored in an encrypted file named keystore in /data/.

After unlocking ClientBook, the next time the user tries to lock ClientBook without a password, the old password will be decrypted from the password file and added to the state of the program and the password file will be encrypted immediately.

LGTM! Perhaps you might want to add this in to the User Guide too?

You are right, I have added it to the features section as well as created a Summary of Keyboard Shortcuts section.

Cleaned up UG in time for PE dry run. Tasks left:

Group and color code features
Clarify whats identifier and attributes
Also need to improve purpose of each feature/command. Currently quite pointless.

Edit command also has similar behavior which needs to be fixed.

One more comment: for Insurance Policies, can we also add into the UG saying that they are uniquely identified by the PolicyID and PolicyURL pair? So this means that the user can enter 2 policies of the same ID, but link them to different documents.

This is currently being done in the code.

If you have any alternatives, do let me know so I can update the code accordingly.

How about "a client cannot own 2 policies with the same policy ID and URL."

I noticed in the code that duplicate input for tags are simply ignored. Perhaps in the UG we might want to add that duplicate/repeated input will be ignored for tags and policies? Since these two can accept multiple objects, as compared to repeated address/names/phone numbers, where we simply choose to take the last input.

Added "if duplicate X are entered in a command. only 1 will be added to the client" in the attributes and identifier table.

How about "a client cannot own 2 policies with the same policy ID and URL."

Perhaps "... with the same policy ID and URL pair"?

I think even though what you've suggested sounds clearer to a technical person as well as PE testers, it could be unclear to a non-technical reader like Serene.

I think it would be better if you could sort the user stories by priority.

I think the numbering for this extension should be 1a1.

I think this use case should resume at step 3 as the list would still be shown even after the error message, so ClientBook does not have to show it again.

A suggestion would be "2a. The list of matched clients is empty."

Same here. A suggestion would be "2a. The list of matched clients is empty."

Would be nice if can add a screenshot of how the feature works.

Would it be possible for the success message to output the attribute that was specified as well? Like "Listed all clients with address attribute as filter."

A suggestion will be to do "if (!isAttributeSpecified()) {".

One suggestion would be to use switch statements.

Same here. Suggestion to use switch statements.

Suggestion to name this isFirst to isFirstAttribute to make it more understandable.

Same here for the isFirst boolean as mentioned above.

I think there is a typo here. Should be "...client management tasks faster than traditional...".

Would it be better to define what is "home folder"?

Instead of "jar file" maybe you can put "clientbook.jar" with a markup to be more specific?

Adds a client named John Doe along with his details to ClientBook.

Index has to be within the range of the list as well.

Maybe can include an image for the "list -policy" command, since the "list -phone -policy" one already has one.

Also can add "An optional attribute option can be added to show the list of matched clients with only the specified attribute."

The image format is different from the other images (e.g. the title bar not shown).

I think it is okay to remove the OR search part because I think the user might not understand what it is.

Same here, about the index being in range of the list.

I am not sure if these 2 lines should be in this policy command section. Feels like it should be stated in the add/edit command section where the policies are added/edited.

Same here with the index within range.

Will be good if can describe how the sort by policy command displays the list. Maybe add an example.

I think there is a typo with "exclamation".

How about "Copy the file to the folder where you want to store the ClientBook application and your client information."?

Yeah, this is much clearer!

Yeap, that works too!

Like a screenshot of what happens when you perform "sort -i -dsc".

I think this part is missing the "FLAG/KEYWORD [& MORE_KEYWORDS]..." part.

I think this key should be excluded from the merge.

I think its better to show the format as "[i/POLICY_NUMBER... [-MODE]]..." or something like that because the mode only needs to be specified when there is a policy number provided. Correct me if I am wrong.

Would be nice if you can mention how the user can do a replace, which is by not including the "-MODE".

Not a big issue but it would be good if the conditions in the if-else statements can be abstracted to make reading it easier.

I think theres a typo here for "Deletes".

Will be good if the Ui image can be updated to reflect client contacts that have some policy URLs, meeting details and relevant tags.

Yeah, I just followed the original AB3 convention and used their way of expressing booleans like this. So I don't think I will be changing it as doing so will also mean changing the naming convention of all similar booleans in the existing AB3.

Thanks for pointing this out! I have made the changes.

Yup, I intended for it to check the name only, so I have changed the method. Thanks!

I have inserted assertion errors in the methods you mentioned. Thanks!

Thanks for the suggestion! I have renamed the object to make it less confusing.

LGTM 👍🏻

Closes #9

I think maybe we can use student instead of stu to improve readability

Possibly change the use of 'acc' and 'el' here too

The change.next() method controls the position of an iterator that goes through the discrete changes in the Student List. Whenever there is a change the listener catches these changes and triggers the contents of the onChanged function. The while loop will terminate after all tracked changes are iterated. Here's the API

Yeah, I believe the "calling" to update the ListView is abstracted away in the implementation of ObservableLists in JavaFx under the Observable collections.

I think the reason why we're using ObservableLists is properly summarised in this article.

A ListView bounded by List will not update upon changes, but a ListView bounded by ObservableList will.

Correct me if i'm wrong, is this a particular coding standard I do not know of?

Might not need to check for same sessions?

{@code name}

I believe this.value would be better? 🤡

I believe this.fee would be better? 🐔

Lazy efficient way, I like! 👍🏼

I believe this.value would be better? 🐷

whitespace missing after @JsonProperty

Are we leaving these commented out?

This removeSession method seems to be very destructive. Could this probably be student.getListOfSessions().remove(sessionIndex)? 💥 💣

Oh shizzle mah nizzle. Roger doger!

Hahaha, wait I placed them in brackets because I'm not sure which term we should go with 😄

Maybe a typo here? 😅

Not sure if capitalization of session here would make a difference.

Not sure if capitalization of session here would make a difference since it is referring to the class Session in the javadocs.

Right I guess Java 11 is more appropriate here, unless the distinction isn't that obvious on the page.

Sounds good, we should merge the individual changes first.

Agreed, dd MMM YYYY would be more reader friendly.

Is this perhaps TuitionCard.fxml for consistency?

Not sure if it's just on my end but i notice the clear not showing up as intended.

Not sure if it's just on my end but i notice the STUDENT_PHONE_NUMBER and GUARDIAN_PHONE_NUMBER not showing up as intended inside of the block.

I believe line 121 has an extra indentation.

Works fine for me, probably some browser issue?

True, also this could possibly make use of the ℹ️ notation we have included.

Do you want to throw an error if numOfSession is less than 1 instead, easier for debugging in the future.

python? hahaha 😆

Just checking if this should be caught earlier on, before checking if overlap.

Might want to add the command deleteSession in UniqueStudentList.

I am not entirely sure if the inclusion of the seedu.address and model boxes adds much value here. Maybe the rest can look into this too!

Hmm is this change here intended? 🤔

For the architecture sequence diagram, perhaps we can change it to a more generic example that @enhao25 sent on the group so that we don't need to update if we were to change commands formatting, and to use this diagram to show the interactions that occur for all commands. ☕

Agreed, I will make the necessary changes.

Agreed, I will make changes on the next commit

Will need to write test cases for Students!

I will check again if there are conflicts with test cases. But the reason for the change was to fix a formatting for the study level field because currently some of the entries differ, eg. "P5", "Sec 2", "JC 1. I understand the consideration for possible less trivial cases like "Uni CS3230", but I believe we should standardise the format, at least for pre-generated data.

Did you mean line 80?

Possibly for use in the future to differentiate session objects, since we do not assign unique ids to sessions yet. If this is not needed I can remove it!

Yes, I wanted to check if the same student with different list would assert to be equals, however I had forgotten to change BOB back to Alice nice spot!

Yes you are right, I will resolve in the next commit!

ohmilorde thanku

Placeholder for next iteration where we add student names into session, will remove for now.

I would think so, so that we know the two panels are in sync and the first session will always be from the first student in the list. What do you think?

Good point 😊 Will make changes!

Yes correct, this is because of the OneBasedIndex that is returned in getSessionIndex(). I will add in a comment to make this clearer!

Answered in previous comment!

Thanks for spotting, will update.

Hahaha, yes I am aware, just thought that I might need to change it next time so might as well copy first. Will remove later on if it is not needed!

Were these from AB3? Okay I'll remove the extra forward slashes.

Thanks for spotting! 🙏🏻 arigathanks

Gotcha

True! I'll add in more comments to explain the functionality!

Good spot! Forgot about this, will add the corner case in. Thanks!! 😁

Okay sure, will change it!

Okay, I'll explore this later!

Have made changes under the method Student that does the operations.

Postponing this to be completed by Friday. Issue tracked in #158.

Yes agreed, added to #158

Yes not needed, but was trying to use the abstraction of a SessionDate to feed through. Will try having a dummy Time for 1.4.

Gotcha, will amend! Thanks.

Think it would be safer to postpone this to 1.4, because I'll need to abstract away from SessionDate or use a dummy time in SessionDate

Oh crap forgot about that thank you!

I briefly included it on line 378. Do you think it is better if I brought it up to line 365?

Updated #158 for this. Thanks all.

Okay I went ahead to add the extra description on line 364. Let me know if this works.

Are you referring to line 58? I am aware of that and have thought about it and decided to add it in as well since it wouldn't make sense for me to just check for the range strictly between sessionStartDate and sessionEndDate and have the method named hasOverlappingSession(), though a change in method name to hasOverlappingWithinSession() may be possible. Let me know what you think.

I have decided to leave it for now, because if I were to remove equality checks, we would have to modify some logic in our test cases. So any test cases that are of the exact same time, should not be used for the test in overlap. A little counterintuitive, but yeah let me know what you think.

Will make changes!

Thanks

Will do in 1.4! Thanks!!

Thank you good sir and mdm, I will make the necessary changes 😃

Duplicate commit

A sketch of the UML with a Tuition class that contains both Student and Session class.

Realised it doesn't add much value to @JonahhGohh's UML but here's a glimpse if anyone's interested.

I also noticed all the commands that @enhao25 changed to name it as ____StudentCommand got reverted. Is it intentional?

It is intentional if we were to follow the current implementation of Tuition class, where all student parameters are explicitly declare in the Tuition constructor.

So there will only be 1 TuitionCommand which is the AddTuitionCommand right? The rest like list, delete, find, etc are still StudentCommands?

This is a mistake, good spot, should be AddStudentCommand.

Resolved in #43

Resolved in #34

Change of implementation to hold list of session as attribute of Student class.

Dear me 😭

Closed due to change of implementation.

Resolved in #53

Pulled to #67.

Pulled to #73

Some comments on testing.

Can you add a parseSessionCommand_list() test case in AddressBookParserTest? #76

Okay! I'll add them in.

For quick reference, here's an image of the current UI:

LGTM. Not sure if we still need the d in 'd:ListStudentCommand' in your UML sequence diagram. I think that d was used in DeleteCommand and it might be confusing here. I think the best representation is to remove the 'd's all together.

Okay will make changes on the next commit

Yeap LGTM. However, there is something that I noticed when checking out the PR and testing it which is outside of the scope of this issue. The duration class allows a duration of 0. Do you think it would be better if we only allow value > 0.

Good point, I'll add a data validation for this!

Forgot to account for overlap within defined recurring period. Will continue tomorrow.

Duplicate of #139.

Merged to #158.

I have a feeling this happened from editting the json directly.

As per the UG delete_session delete session should delete tuition sessions (inclusive of recurring sessions). Perhaps the confusion is when delete_rec_session allows not to delete recurring session, but to a single session within a recurring session.

As mentioned in the UG, TutorBuddy is optimised for fast typing users with most of our controls replicable using commands.

There is no mention of clicking on the student, session, and calendar items in the UG because there is no intention of any additional functionalities at the moment. 👨🏼‍🍳

Change command feedback to "A session already exists at this time!"

Seems to work for us sorry 😭

Please don't be ridiculous 🤡

Accepted! Will need to simulate adding a session when loading from a json.

LGTM! Might do a check when we parse from json for each startup in #264 .

I think you'll have to make changes to model/UserPrefs.java as well. Doesn't seem to create tutorbuddy.json on isolated launch with these changes.

^ With the above changes, we'll probably not need to exclude preferences.json from gitignore.

Woo thanks!

Resolved in #150

Yes, not done yet

You can actually use the Equals method in this same class since the equals method checks for if method, address and tags are the same.

nice catch on the naming here

Since we are not done with EditCommand yet, perhaps we should keep this as a to-do since when we change EditCommand it may lead to some more errors here.

the space there is actually on purpose so that if you enter the commands, there has to be a space else it won't work. Unless u wanna allow them to do -xmethod

wow cool diagram

The grind for comments is real

nice addition.

why did you change this to 0?

Ohh, ok nice

minor typo? should be and it is

I think this should be called command right?

"Possible sources of error may include but are not limited to: "

might be a better way to put this

Uhh, should this be here

why is orElse used, i think a assert before this statement is more apt since there always should be a method and address, hence the method will never be empty

maybe can add a OR between the 2 examples, or can put 1. 2. ...

i think can remove these after warren does his addition

this beatify implementation does not hold if we change the toString output of feedback, endpoint or anything related to these comments. Hence I will have to reject this implementation of beautify.

this can be

show -> shows

this can be

show -> shows

do -> does?

executed -> executed by the user

nice catch on fullstop

should we add what a list is also?

yep, did not see the previous line oopps

ok i think can just merge then

ok makes sense

i see you have removed a fullstop

'Use the help command for more information' can be refactored into MEsSSAGES. Would make changing this easier

same as above

same as below

Don't worry, I do not allow duplicate endpoints, the check is as follows -> if the method and address same it is considered as a duplicate.

newline indentation must be 2 tabs wide, some checkstyle error flagged it so no choice

Once again, duplicate endpoints have been considered to issues solved

no, i got rid of all the tests using typicalendpointlist cause idk what they are for

yea, keep this in here.

nice

👍

yea i copy paste

yea, was planning to refactor this

As the QA for my company, I would like to organize my tasks so that I can identify what needs to be done next

Yay

I agree with yong liang

Don't remove the List command, it shows a complete list of all the API's after the find command. There is no way to do that after the find command is run

Okie @ong6 introduced the whitespace in PREFIX_METHOD in this commit 5 days ago so I think's best for him to do the review.

@ong6 so heres a more in depth view of whats wrong with PREFIX_METHOD = "-x "

using an example of "edit 1 -x "

when passed into the parseIndex method of ParserUtil.java, it calls

string trimmedIndex = oneBasedIndex.trim(); which trims the string to "edit 1 -x".

then because PREFIX_METHOD is "-x " (with the space), StringUtil.isNonZeroUnsignedInteger(trimmedIndex) will be true, because trimmedIndex will be equal to "1 -x", which leads an exception of the EditCommand.MESSAGE_INVALID_INDEX being thrown, instead of a more specific error message from the parseMethod method.

Also, if PREFIX_METHOD = "-x ", doing "edit 1 -t " or "edit 1 -h " does not work to remove tags/header because of the same reasons as stated above.

TLDR: there should be no space in all prefixs, unless you want to change a ton of other codde

Nice spot!

But then this would allow users to do edit 1 -tdog (without space), I guess it would be possible to remedy this somewhere else, but if I'm not wrong, the original AB3 code came with a "/t " (with space) so when changing to "-t " I kept the space as well.

However, after checking out your commit, I think that the problems that the space brings are substantial so this is a good change overall!

Uhm, I just tested it. But it seems that the clear command does not show this picture? Is it only meant to be used for list when there are no endpoints?

This is actually unfixable, due to the nature of URL's there is no way to check (for certain) if a URL exists or not

Update UI to make it look nicer?

Quotation issue, will fix

Fix: improve error message

@tjtanjin yes, there is still a response field

Some line breaks are not fixed yet, do we just accept this PR first (so we can start editing)? Thoughts @AY2021S2-CS2103T-T12-4/developers

this also, should we remove this since it's quite a low level design aspect and not really that important?

This is our last resort, only approve if I can't get it done programmatically by sat

Should this be edited or removed?

Perhaps the responsibilities for each member should be updated?

should we have an overloaded constructor?

perhaps this method may seem a little too long? maybe we could use a stream here

what is the difference between passenger and commuter?

Is this method meant to be person?

did you mean stub?

i noticed the same potential problem in the rest of the code

small thing but, perhaps this could be renamed getTripDayAsString() as we have discussed

small thing but, perhaps this could be renamed getTripTimeAsString() as we have discussed

perhaps we should call TripDay and TripTime's source.getTripDayAsString() method so as to not violate the law of demeter?

should these be the actual values in the native types?

or should these be the strings, because i believe command test util is to test the input that the user puts in (in the form of a string). To test if it is correct or wrong input

this is ok because its testing the constructor, not the command

this is ok because its testing the .equals method, not the command

i believe this should be ok, because its for the purpose of constructing a passenger

Did you mean this or is it a typo?: "@code Passenger}s"

did you mean the phone number to verify? not name.

what do you mean by "the name as a phone?"

did you mean "phone number"

i noticed the same problem as phone here.

perhaps you could add a fullstop here

fullstop here too

perhaps a fullstop here too

could this lambda have a more suitable name?

Should the message be "both pool and passenger lists have been cleared"? as suggested in issue #192

else LGTM

should these be magic literals? could we have a sample price constant from the test util classes here?

should "2.34" price literal string could be used here instead?

i noticed the same potential minor issue at other parts of the code

could we use the invalid names and invalid phone number constants that we have defined in the test utils?

should this be note instead of warning?

rectified

thanks, i have rectified this issue.

LGTM 👍 Closes #5

LGTM 👍

Resolves issue #57

update price field for add and edit command

Update methods to not violate law of demeter

PR #121 resolves the issue with unpool command working with the updated model

issue resolved with #128

#121 resolves this issue after model is updated with poolList

issue resolved with #111 as overloaded constructor inside person class is no longer required

issue is now closed because we have decided not to implement this feature, but rather another feature.

Also we are intending to change the "power users" part for CS2101

Thank you for your valuable suggestion @deyixtan, our team has discussed the use of the prefixes and has decided to stick with tag/ for the tag prefix and believe it should not take a toll on the usability of our product. Perhaps in future iterations after CS2103, we could consider relooking into this, nevertheless a good suggestion 👍

the bug report is invalid as the highlight is grey

this feels like it should be not of an issue. The purpose of the information in the editing data file section is to remind/reiterate to the reader where the data would be stored, whereas in the FAQ it would part of a frequently asked question that the reader could easily search for.

It serves two distinct purposes, and thus should not be of an issue to repeat information.

is the space supposed to be there?

should there be two seperate commands for property and appointment?

shouldn't it sort the filtered list?

should it be filterby or sortby? same for the rest below

yeah, sure

waaaah thanks for helping me update mine!!

nice!

is there supposed to be something else after the and?

would it be better to initialize it in the constructor?

i think it could be permanent, but idk

Thanks for doing this!

thanks!

why is the example usage removed?

that makes sense

i like the colour you chose

izzit possible to have something to toggle between light and dark themes?

i see

undone? idk my english is quite jialat

i think there is a typo, i think us should be is

asking price might have decimals too, would using the regex defined in asking price help?

may i know whats changed here?

waaah bro, thanks man!!!!

nice catch!

ROFLMAO

shouldn't it be FindPropertyCommand?

thanks again man!!!

would "Forgot when you are supposed to meet Simon again? Let's try finding it out!" be better?

maybe only set the text to red when the time has passed like you have already done in appointment and property card?

thanks man!

actually, would using the ArgumentTokenizer be better?

same for here

thanks man

thanks for this too!

i was thinking like the recognized fields will still be updated and shown to be updated in the list, should i phrase it differently?

personally, i think i would prefer 1 if i were a user but would also want to be alerted that there were erroneous fields however, i think it would be best to follow the add command. Like if add aborts the whole command, i think edit should abort the whole command too just to be consistent

Ahhh, pesky IDE. Thanks!

Thanks for catching it! should all be fixed now

Thats true, would changing the default values of property builder be alright though, then I wouldn't have to edit again

Thanks for catching this! should be fixed!

You have a good eye! should be fixed!

thanks! fixed!

shld be fixed!

noted, though i should warn you, i would probably be doing the same thing for appointment to keep it consistent XD

IDE complains that the variable might not be initialized if i dont put leh

that would be one way of doing it, i just find this way easier

I was thinking of using this to validate that there is only 1 new/proceed/cancel

but have not written the code out fully yet

yeah, cos it has to implement the status interface, and completion is like the end point. Is there a better way to resolve this issue?

nice catch! i used scenebuilder, it must have changed things automatically

same for this

and this

thanks!

moved it! thanks!

i think you are right, made the prefixes consistent!

removed it!

removed this too! thanks!

added more words, is it better now?

updated!

updated too! thanks for catching it!

added the code to ensure that there is only 1 new/proceed/cancel

oh yeah, nice catch!

added a check to raise an exception if proceed is used on a property with a Completion status

moved it!

same as above

oh yeah! thats a good idea! thanks!

Revamped the prefixes!

yeah, these too

Nice catch! thanks will change it

yepp!

yeah, yet to learn plantUML will add next week

maybe we can tackle find in another pr?

its just a convenience function, i can use the static variable as well but it would look like "String.format(MESSAGE_MISSING_ALL_PROPERTY_APPOINTMENT, command, command, command,

            command, command, command)"

i see

changed it!

ok! changed it!

i tried my best to match the find format!

I tried elaborating more, Is there a better way to phrase it? Was wondering if adding Option, Sales Agreement, Completion to the glossary would be good as well

added in elaboration!

added in a table!

i tried my best to follow it

changed the table to a list

oops i was being too lazy, changed it!

ooooh nice thanks! added it!

oh yeah! nice! thanks! added it!

should I close this pull request?

LGTM, thanks for the tremendous effort

i think the refactoring is pretty good, can make things easier

open to suggestion for colours as well, I can try modifying the whole thing to be more like a light theme oso. I just generally prefer dark themes.

i think can lose the underline, maybe the bold isn't needed oso. I was just confused why every date was red

in that case, i think just bold is enough underline looks a little ugly to me

@candyhy what do you think of this thinking

I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either

what colour would you suggest?

can I also suggest keeping the text wrapping fixes and changes to Ui as separate pull requests? cos I think its imperative to fix the text wrapping but the Ui may not be satisfactory yet

created a separate pr for text wrap!

LGTM but do you want to put the class diagram as a separate PR since you are not using it in the UG yet?

oops, my bad. Removed it!

@candyhy what do you think of this thinking

I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either

what colour would you suggest?

I think its better to keep the background white/black. shouldn't have more than 3 colours in a Ui in my opinion

like this?

or this?

This shouldn't be execute(undo) right

I think should enclose the parameter in quotes cuz its supposed to be a string

should be dotted line for returning

This is a constructor call, so the label shouldn't be 600000 I think. Either leave it blank or change it to a call to create a new Option object

should be dotted line for returning

missing returning dotted line (if everywhere else has a returning dotted line, then u should probably include one here too)

Thanks! I will fix 1-6 but for 7 i was thinking that cos its a void method and doesn't return anything so I omitted it

Your diagram:

My diagram:

For this, I do agree that the 3 child classes should have a composition relationship with Offer, and I will update my diagram. But do you think there should be a dependency arrow from Status to Offer as well?

I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status

the updated sequence diagram

I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status

Ohh, because I thought Status has a method returning an Offer object. Hmm, not really sure whether to include this dependency arrow...

Oh yeah! I forgot about that, that method isn't currently being used now should i remove it? If it shouldn't be removed then i will add the dependency arrow

I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status

Ohh, because I thought Status has a method returning an Offer object. Hmm, not really sure whether to include this dependency arrow...

Oh yeah! I forgot about that, that method isn't currently being used now should i remove it? If it shouldn't be removed then i will add the dependency arrow

Ohh, its not being used? Then ya please remove and I will update my diagram. Thanks!

I just removed it!

oops, got merge conflict now

Correct me if I'm wrong - DisplayFilterPredicate.test() will return true if field is specified, and only these specified fields will be set as visible and managed. If that is the case, can I clarify what you meant by "returns true (...) should be hidden"?

Looks good to me 👍

Just spotted this: "@param displayFilterPredicate that returns true if prefix linked control should be hidden",

looks to be the same mistake as before (ie. returns true if (...) should be shown). Maybe check the other areas where this line was copy-pasted, to see if there are other uncaught ones.

Just spotted this: "@param displayFilterPredicate that returns true if prefix linked control should be hidden",

looks to be the same mistake as before (ie. returns true if (...) should be shown).

Correct me if I'm wrong - this Command class is different from the one in address/logic/commands right? There is one Command class in that path, so I'm not sure if having two classes of the same name would be confusing.

Good point, thanks for the explanation. No problem here then.

Maybe rename the boolean variables to eg. isX, so that the variable name immediately implies a boolean value. In general it is clear that these are boolean values, but perhaps a rename would be safer to comply with the textbook recommendation.

Your suggestion sounds good to me!

I am aware that some of the pre-existing boolean variables from AB3 might not seem to exactly comply with the textbook recommendation, and have thought about just leaving the variable names as is. However, I currently feel that it is better to err on the safe side, as it is always possible for the reviewer to argue that "just because it was originally named this way, doesn't mean it is correct". What is your opinion on this matter?

Nice, LGTM now! Will be marking this conversation as resolved.

Maybe it would be easier for the reader to understand what this line means, by providing an example of how the index of the focused contact can be autofilled. At the moment, it might be difficult to visualize how this feature works (referring to the point on autofilling index).

Slight typo for component

Maybe capitalize Tab for consistency with the other two keys?

Perhaps rename this to better imply that this is a boolean.

Should be "[INDEX]..." instead.

Slight grammar issue: person should be persons instead

Might be good to specify highlight to be green, since specificity helps a lot in UG.

Same slight formatting issue for [INDEX...] as mentioned.

Slight grammar issue: return message should include persons instead.

Oh okay, I was referencing this clause in our UG, so I made the suggestion for consistency with our UG.

That makes sense, I think original notation [INDEX…] should be fine, as long as it is explained what that means in the UG.

That's fine then, the image should do the job well too.

Yeap looks good to me!

Would it be better to include this line as part of "Notes on email command:", to be consistent with the rest of the commands?

Not sure if this was intended, but the Other Commands | coming soon is not in its own row.

Perhaps change audiences to users to maintain consistency with the rest of the UG.

text base -> text-based

CLI based -> CLI-based,

command that are -> commands that are

multiple optional argument -> multiple optional arguments

each argument are -> each argument is

Perhaps change one-and only one- to just only one, and bold it to retain the emphasis of only one item being allowed. I understand that one and only one has a specific technical definition, but non-techie readers probably will not understand the technical meaning, and will likely think that we are just being overly verbose.

Just my opinion on this, not a major issue at all. Feel free to ignore if you disagree.

(yes, person objects that a user has to scroll down to are selected) is written in a different tone than the rest of the UG, which the user might find jarring or informal.

Let me know if the following suggestion explain shown properly:

(the visible person list refers to the entire list, if it is too long, the user might have to scroll through the list to view all the selected persons)

Maybe change scroll down to scroll through, as the scroll direction depends on which part of the list the user is currently at.

Good catch, will be merging after fixing the typo.

Oops, forgotten to include it in my PR description. I provided the reasoning in the relevant commit message, so I'm going to paste it here:

This change fixes bug where parser previously cannot distinguish

between eg. -p and -pp. Now, the parser can differentiate between

-p and -pp , as -p is not a front substring of -pp due to

the whitespace char at the end of -p .

Accordingly, AddressBookParser has been modified such that it only

removes leading whitespaces, and no longer removes trailing

whitespaces. This is to account for optional options such as -r ,

where -r will not be registered as a valid key since the

whitespace char is trimmed away before the parsing of keys.

Not removing trailing whitespaces should not affect the eventual

values of the keys, as tokenizer will still trim the parsed value

before returning it. ie -a test street still results in

the address value being test street, without trailing spaces.

LGTM

LGTM!

I realised that the help text for add command does not include spaces between the flag and the value. I'm guessing the edit command will have this issue too

Thanks for catching this. I'll fix it up in my next PR, after checking the other commands that might be affected.

@oeiyiping will you be updating the diagrams for your changes to Remarks?

Was intending to settle diagrams in 1.4. Unless we are aiming to complete diagrams in this milestone?

After testing the new prefix parsing implemented in this PR, I think there are fundamentally a few problems here, especially with the filter and alias command.

The filter command is having trouble working as intended. For example, if I want to filter by address, I would need to input filter -a with whitespace behind.

Similar, typing filter should clear all existing filters. However, without trimming the trailing whitespaces, the filter command will recognise the command slightly different and instead filter the list of persons to show just the name.

Alias commands are also having problems when parsing and checking the validity of the commands to be aliased.

Thanks for pointing the errors out, I should not have assumed that these cases are already accounted for in the current testcases. I will see how else I can fix this bug while preserving the Bash-like format. Changing this PR to draft until then.

Will need to update helpMessage.png to reflect the new user guide.

Are you going to be packaging the HTML pages for offline viewing? If so, what is the implementation?

Sure, will update the image file accordingly.

I am not intending to push the offline implementation in this milestone. Current intention is to implement an offline alternative in 1.4 as a refactor, as I intend to explore other options of implementation.

Looks good overall, aside from the following matters:

Out-of-bounds index does not return any error message in ABB, and there is no other indication that the input index is invalid.

Might be good to reference the error behaviour in delete command for consistency.

Some minor docs issues.

I feel that it would it be good to include a disclaimer in ABB itself and/or in the UG stating that the email command is only valid if the user has an OS mail app, and is logged into a valid account in said mail app. What do you think?

For point 3, I'm not exactly sure that is within our control? I've tried on Windows (logged in), macOS (logged in), Ubuntu (not logged in, Thunderbird installed) and on Ubuntu.

On Ubuntu, it will first open up the default browser (FireFox) and subsequently opening up Thunderbird, prompting me to login.

So I believe that on most OS, if the user is not logged in, the mail client will prompt the user. I feel that I don't have to document that down.

Yeah I agree with your point, just thought it would be good to err on the safe side. Agree that this seems unnecessary, but I feel that it can serve as a fair warning to prevent "non-techies" from blaming us for what they (mistakenly) feel is a flaw in our app. What I had in mind is just a one-liner disclaimer eg. "The user must be logged into an email application to benefit from this feature.".

Hi Prof Damith, the javafx webkit and media packages are used to open HTML files from within the app. Our intention is to allow users to open the user guide (which is a .html file) directly within the app itself. May I know if the large file size is an issue (and negatively affect the grading)? If so, we will remove the packages and explore other options.

Closing this PR down, will be resolving this issue on a new PR.

I noticed this as well, I found out that this always occurs after using SceneBuilder (probably auto-edited the fxml file to be v15). Did not encounter any issue regarding this matter, but I feel that we should edit the affected fxml files back to v11 before submission.

extra space before />

Is the space intended to be there?

Missing space

Why call it ProjectsFolder instead of something like ProjectList?

Extra quotation marks?

here can perhaps use Project.addEvent()? since it does not seem to be used anywhere

This is not a problem with the test but I think we should put project name instead of project is the message?

Perhaps we can change all occurences of Index.fromOneBased(1) to INDEX_FIRST in this file?

To be consistent, 1 should not be bold

Perhaps it is better to put this under a level 3 heading named others or something? It looks a bit strange to me to have a level 4 heading parallel with level 3 headings.

According to seedu md standard, we should put an empty line after each heading:

same here

Should this be Contact List instead since we have only one such list?

Yes! That would be nice!

Perhaps successful or succeeded?

here also

It seems that other commands' MESSAGE_SUCCESS do not capitalize all words

Ohh okay sure! Then I think can leave it like this!

My bad, forgot to change this line after copying from the sample.

@samuelfangjw Changed as requested!

General hashcode contract states that

When hashcode is called repeatedly on an object, should return same result unless object has been modified.

Two objects that are equal (according to equals method) should return the same hashcode

Different objects do not have to return the same hashcode, although it's good if it does so.

Wah I never knew there is such a contract. Will do it tomorrow!

For the third point I think it should be the other way round. Objects that are not equal should return different hashcodes as far as possible.

I think it should still be pretty safe to check for different hashcodes for different objects since it should be quite unlikely to collide. Do you think we should remove this check?

Tested on all modern hardware we have access to.

Agreed

wah this is complicated, do you want to split it one by one before return

A complicated return also

tks for this change

You forgot to include the project-index in this message_usage

As Samueal commented on my PR before, the getZeroBased method alr checks for negative value, so this is unnecessary

tks for the change

I'm not sure about this 2, one you taken from address field right, and the original I take from project name.

I think for the rest of the pr, it's ok

hey samuel I'm not sure about this, but as I see it from javadoc format of other methods, there should be a blank line between description of method and parameter, return, throw

I think this is a complicated boolean expression as code quality says about it. You can choose to keep that or separate them 1 by 1

should this have a javadoc

this 2 method missing javadoc also, as for other builder, you put javadoc for constructor also

Ahhh, OK I think that is all I can spot for now. For cases to test, I cannot think of other cases to add.

add a blank line in javadoc

leave a blank line here too

here also

can we use requirenonnull for this

0 here sounds a little bit like a magic number here, should you put another variable for it?

1 here also

Here are the variable for it right. you can mention it if possible

leave blank line

can we use !requrireNonNull here

I think for the rest I agree

I think this should be userInputInvalidProjectIndex

This should be userInputInvalidTodoIndex also

I think here should rename also so that it refers to index of project not project.

This one's javadoc should have a return statement

This one also

add blank line for javadoc

here also

yeah i think its weird yesterday too, but not sure thanks for the comment

@vevek Am i addressing your full name correctly

resolved

ah for this actually the invalid format is thrown above

the parseIndex has its own exception throw for invalid Index. So no problem with this, and actually I change it because if invalid index, the correct exception should be thrown (invalid index), not (invalid fomat)

resolved

Closes #22

Great work 😃 . Can I also suggest adding the role "Developer" to everyone. I feel that it would help reflect our roles clearly.

Agreed

Cannot merge because of irrelevance to the project

closes #5

Omg i just did it again. So sorry @vevek 😃))

closes #49

i have implemented the addEto command. Please give some input. For the codecov test, that might be because of missing tests. For now, you guys can comment on any logic faults in my code. I will try my best to complete the documentation and the tests for this command asap.

And also, i have tried out the code but seems like only the command result shown up. Is it because of the ui not ready yet? Or maybe I don't know how to make that shown up. Please let me know.

This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.

/by is an optional parameter so no need in the example

closes #316

I'm a little confused about why current_password is wrapped in square brackets. Does this mean that if a password has not been set, then unlock command does not need a password?

For the return statement of this method, the comments helped me to understand the code easily which is already great, but I was thinking whether the expression would be a little less complicated if you separate the boolean statement into multiple named boolean variables.

For example


    @Override

    public boolean equals(Object other) {

        isSameObject = other == this;

        if (isSameObject) {

            return true;

        } else {

            isLockCommandObj = other instanceof LockCommand; // instanceof handles nulls

            isCurrentPasswordEqual = currentPassword.equals(((LockCommand) other).currentPassword);

            isNewPasswordEqual = newPassword.equals(((LockCommand) other).newPassword);



            return isSameObject || (isLockCommandObj && isCurrentPasswordEqual && isNewPasswordEqual);

        }

    }

If we remove the password here, does that mean that every time the user unlocks the ClientBook, the next time he locks he needs to set a password again?

If that's the case, then I'm thinking if it is possible that we don't remove password on unlock and store the password, so the user only needs to specify a password for the lock command when he/she first adds or changes his/her password. Then subsequently, if he/she locks and unlocks it will just use the same pasword.

edit: after thinking about this more, I realised that its not so easy to store the password securely within the app (I was thinking in UserPrefs? but not sure if it is secure or even possible), and perhaps this one time lock and unlock is enough. What do you think?

This method is fine, but are the 2 try-catch blocks are mainly to differentiate between the 2 types of exceptions? I was thinking whether you can condense it into one try-catch block, and in the catch block, you differentiate the 2 cases using the ZipException that was caught.

Actually I was looking at the docs, and found that they didn't really specify what ZipException each method threw, but on their ZipException class, there is a getType() method, which returns a ZipException.Type. (https://javadoc.io/static/net.lingala.zip4j/zip4j/2.7.0/net/lingala/zip4j/exception/ZipException.Type.html)

Perhaps you could check if it is possible to differentiate the cases by checking the exception type? If not then your method is completely fine as it is

Just a little bit of unnecessary white space 😃

Is there some reason you chose to overload the attemptUnzip() method with this? It seems to me that you could directly call attemptUnzip("") where you want to call this method.

I see, that makes sense. Perhaps it could be clearer if you leave a comment or rename the method to indicate that it is for cases where no password was involved?

I see, since the API doesn't specify then it's difficult to catch the different cases ourselves. In that case then two try-catch blocks is a nice way to circumvent that👍🏼

I agree that the effort to reward ratio is pretty low since it's not a particularly core feature of our application. In that case, let's keep this extension in mind, and if we have time after other core features then we can possibly come back to it in the future.

I see, then let's follow the format 😁

For the name of this method, I was wondering if the name may be slightly inconsistent with the other get methods of this class, since other get methods in this class returns the object, while this method returns String. A suggestion would be to name it something like nameAndPoliciesToString()

There seems to be a lot of white space here. Is there a reason you chose to have a new line after each of the statements?

Do you think that naming this method formatOuterBox() is more specific? since there are other VBox instances in other classes or if we extend the UI

I see, I think I didn't notice the line breaks were separating each of the variables/objects. now it makes sense!

I suggest changing this to ATTRIBUTE, since we used attribute to specify in other parts of the document

Similar to the previous comment, I suggest using ATTRIBUTE instead of property

This line is a bit confusing, may be instead of "more than 1", it is more suitable to be "at least 1"? Alternatively, we can also say "index must be within the numbers listed on the clientbook"?

A little nitpicking, but instead of leaving it as the default case, it might be better to specify each specific case, like

The CURRENT_PASSWORD field can be omitted if ClientBook is not yet locked.
When CURRENT_PASSWORD and NEW_PASSWORD are both specified, ClientBook verifies the current password before locking ClientBook with the new password. >- specifying this case instead of leaving it as default case
When CURRENT_PASSWORD and NEW_PASSWORD fields are both omitted, ClientBook will attempt to lock itself using the last used password that is safely stored on your device.

Awesome addition of the column!

By the way, I tried to update the data directly from the json file, but not sure if it is because of the zip, but it doesn't work. After I change the json file, I start up the app and it goes back to the previous state. Maybe you guys can test it also, and if it doesn't work, we just remove the "Advanced users are welcome to update data directly by editing that data file." part

Is the name isShowShortcuts a little confusing? I realise the original AB3 code uses show... as booleans but I wonder if there is a more intuitive name? (if you feel its okay then can leave it as it is)

shortCutCommand equality doesn't seem to be checked in this equals method

From the name of this method, it seems that it is a duplicate of the equals method. Upon looking at the comment, if this method only checks name, then a suggestion would be to name this method isSameShortcutName()

Is there a better alternative to having these methods empty? If they are not going to be called, perhaps you could throw an assertionError? If not it is also fine if it doesn't affect the test cases.

In this method, I got a little confused because the Shortcut object was named shortcut, while the List>JsonAdaptedShortcut> is called shortcuts. A suggestion is to name the List>JsonAdaptedShortcut> jsonAdaptedShortcuts instead.

No problem!

For these 2 methods, I thought it might be slightly inconsistent that all the other methods in ParserUtil class named parse... parses some string into an object, while these two methods trims whitespace and checks validity. I personally suggest renaming them to isValidShortcutName/Command. What do you think?

Some more empty methods where you might want to throw AssertionError if they are not supposed to be called.

Another empty method where you might want to throw AssertionError if they are not supposed to be called.

Made the changes to differentiate command words in this section in the latest commit

Added tags back in

Added the quick start into the user guide, but release is not yet ready.

Great suggestion, done!

Great suggestion, made the change.

Done!

Good point, done!

Ah right that makes sense, will change it

Edit: after thinking about it, i realise that putting it like that might imply that a flag can be specified for each policy, since the user can put in multiple policies. My implementation was no matter how many policies you put, you can only set 1 flag. e.g. i/P123 i/P321 -remove removes both

Done!

Just did some testing, feature works perfectly! The only small issue is when you input unlock without any parameters, the feedback message to user is


Invalid command format! 

lock: Locks ClientBook with a password.

Parameters: CURRENT_PASSWORD(if any) NEW_PASSWORD

Example: lock 12345

And also I think maybe it would make it clearer for the user if we add in the user guide a sentence to specify that when lock is used without parameters, then it will be locked with the current stored password.

After these 2 then its LGTM for me!

For LICENSE, there's no need to change person to task.

For README, the AddressBook should not be changed since we are referencing the original.

For this one, I think its best to get rid of this line if we don't have a team email.

I think we should keep addressbook in this file. The link might break and we're still not sure how DevOps will change from here.

Likewise for this one, I'm of the opinion we should keep the addressbook here

I think we should delete the tutorial docs from our repo since they are unlikely to have any purpose in the future.

I think this unused code block has to be removed.

I wouldn't describe sorting as replace task in javadoc.

Personally, I prefer to initialise both index and tags in the constructor. But I'll leave it up to you to decide.

I don't think all the other prefixes (apart from PREFIX_TAG) are necessary under tokenize method.

I think the UG should also mention what happens when the time is not keyed in. E.g. The current time on your computer is taken.

I recommend moving this block of code to before editedTask. Avoids unnecessary generation of the editedTask object if there's no tag to delete.

Not sure why there is a new Use case 9 right before the NFR section.

Nice to see the new commands here. But I think the new mod command for finding by module should be included + the top list of commands and bottom summary should also be updated before the UG update is complete

To add on, maybe the valid module criteria should be listed at the top of the UG, before the instructions. But I think it can be added in later.

Not sure why there's a minus sign here

I see. Sounds good

I have a few questions:

Wouldn't the edit command suffice for changing the recurrence of a task?
If we decide to keep the recur command, is there a way to remove recurrence without using edit command? I think users may be confused as to why the way to remove recurrence is not obvious.

Actually, for 1, scratch the question. We also have a tag command and edit command that can handle tag changes.

If it works, I guess it can be used

I think this link can be kept, but it has to be changed back to AddressBook level 4 since that was the original project from which this came out.

Same scenario as the one for ModuleCard

Looks good, although I think the line for empty recurrence should also mention that the prefix r/ must be kept.

I think the new modules should also be included in the UG table

I think the UG Features section should also be updated to describe the task colours.

Noticed a spelling mistake mut instead of must.

I think "You may contain multiple keywords." should be changed to "You may key in multiple keywords"

Nice!

Not sure what you mean by "follow its format"? Does it mean that the optional parameters have to be in the order shown in the format?

In my last edit to the UG, I added seconds to some examples. If we are getting rid of seconds, we need to remove them from the command examples.

To clarify, the module field should be changed to a proper module code?

To clarify, is the deadline here supposed to change?

I assume here the ADDRESS should be changed to DESCRIPTION. Is there any other changes to make?

I was considering using enum but I couldn't get the constructors to work. Maybe I'll look into it in v1.3.

I've changed it to show how many tasks there are across all 3 workload ratings for a single module.

Just to clarify, it's just re-add the original workload count implementation?

So we have:

-One variable counting how many low workload tasks there are

-One for medium workload tasks

-One for high workload tasks

-One that sums up the workload rating translated to int

I chose to mention learning portal here since some features of MB-3.5 can also be found in LumiNUS (like showing which tasks have closer deadlines). Not sure what else to add though.

If I'm not wrong, how markdown works is that the 1s here would automatically be converted to 1,2,3,4...

So it's a deliberate choice.

I chose to add it so that it's more obvious that its referring to workload. Looking at the original task details could be somewhat disorienting

Pull request closed to avoid accidental merging into the team repo.

Pull request closed given that changes are small. All changes are moved to the done status PR

I just swapped out the modulebook.jar file.

I think what happened was the build process was done on a branch that was not updated. Remember to pull the team master branch into your local repos and forks.

Personally, I think that if 2 commands share the exact same functionality, we might as well keep to one single command.

Duplicate #164

Thank you for the report.

At the time of the PED, we are still finalising the GUI colours. Therefore, we chose to defer updating the GUI descriptions till v1.4

Duplicate #186

Duplicate #166

Related #159

Related #181

Related #148

Related #159

Related #174

Issue closed due to link mentioned above.

Closed due to link mention above

Related to #182

I also don't think any normal user would put a date that is all the way in the past anyway.

Closed for deferral to beyond v1.4

Closed for deferral to beyond v1.4 and to reduce issue tracker clutter

Closed for deferral to beyond v1.4 and to reduce issue tracker clutter.

Closed for deferral to beyond v1.4 and to reduce issue clutter tracker.

Closed for deferral to beyond v1.4 and to reduce issue tracker clutter.

Related to #165

Add-on based on reports from related issues: To update user guide images to include latest GUI + resize to fit entire screen

It's an IllegalArgumentException that was not propagated to the GUI.

Specifically, it was generated during the attempt at generating new Tag() in the FindTagCommandParser.

This is most likely a case where the user guide wasn't clearly written to explain that only the absolute last argument for duplicate parameters is taken, regardless of its validity as well as the validity of other arguments.

More module codes have been added. Currently, we cannot make modules optional so if professionals wish to use this app, I would recommend using any supported module code as a decoy.

Issue closed.

We may come back to this in a future update. Issue closed since it is not within the scope of v1.4

Closed because graph centering is not that important as a feature flaw.

UG has been updated to include summary table of prefixes.

Closed because changing the way deadline validity is tested is beyond the scope of v1.4

LGTM

Solved

Includes respective parsers (especially RecurCommandParser)

overall LGTM!

Just a question, the size of the new images have been fixed too right as they are v small in our current UG haha

I did the screenshots in full window. Shouldn't be a problem.

Users are most likely going to key in different parameters. It's unlikely anyone would key in the same parameters but even if they do, it's most likely intentional and the tasks are not altered in any significant way.

Either way, I think the severity of this should be much lower.

LGTM

For a very large integer like "100000000000000", it appears to be a limitation from Java's own parseInt() method, but I noticed that the error message for signed and zero integers was too general.


        Use case ends.


        1a1. HippoCampus shows an error message.

        Use case ends.

Extra space.


            + "for more information refer to https://ay2021s2-cs2103-w16-3.github.io/tp/UserGuide.html\n"

Extra newline.


            + "help [COMMAND]";

Missing exit command.


            + "edit INDEX [-n NAME] [-p PHONE_NUMBER] [-e EMAIL] [-a ADDRESS] [-t TAG]…\u200B [-b BIRTHDAY]\n"

            + "Exiting application: "

            + "exit\n"

This is a little confusing. By deleting the contact when no more tags exists, it suggests that contacts cannot have no tags. But what about a workflow where user wants to delete all tags, then assign new tags from scratch?

Should the delete -t command just deal with tag deletion alone, and not touch contact deletion at all?

I think using the current add, find, delete for contact processing is a good idea, like what you mentioned. That's essentially the existing commit: "deletes all contacts with at least one of colleague or cs2103 tags".

It's the proposed change that I don't quite catch, i.e. "delete tags in contact + delete contact if there is an exact tag match".

PS: On this note, going by your suggestion to use tags exclusively for tag, we can do tag deletion using the same command, e.g. tags -d -t colleague -t cs2103. Sounds like a pretty self-consistent idea.

Cos the happy path is to delete the contact. Then ONLY IF it is tagged with another tag then the contact is not deleted.

What about the case where I want to delete all people with that tag? I can't quite think of a viable workaround for this, except manually searching for and deleting the person, e.g.,


# Removing everyone tagged A requires `delete 1 2` instead of `delete -t A`

1. John (tag: A)

2. Grace (tag: A, B)

3. Bob (tag: B)

But I guess these issues only arose because we didn't define the feature well enough in the feature request.

Missing space.


            + "Example: " + COMMAND_WORD + " -n Bob -t CS2030";

Probably an extension of using string validation, difficult to predict all possible user errors.

Might want to change to } else { style recommended in this module.

Screenshot of what @garyljj is referring to:


     * Parses a {@code String remark} into a {@code Remark}.


     * @throws ParseException if the given {@code Remark} is invalid.

Perhaps best of both worlds: "You can write anything in the remarks, as long as it is not blank".

Perhaps a more natural phrasing?


    public static final String MESSAGE_DELETE_PERSON_SUCCESS = "Deleted the following people: %1$s";

Might have to consider a different phrasing later, once the --append flag for tags is added in as well. Should be fine for now.


            + "OR " + COMMAND_WORD + " " + FLAG_REMOVE + ": Removes specified tag from all people in the filtered list.\n"

The recursive string concatenation is technically quadratic here, though it's probably negligible for small number of Strings. Can consider .map(...).collect(Collectors.joining(", ")); from this SO post.

If implementing, can consider allowing removeTagFromPerson to return a boolean reflecting the tag removal success, just like the boolean isEdited = tags.remove(targetTag); line you used in line 49.

On a related note, since model.addState() should not be called if no tag removal operations were performed, I think doing the check would be a good idea. Ties in with the same idea.

Sure. If got time, I can probably do a quick separate PR for all occurrences.

There is an existing predicate for tag testing, if intending to integrate with the existing Person model. Will require addition of a new predicate to separately check for all tags.


    for (Tag t: targetTags) {

        Predicate<Person> predicate = new TagsContainExactTagPredicate(t.tagName);

        for (Person person: personList) {  // this can be refactored into separate method as usual

            if (predicate.test(person)) {

                deletedPersons.add(person);

            }

        }

    }


     * @throws ParseException If an error occurs during parsing.


            PREFIX_DATE, event.getEventDate().value,

Update EventDate attribute reference, changed after refactoring of Date object in #180.

I'm amazed that this works, because I don't actually see the overloaded method in KeyCombination

Scratch that, it's the KeyCodeCombination class, not KeyCombination

@zhengruoxin yup, also noted here. I couldn't find a way to solve this invalid date mapping problem, without having to move towards manual date parsing. Was planning to document this quirk in the UserGuide and leave it be, since adding the wrong date is not within normal use anyway.

Sounds good, it should be more efficient that way. Will make the change.

This should be better:

Assuming in typical use scenarios, the number of unique indices specified is not large (pretty unlikely)
Since the application does not require strong performance optimization, readability should be a priority

Will apply suggestion and merge.

Remove references to HashSet with change in algorithm, discussed below.

Yes, very much intended, because sorting in "reverse upcoming" doesn't seem to have a use case. Will be documenting this eventually.

Think it's a good idea to support it?

Thanks for the suggestion! Implemented the alternative algorithm as separately discussed earlier, see upcoming commit.

Good catch thanks! This is a bug inherited from AB3.

'''suggestion

private static final String SPECIAL_CHARACTERS = "!#$%&'*+/=?'{|}~^.-_";

'''

Non-functional requirements

Quality requirement: HippoCampus should be usable by a novice who has never used a CLI addressbook before.

HippoCampus should be able to hold up to 1000 contacts without noticeable sluggishness in performance for typical usage.

Should store data locally only, in a human editable text file, for privacy reasons.

Technical requirements: HippoCampus should work on any mainstream OS with minimally Java 11 installed.

Notes about project scope: Should only be for a single user and should not require interaction with other users of HippoCampus.

A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.

The source code should be open source.

Glossary: Mainstream OS: Windows, Linus, Unix, OS-X

Duplicate of #17

Duplicate of #19

Description expanded in #22 #23 #24

LGTM

No guarantees it'll work right out the box, but it's a start.

Confirmed working. Can close once all checks are done.

@nickyfoo commit at d1d7501. All completed.

Adhere to more generic command line conventions

For a more extreme (cherry-picked) examples, see these workflow runs:

MacOS delayed the check completion due to running 4+ mins.

Alternatives to dropping workflows include using skip actions keyword in commit message to skip tests, but not a healthy habit to adopt.

Reference: https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

LGTM

Courtesy of @nickyfoo, cannot reduce automated tests until one iteration is complete, for grading purposes:

https://nus-cs2103-ay2021s2.github.io/website/admin/appendixE-gitHub.html#tp-workflow

After following the given workflow for at least one iteration, optionally, you may adjust the process rigor to suit your team's pace. Here are some examples:

Reduce automated tests: Automated tests have benefits, but they can be a pain to write/maintain. It is OK to get rid of some of the troublesome tests and rely more on manual testing instead. The less automated tests you have, the higher the risk of regressions; but it may be an acceptable trade-off under the circumstances if tests are slowing you down too much. There is no direct penalty for removing tests. Also note our expectation on test code.

Reduce automated checks: You can also reduce the rigor of checkstyle checks to expedite PR processing.

Switch to a lighter workflow: While forking workflow is the safest (and is recommended), it is also rather heavy. You may switch to a simpler workflow if the forking workflow if you wish. Refer the textbook to find more about alternative workflows: feature branches workflow, centralized workflow. Even if you do switch, we still recommend that you use PR reviews, at least for PRs affecting others' features.

Can postpone discussion until the time comes.

Duplicate feature already present as a Tag in AB3.

Duplicate of clear feature already present in AB3.

In particular, adjusting sample data to follow new functionality.

@zhengruoxin perhaps some ideas on additional datetime formats that we can provide: https://github.com/pyuxiang/ip/blob/master/src/main/java/duke/parser/DatetimeParser.java

Probably here, where the dimensions for the result display are specified:

https://github.com/AY2021S2-CS2103-W16-3/tp/blob/1d205c019aa61650b61f437bc8d77a82bfa0b5c2/src/main/resources/view/MainWindow.fxml#L42-L47

Overall window size seems to be specified here:

https://github.com/AY2021S2-CS2103-W16-3/tp/blob/1d205c019aa61650b61f437bc8d77a82bfa0b5c2/src/main/java/seedu/address/commons/core/GuiSettings.java#L11-L14

Experimented a little with dynamic resizing by setting VGROW to ALWAYS, but it scales together with the person list UI pane, which seemed a little weird: there is no longer an intuitive fixed reference by which the application grows.

For more text, I think the more appropriate action is to limit help text to at most 4 lines.

According to the UserGuide, we're also removing the need for -n to specify the name, i.e. add John instead of add -n John, but not yet implemented. We can open a separate issue for this.

Also need to change the help message.

Issue #81 opened to address the -n prefix issue.

@Ellevy mentioned that find and edit also use the same -n prefix, can maintain in add for consistency.

The todo is now to change the syntax in the documentation to include the -n prefix.

Courtesy of @glennljs: Issue only happens when gradle run command is used. If built normally and open the jar, it works fine. Perhaps grade adds the font as a separate resource internally.

If not fixing, can assign tag::wontfix, remove the priority label, and close the issue.

Duplicate of #49

Duplicate of #67

PR erroneously requested, closed.

Note that merging this is a big priority - will introduce a lot of merge conflicts with subsequent PRs.

Doesn't the current algorithm involve iterating through the list to check for tags? A quick is_tag_found boolean flag probably works.

If want to extend to existence of multiple tags, can create a boolean flag array as well.

Duplicate of #86.

Any suggestions to implement this? Thinking of an InputHistory class native to the parser / executor class. Probably also need to register event handlers for up/down arrow keys in the input field box, see this SO post for a possible implementation guide.

@zhengruoxin just a heads up, in case you're busy, I'm currently working on a new PR to incorporate the use of LocalDate for validation. Should be done by today.

On Fri, 12 Mar 2021, 13:06 Zheng Ruoxin, @.***> wrote:

@.**** commented on this pull request.

In src/main/java/seedu/hippocampus/model/person/Birthday.java >https://github.com/AY2021S2-CS2103-W16-3/tp/pull/88#discussion_r592912610> :
   value = EMPTY_BIRTHDAY_STRING;
   isEmpty = true;
}

/**
* Returns true if a given birthday is an empty birthday.
*/
public static boolean isEmptyBirthday(Birthday birthday) {
   return birthday.isEmpty;
}

/**
* Returns true if a given string is a valid email.
*/
public static boolean isValidBirthday(String test) {
   return (test.toCharArray()[4] == '-') && (test.toCharArray()[7] == '-');
That's true. I considered LocalDate but wanted to keep to standardising using isValidBirthday boolean to check for validity. Will try to see if I can use both, else will switch to LocalDate. Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub >https://github.com/AY2021S2-CS2103-W16-3/tp/pull/88#discussion_r592912610>, or unsubscribe >https://github.com/notifications/unsubscribe-auth/AG2V5DVZTIYF25ESV2G6A2TTDGOMZANCNFSM4Y34E7SA> .

Doing iterative addition of features, sample data will be updated concurrently. Not a singular feature.

Personally I'd avoid the highly ambiguous "11 Dec 02", partly because it's uncommon, and will succeed without raising errors for international users whose local formats follow "yy/mm/dd" instead of "dd/mm/yy". Perhaps enforcing the "yyyy" format will catch potential errors, or another option would be to allow users to customize the desired date format.

This might be a good reference: https://en.wikipedia.org/wiki/Date_format_by_country

Perhaps the formats we might want to support include the predominant little endian DMY format (exception is ISO format which should always be supported):

"yyyy-mm-dd" ISO-8601
"d.m.yyyy" German, Russian
"d/m/yyyy" French, Spanish
"d-m-yyyy" Hindi

with the associated long forms:

"mmm d yyyy" USA (+ "mmmm d yyyy")
"d mmm yyyy" Singapore (+ "d mmmm yyyy")

Closed, not implementing, since bottleneck is no longer workflow runs, but PR reviewing itself.

Implemented by #96

Is the deletion done across the board, or just for the filtered list?

Got confused a little: Isn't the undo command feature part of your PR, and not yet integrated into the master branch? Can raise this issue in the PR first, then open an issue from there if not implemented.

What's the syntax to test this?

Courtesy of @nickyfoo: Just "undo". It will undo the last change to the AB (by add, delete, edit or clear).

INFO: Added state to stateHistory. Current number of states is: 2. Currently on state: 1 is the logged message. Seems like we can have a feature to easily redo as well.

Merge master branch by updating newly introduced Remark feature to include long-form "--remark" prefix in CliSyntax.

As per previous discussion, this GUI design will be phased out in favor of Event cards (see commit 02452dd).

Part of the reason includes: (1) lack of horizontal real estate, (2) not a critical feature (selection of tags will be supported by commands in the upcoming PR #116).

Depends on which we choose to implement. The alternative, with perhaps the flag --exact, is also viable.

Even if decide to keep it as exact by default, i think would be good to minimally make it non case-sensitive.

Yes, exact is already case-insensitive.

Changed default behavior to partial matching as requested by @garyljj.

Should filtering by "people who do not have a birthday specified" be implemented as well? From the perspective of the welfare IC, they might be interested to check for people whose birthdays are not yet populated, so that they know to approach them for this additional detail.

LGTM

Are we going to throw error if the user types in wrong specifications? like eg. list -partial or list partial or list Bernice. Currently if i'm not wrong it just ignores and lists all people in the addressbook

Thanks for spotting the bugs, you're absolutely right! At first was thinking of making space for the discussed list 1 3 syntax, but that's not the scope of this PR. Have added changes to check for the required empty preamble.

Some notes:

list -partial and the other variants above are now invalid.
list -partial -n john will not be valid since the preamble -partial exists.
list -n john -partial will be valid since the search term for name is now john -partial.
- This issue cannot be avoided since this is fundamentally how the parser is designed, to only parse specified prefixes.
- One way is to enforce regex validation, but we probably can't predict how people name themselves / their kids 😂

Just need to update HelpCommand.java

then LGTM

Great catch, thanks! Let's defer this till once the list functionality is complete, since there are more pending changes to the command.

Reopening this, issue still persists from https://github.com/AY2021S2-CS2103-W16-3/tp/pull/107.

Currently only allows deletion of 1 tag at a go (only the last specified tag will be deleted).

eg. edit --remove -t friends -t colleagues will remove colleagues tags from all listed persons. Should we allow deletion of multiple tags at a go?

Technically the proposal does specify multiple tag removal, but the syntax didn't reflect it :p

If implementing, can use argMultimap.getValues in line 92 of EditCommandParser.java.
If not implementing, might be better if we change the success message to include which tag was removed.

Did we conclude whether we wanted to do this, the other time we had a discussion?

Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1 -s?

Probably not, since it increases the complexity of the command + the parser doesn't distinguish the absolute positions of the prefixes, so matching two prefixes will be a pain.

Throwing error is one way, and the ~~easy way out~~ other way would be to simply document this ~~behavior~~ feature (i.e. only the last sort prefix given is used), just like for the add command. Which do you prefer?

I think we agreed that memory not really a concern atm since undo history doesnt carry over across sessions.

Floating an idea, what about (1) setting undo history to a cap higher than the average number of commands used in a single session, and (2) letting undo history carry over sessions? It's a little like vim's swap files.

Validation of the swap history can be achieved by storing the latest address book state in a lightweight hashed format, so it avoids users abusing the swap file to trigger invalid undos.

Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1 -s?

On that note, forgot to mention that if this is desired, there is a workaround for it, e.g. to sort by ascending birthday, and descending name if same birthday, can call these two commands in succession:

list [...] [-s name] -o descending
list [...] -s birthday [-o ascending]

I agree, though I also think the UserGuide is a good starting point for the users. Perhaps we can consider link drop in the result pane when help command is called.

On the same note, I think a nice feature would be to remove the menubar feature. Takes up much needed real estate only 😜

Gave a cursory glance (no computer to test), looks okay. Note the date comparisons are a little different between EventDate and Birthday:

EventDate should be sorted by date including the year, whereas Birthday is by month and day only. The compareTo method in Date should implement the absolute ordering, and Birthday to override this behaviour using getMonthDayString.
When merging #126, the retrieval of the string date for comparison should return "" for empty Dates. This is noted in the PR description.

--any is not the opposite of --exact functionality

Tested using #176 head. Very straightforward LGTM.

Dark theme:

Pastel theme:

As per internal discussion, will not be implementing due to lack of potential usage.

Great suggestions! All proposed changes have been integrated.

Not implementing, since #163 already removes all such updates.

Already fixed in #145, in previous milestone.

Did a quick field test (Person 1 has no fields, Person 2 has all fields populated), most issues from previous PR fixed.

Very nicely implemented! Note certain behaviors below that might need to take a relook (either in same PR, or in a subsequent PR if there is sufficient buffer).

Behaviors: General

✔️ edit 1 --address TAB -> edit 1 -a
- Long form prefixes are converted to representative short form. Valid, need to document.
✔️ edit 1 -r -r hey -r hi TAB -> edit 1 -r hey -r hi ENTER -> change remark to "hi"
❗ edit 2 -n -r -e -a -p -b TAB -> edit 2 -n NAME -r REMARK -e EMAIL -a ADDRESS -p -b BIRTHDAY
- Seem to have implemented all autofill except phone
❗ edit 2 -p 999 TAB -> edit 2 -p
- Phone number field is removed from input.

Behaviors: Tags

✔️ edit 2 -t hello TAB -> edit 2 -t hello -t TAG1 -t TAG2
- Existing tags are added. Valid, need to document (as opposed to replacing all tags with hello).
❓ edit 1 -t TAB -> edit 1 TAB -> edit 1
- Tag prefix is removed from input. Valid, but extra spaces in output? Cosmetic issue.
❓ edit 2 -t TAB -> edit 2 -t TAG1 -t TAG2 TAB -> edit 2 -t TAG1 -t TAG2
- Tags are populated. Valid, but also adds extra spaces in output (as above). Cosmetic issue.

Behaviors: Wrong command format

❓ list TAB throws "Invalid command format". Upon invalid command/prefixes, should it ignore as well?

❓ edit -r hey TAB / edit 2 -test throws "Invalid command format". Perhaps would be good to state "autocompletion requires command format edit INDEX and remark prefix -r to be specified.

Tested, LGTM. Note that the current behavior for delete -t tag1 -t tag2 removes people if they at least contain both tag1 and tag2. Intended behavior, will need to document.

Seconding this, @nickyfoo. This is a pretty urgent feature, for undoing changes to events.

Redo is a secondary feature, since there is already a command history.

Tested, works well. Note the cosmetic issue:

LGTM. See #184 for extension.

Very quick fix, LGTM.

Tested, works well. LGTM.

Tested, works fantastic. Other than @Ellevy's comments on supporting event names, LGTM.

Additional notes

edit 1 -t TAB -> edit 2 -t TAG1 TAB -> edit 2 -t TAG1 -t

There is an extra -t popping out with every second autocomplete pass. Can either raise bug report, or document as a feature.

edit 2 -test TAB -> "Index not specified!"

Error message can be more appropriately phrased as "Index / prefix not specified"

Made changes to upcoming event sort as discussed with @Ellevy and @garyljj, i.e. upcoming but done events are also funnelled to the back of the event list, sorted in chronological order with the rest.

Very cleanly done, LGTM.

Side-comment

The success message for both number of people and tags is a little weird (the former introduced by me...). Might want to update the result message in a subsequent PR.

Completed with merged PRs:

#192 (tags -> list)
#158 (delete by tag)
#128 (remove tags)
#116 (find -> list filtering)
#113 (delete filtered, deprecate clear)
#111 (long form prefixes).

Did not implement delete as alias to list command due to unnecessary complexity.

tags command deprecated with #192.

Not implementing, for two reasons:

Normal use case will not involve removal of fields (objective of welfare IC is to populate as many fields as possible)
Erroneous field additions are foreseen to be typically corrected during the same session, which is the responsibility of undo

Should the KeyCombination event handling fall under the same handleUserKey method? They seem to conceptually belong together.

Weird spurious merge conflicts, changes taken directly from branch instead.

Was actually on this similar documentation.

LGTM.

Was wondering if changing Tag::isString() to remove the square brackets directly would be a good alternative. I haven't seen the brackets during normal use.

Weird result message when sorting criteria not stated.

Potentially buggy implementation? Will need to fix, perhaps in v1.4.

LGTM

Rectified between commits 4df1103 to c259b07

Added in #218.

Alphanumerics inherently mean ASCII. Perhaps we can make it explicit by stating in the user guide upfront.

This is a legitimate documentation error, to change to corrected command: list -o asc, or perhaps even remove the whole thing since it's already ascending by default.

Fair point, since Ctrl-Z combo also exists for MacOS, even if intuitively Cmd-Z is the default MacOS shortcut. To fix.

Color me surprised, someone did raise this as a bug #239...

Adding the 0 as an argument is intentional, since it plays along conceptually with the 1 - 12 integer values.

~Possible follow-up to update the UG to describe this feature more clearly.~

It is described VERY clearly - as an alternative to -b (empty string) in the very same line.

Possible follow-up: Add tutorial to describe common workflow for welfare IC, which includes vendor management.

Related issue: #223

Quoting @zhengruoxin, 29 or 30 characters optimal for maximum event name length.

The same can be said for accidentally highlighting and deleting the whole input.

There are already multiple safeguards implemented to minimize said inconvenience, including an input history feature as well as an autocomplete feature to streamline the process of adding extra details.

Especially so since erroneous additions are foreseen to be typically corrected during the same session.

As a failsafe, the option of modifying the stored data is also available.

The field is intentionally constrained to only accept ASCII alphanumerics and space.

The problem of name variation is more one of legality, e.g. X Æ A-12 Musk, than it is the difficulty of romanization.

Not fixing, see: https://github.com/AY2021S2-CS2103-W16-3/tp/issues/245#issuecomment-813008894

This is clearly already reflected in the list command syntax list [-n NAME]... which accepts multiple prefixes. Not a bug.

~Perhaps we can add another example to list to illustrate how multiple -n prefixes will work @Ellevy~ Added in c8bb88e.

Duplicate of #225

Duplicate of #252

Duplicate of #266

Duplicate of #224

Duplicate of #225

Duplicate of #246

Due to case-insensitivity of tags raised in #240, duplicate issue.

~Note: 1/1/0000 should be a valid input (minimum year is 0).~

Turns out 0 itself is not a valid year, see #292 for more details (esp. fix)

Wrong error message for add, should be "Incorrect format" instead.

Note the same behaviour for eadd as well.

Duplicate of #270

Duplicate of #250

Duplicate of #270

To also check output of tags list, when list command is invoked.

Resolved with 94fc8ae.

To update documentation to rephrase wording.

And so is u.nus.eduuuuuuuuuuuuuu, by virtue of the non-existence of the eduuuuuuuuuuuuuu TLD. The RFC itself for determining a valid host/domain name is huge.

Regex, in my opinion, should be used as a means of providing a minimal level of client-side validation (or perhaps even restricting the scope of the product to ensure reliability of the product, see #245) to instill some user confidence in the product, not as the ultimate fallback to validate everything.

The only reliable way to authenticate a user is by doing an email verification exercise, which is not within the scope of this product (since this product is designed to operate locally).

This issue does raise a fair point about consecutive . being invalid in any context anyway, so might as well fix this.

My bad, edited the wrong issue.

Duplicate of #270

Should be okay to merge, approval from @nickyfoo @zhengruoxin @pyuxiang

Fetched and tested. Quick fix, LGTM.

Indexes are not exactly completed for 2. Perhaps can change wording to:

Indexes provided are either invalid, or reference events that are already completed.

Other than the above, LGTM.

To eventually also update that list is the only special kid around the block, with its case-insensitivity

Fetched and tested. LGTM

The same behavior persists for add and eadd as well, are we fixing those?

Duplicate of #270

Duplicate of #222

Actually, the description in #259 is a lot better than in this issue, might help to refer to that issue instead.

To refactor both documentation references and variable name references.

Should the isTooLong method calls be in the constructor instead of the parser? Otherwise direct initialization of names and tags will not trigger the check.

Need to truncate further, by taking into account the vertical scrollbar:

Optimal length for tags is 41 characters, names is 28 characters.

edit: I'm on Windows 10 with a 1080p screen, is this the same behavior across screen resolutions and platforms?

Also noticed the font @zhengruoxin is using doesn't seem to be Tisa Sans.

For smtp.google.com., is ending with a . valid? if not can domain regex to "[\\w-]+(\\.[\\w-]+)*$"

Yes, you can give it a try in your own browser: https://google.com.

The terminating period is part of a fully qualified domain name.

For false positive - . isit cos - need to be surrounded by letters, if so can "((\\w+(-\\w+)*)+\\.?)+$"

This enforces that - need be surrounded by \w. basically using same idea as above

By specification if I recall correctly, just cannot start with hyphen. Also not too sure what the email address domain part includes a hostname (for the mail server) - if it's a pure domain name, then hyphens are not even allowed. Also dunno if a single period is allowed.

Essentially just playing very very safe here in case someone want to find fault with our validation. If we want, can add a [^\W_] right after the @ to enforce alphanumerics.

What do you think @garyljj?

Makes sense. i think either "(\\w[\\w-]*\\.?)+$" or "([^\\W_][\\w-]*\\.?)+$" works. whichever u feel more readable.

Gotcha, going with the first. Thanks for the feedback.

You might want to consider removing this portfolio line that is a placeholder.

You might want to consider following the syntax for writing command line arguments here. In this case, the format should look something like week {WEEK_NUMBER | first | next | prev | last}

You could consider changing this to say week 2 shows the second week of the year.

You could also consider using the amended week syntax above here as well.

For these two lines, please include P / E respectively in the indices for the delete command

You might want to review this merge conflict...

Please remove the backup folder from your pull request as well.

There's another merge conflict marker here as well you might want to fix this

This is also another merge conflict marker

You might want to remove this as well

You might want to delete the .backup file as well

Here's the end of the merge conflict marker, you're supposed to tell them which one you want to marge in because Github couldn't do this automatically

You might want to remove this portfolio link since it links to an empty file

You might want to add a comment on why this part is commented out.

Might want to change to EventBook here

EventBook*

Similarly, you might want to consider leaving a comment on top of this commented chunk

You might want to consider removing the comment since you're done implementing it

You might want to consider changing the variable name to BACKLOG_EVENT_STATUS

You might want to consider changing the name of this to IN_PROGRESS_EVENT_STATUS

InProgressCommand**

BacklogCommand**

Event should be edited based on their identifier, not their index.

Define another method getEventByIdentifier(int identifier, List events) to get the event by identifier


Event getEventByIdentifier(int identifier, List<Event> events) throws CommandException {

    List<Event> eventsFilteredByIdentifier = events.stream()

             .filter(event -&gt; event.getIdentifier() == identifier)

             .collect(Collectors.toList());

    if (eventsFilteredByIdentifier.size() > 0) {

         return eventsFilteredByIdentifier.get(0);

    } else {

        throw new CommandException(Messages.MESSAGE_INVALID_EVENT_DISPLAYED_IDENTIFIER);

    }

}

You might want to consider converting the user input to uppercase as well, since currently, if user passes in s/todo, this would get rejected as they would need to do s/TODO, which might not be very good UX.

If we uppercase the user input, then the user can pass in s/tOdO and it will still work.

You might want to consider renaming index to identifier, since we would be checking by identifier, instead of index.

You could consider renaming these to Identifier instead of Index

You could consider renaming it to Identifier

Closed due to cyclic dependency

Closes #71

Closes #49

#102

Solved by #64

Solved by #159

Can be renamed before uploading for v1.4

Not a bug, identifier is not a counter, added as note in UG

Added to the UG, identifiers are unique IDs, not a counter or index.

Integer.parseInt issue, changed error shown in #160

Added p/ tag into description in #160

Resolved with #160

Solved with #160

Exists but undocumented yet

Solved by amending in #160

Added in #160

Closed by #160

Done with #160

I like how you used this plusDays() method in your code, didn't realise it exists

Looks well-implemented to me, seems pretty extensible if we need to add more formats or features

Perhaps you could consider using different dates here so there's more variety in the tests?

Looks pretty thorough to me, nice

I'm not sure if this may be necessary, but I think it could be good to have two date strings, parse them, and make sure they're equal in the date value represent? Just to check that the equals method doesn't break

A lot of formats seem to be covered here, nice 👍

Are there any delimiters your delivery date class is intentionally not meant to handle? If so perhaps you can add an invalid delimiter test here

Thanks for the heads up 😃

I think it might be better practice to keep request.value() as private and not public? you could have an isEmpty method in request itself

It might be better for anyone testing/using the product if you use a variety of requests in this file 😃

Think a variety of requests will be good here too

Maybe the Name class contains the regex you're looking for? You could adapt the "\p{Alnum}" in the Name regex to \p{Alpha} . I'm basing that off this link (https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html)

Also, I think when the parser part is done, it should be trimming any user input before the Type constructor is called so checking for spaces may not be an issue?

Thanks for catching these 💯

Think you mean Cost here

If these two classes are supposed to be the equivalent of CakeCollate.java and ReadCakeCollate.java, maybe this could be better named after the model name? so something like public class OrderItem(s) implements ReadOnlyOrderItems.

Something trivial, but I think it could make more sense while writing the guides, what do you think?

(For your future testing purposes) I wonder if a single " will be accepted? Can be added to tests if you think it's necessary 😃

I don't really understand why a delivery date has to be returned in all formats here? 😅 Also, could any of it be abstracted away in your delivery date class?

Would using a PREFIX_ALL variable be less bug-prone in case you need to add future tests? Not very sure myself, I think as long as we assert the user doesn't use that prefix, it should be okay?

Might want to explain the purpose of this new prefix as a comment, or maybe in the DG. Took me a bit to follow, but seems like a good design choice to have this prefix 👍

Seems like this method takes care of the "And" search, I'm not too sure about which part of the code takes care of the "or" search when no prefixes are specified?

I think in general our usage of order description and order item is a little confusing 😅 it might help the user if you use "ORDER ITEM" in line 20 instead of order description

Also an example would be good, think other commands have it 😃

I think you need to remove the elipses (...) since the command seems to be taking only one item at a time?

I was thinking of standardizing to "ORDER_ITEM_INDEXES" if the index refers to the order item table. What do you think?

inb4 tester reports that our app doesn't accept "X Æ A-12._"

maybe we should mention customers in our UG, not sure if that's more or less confusing...?

e.g. The name of the customer who placed the order."

Got it, changing it to "I can reflect mass cancellations in my database if they occur"

Thanks for the comments! Making all the changes you suggested now.

Rephrased a few things similar to this suggestion and removed all full stops 😃

Good point, added 😃

Oops, thank you, fixed

Ahh I wasn't sure if we wanted the users to type in numbers, or if we should be giving them another way to add multiple of each item at the same time

Reverted. My previous reply is irrelevant till v1.4 haha

LGTM

The order prefixes are wrongly written as "/o" instead of "o/"

I think someone can test the example commands given in the UG towards the end of v1.3b to similar errors (perhaps in error messages too)

Could mention in the UG that writing list or any valid command closes the help window?

Hmm I agree with this though, I thought might be helpful to list how many orders are being listed (can help w testing too)

Seems like the tester misunderstood the order items table - it's not meant to be a tally of all the cakes that need to be made. Think we should explain somethings clearer in the UG e.g. we can explain that the order items table is a shortcut table.

Oop clicking anywhere after clicking an order item does this

if all fields are the same --> considered same order --> reject it?

KIV, think about user profile

bc catching the wrong exception in delete command
also because of int data type

describe it a little more
include in the heading: "access previously inputted commands"
move this part of the UG

look at o or order item regex to fix this bug

check if edit command checks regex for other fields also??

specify what formats are accepted in UG

we assume this is from the perspective for clearing sample data --> so let's modify clear removes everything

add that future improvement

we have a separate command to clear two different tables

if refactoring =/= new feature --> refactor CLEAR to RESET

consider updating the dg (xw's 2nd pr on del date)

restrict the number of characters that user can input for name, email, addr, order descriptions, request

restrict to a flexible amount
add this to FAQ

shift request to below other fields, and test if long requests work

@RuiXiong2211

flag it as future improvement

user's can configure if they want this to be flexible or not (whether they want the app to allow amending of delivered orders' del date)

if we disallow this, too restrictive on the user if they make accidents

change command output to show that order already is cancelled

close this after quantity mentions are removed everywhere
can reply to him that's invalid, if anyone bothers
do we need to clarify this in UG/DG? if anyone has ideas go ahead
if not bugs related to quantity is gonna be marked invalid in PE ("reasonable limitation")

try catch -ve numbers & modify message so messages make more sense to users?

because numbers are hard-coded

check how to get maximum screen-width
if we can't fix this, try to default fullscreen
everyone try to look into this, see if anyone has any ideas for fixes

look into reference height and width

rx's issue

remove all troll stuff from code/documentation

additionally, check if UG and help command is synced bef submission

add tip: key list to go back to the main window

Here the value of property isn't change to correct format of MB3.5.

Here we also need to fix the property to MB3.5 to make it a meaningful test although it's invalid test.

I'm not sure if this is inconsistent with Code Quality. Maybe we can check it in the Course Website later.

Here the test case need to be implemented.

On my own opnion, this should not be commented right?

Same for this file.

Same problem found^

Here the format of deleteTag example seems not correct? Maybe it should be 'deleteTag 1 t/homework'

It may be better to add more explaination similar to this?

Maybe this kind of command is not added into UserGuide if I'm not wrong?

Nice defensive style code

Have no idea if the empty else block is acceptable in the CS2103T style. In addition, does that mean we will do nothing when the moduleManager doesn't have the existing module?

Similar doubt as above

Will it be bettter to implement a method in ModuleManager to check this? Since the implementation here may violate the Law of Demeter.

Here existingModuleInStr may be a bit confused since I think it means the list of valid module code right? existingModuleInStr seems a bit closer to the modules of current mapping though it's just personal consideration.

Maybe the empty line can be deleted directly? In addition, what if the mapping doesn't contain the module code? If we will never enter the box here we may use an assertion here : )

I see. Then maybe we can show a message that json file is manually modified and the corresponding task is not supported?

I think if we will never go into the else block then we can modify the if-else structure and use assertTrue(mapping.contains(module.toString())) above. Which seems like this:


assertTrue(mapping.contains(module.toString()));

List<Task> newList = mapping.get(module.toString()); //must ensure Module exists in the listOfValidModules

newList.remove(task);

if (newList.isEmpty()) { //remove the module(key) from mapping if no task is associated with it

    mapping.remove(module);

} else {

    mapping.put(module.toString(), newList);

}

Do you think it's a good idea?

Nice removement for it!

If I'm not wrong, how markdown works is that the 1s here would automatically be converted to 1,2,3,4...

So it's a deliberate choice.

Yep that's the attribute of the markdown.

I'm not very sure why we need appending " workload". Would you mind telling me

sure! I will fix this.

OK!

Yep. I will delete it.

Sure. I will fix it.

I think for this one, may be we can discuss in the next meeting.

OK!

Fixed.

This is because default compareTo will make the task with lowest workload shown at the top of list. But I think the feature may be more useful to show the task with highest workload at first. How do you think about it?

okay! Do you think this is better?


modulePieChartData.setAll(moduleList.stream().map(module -&gt; new PieChart.Data(module.toString(),

            moduleWorkLoadDistribution.get(module))).collect(Collectors.toList()))

Resolved.

LGTM

LGTM.

LGTM

LGTM. I think maybe it can be merged directly?

This is the same documentation bug as #157 .

This is a wrong bug report since tag should be used by t/.

LGTM

The logic flow should be:

IF patientIndex is provided -> user wants to change patient for the appointment {

patient = patient at patientIndex

} else {

patient = same patient from appointment

}

Javadoc to update

This one should be getAppointmentSchedule instead

Is this supposed to be FindAppointmentCommand.MESSAGE_USAGE instead?

There is no need to have a separate try statement.

We discussed that we will not need to maintain the email or address of the doctor.

There was no need to create a separate class. The methods could fit under SampleDataUtil.

The introduced spacing is inconsistent

Typo to amend to DoctorRecords

It was inside (see a few more lines below). Moved it to group w patient records methods

Yes

Yes there were repeated same method calls and implementations under the individual PatientRecordsStorage and DoctorRecordsStorage.

Nope, should only have changed the storing style in the files

It is because the initialised address book is empty here.

Should have one for patients and doctors sorry

This was an accident

Here is my take on this:

The enum could return the DateTimeFormatters instead,


enum StandardDateTimeFormat {

    DATE_SLASH_SHORT ( "dd/MM/yyyy" )

    ...

    private dateTimePattern;

    private StandardDateTimeFormat (String dateTimePattern) { 

        this.dateTimePattern = dateTimePattern; 

    }



    public DateTimeFormatter getDateTimeFormatter() {

        return DateTimeFormatter.ofPattern(dateTimePattern);

    }



    public String getDateTimePattern() {

        return dateTimePattern;

    }

}

Then, the parsing of the non-Next inputs could be performed like this:


public LocalDateTime parseDateTime (String input) {

    for (StandardDateTimeFormat standardDateTimeFormat : StandardDateTimeFormat.values()) {

        try {

            return LocalDatetime.parse(input, standardDateTimeFormat.getDateTimeFormatter());

        } catch (DateTimeParseException e) {

            continue; // no need for regex checking because check is performed by LocalDateTime.parse

        }

    }

    throw ParseException(...); // does not conform to any of the standard inputs

}

I really do not recommend having date and time parsed separately, but for discussion sake, one can implement 2 enums, standardDateFormat and standardTimeFormat and the loop can be modified like this:


public LocalDateTime parseDateTime (String input) {

    for (StandardDateFormat standardDateFormat : StandardDateFormat.values()) {

        for (StandardTimeFormat standardTimeFormat : StandardTimeFormat.values()) {

            try {

                DateTimeFormatter standardDateTimeFormatter = DateTimeFormatter.ofPattern(

                        standardDateFormat.getDatePattern() +  " " + standardTimeFormat.getTimePattern());

                return LocalDatetime.parse(input, standardDateTimeFormatter);

            } catch (DateTimeParseException e) {

                continue; // no need for regex checking because check is performed by LocalDateTime.parse

            }

        }

    }

    throw ParseException(...); // does not conform to any of the standard inputs

}

Should equals check for UUID field?

The predicate cannot check for keywords in the UUID.

The variable pt might be misleading here

Is this supposed to be String as per JsonAdaptedPerson

Will remove comment, but in order to test doctors too will require another AddressBook>Doctor> as a parameter in the future

Separated into 2.

Another predicate accepted by the method, NameContainsKeywordsPredicate must be a Predicate>Person>. So cannot change this.


* `delete -t colleague` deletes the "colleague" tag in contacts that contains this tag. If "colleague" is the only tag that that contact contains, the contact will be deleted.


  * Delete every person that has only 1 tag which is the given tag.

  * If the person is tagged by another tag, only the given tag is removed from the person. The contact will not be deleted.


* `delete -t colleague -t cs2103` deletes the "colleague" tag and "cs2103" tag in contacts that contains these tags. If "colleague" and "cs2103" are the only tags that that contact contains, the contact will be deleted.


            + "OR delete the person if that person has only 1 tag which is the provided tag\n"

            + "OR remove the provided tag from the person if that person has other tags.\n"

Does this mean we should create another command just to handle contact deletion and this delete -t command only deals with tag deletion? Basically similar to our add, find and delete commands that only deal with contacts while tags command only deals with tags.


        return isDone ? "\u2713" : "";


     * Tick represents done, empty string represents not done.

Suggested changes to the javadocs accordingly, thanks!

If I'm not wrong this implementation is the same as the UniquePersonList. Do we want to change? I guess if we change this then we should standardise and change for the UniquePersonList too.

Would it be better for us to display another message if the tag specified is not found in the listed persons?

Currently it is "Removed tag from: ". Maybe we can change it to

eg. "This tag does not exist in the persons listed. No tags were removed."


     * EventDate must contain a year.


 * Parses input arguments and creates a new EEditCommand object


     * Parses the given {@code String} of arguments in the context of the EEditCommand

     * and returns an EEditCommand object for execution.


     * Creates and returns an {@code Event} with the details of {@code eventToEdit}

     * edited with {@code editEventDescriptor}.


     * @param index of the event in the filtered event list to edit


 * Edits the details of an existing event in PartyPlanet.


        if (xDaysLeft < 0 && yDaysLeft >= 0) {

            return 1;

        } else if (xDaysLeft >= 0 && yDaysLeft < 0) {

            return -1;

        } else {

            return xDaysLeft.compareTo(yDaysLeft);

        }


                ArgumentTokenizer.tokenize(arguments, PREFIX_NAME, PREFIX_DATE, PREFIX_REMARK);

Probably should include auto complete for name for events since we allow it for persons


            throw new CommandException(Messages.MESSAGE_INVALID_EVENT_DISPLAYED_INDEX);


        Map<Prefix, String> prefixMethodMap = Map.of(

            PREFIX_NAME, event.getName().fullName,

            PREFIX_DATE, event.getEventDate().displayValue,

            PREFIX_REMARK, event.getDetails().value

        );


Note: Autocompleted Tags will be returned in alphabetical order and is case-sensitive.

LGTM

Are we going to throw error if the user types in wrong specifications? like eg. list -partial or list partial or list Bernice. Currently if i'm not wrong it just ignores and lists all people in the addressbook

LGTM

(On a side note: would be good to implement min height for the event later on too)

Currently only allows deletion of 1 tag at a go (only the last specified tag will be deleted).

eg. edit --remove -t friends -t colleagues will remove colleagues tags from all listed persons. Should we allow deletion of multiple tags at a go?

Currently only allows deletion of 1 tag at a go (only the last specified tag will be deleted).

eg. edit --remove -t friends -t colleagues will remove colleagues tags from all listed persons. Should we allow deletion of multiple tags at a go?

Technically the proposal does specify multiple tag removal, but the syntax didn't reflect it :p

If implementing, can use argMultimap.getValues in line 92 of EditCommandParser.java.

If not implementing, might be better if we change the success message to include which tag was removed.

Can possibly also write an error message telling them they can only delete 1 tag at a go

Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1 -s?

Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1 -s?

Probably not, since it increases the complexity of the command + the parser doesn't distinguish the absolute positions of the prefixes, so matching two prefixes will be a pain.

Throwing error is one way, and the ~easy way out~ other way would be to simply document this _behavior feature (i.e. only the last sort prefix given is used), just like for the add command. Which do you prefer?

I think documenting is good! Which do you prefer?

Do you think its better to include the --exact and --any flag?

eg.

delete --exact -t a -t b deletes all person with tag a AND b

delete --any -t a -t b deletes all person with tag a OR b

might be easier for users and it is consistent with list and elist

Currently all successful elist actions display "Listed all events" as the result message. Should we specify them? for eg. "Listed all events in chronological order", or "Listed all events in ascending name order".

For this I believe its the same as list. I guess if want can change but must change for both. Maybe I open an issue for changing the output message for both list and elist to do later on? Then if this one no other issues then can merge first.

Hopefully I managed to find all the places to change and allow autocomplete for name to work. Other than that, the rest seems good!

Not very sure why but it seems like when I run the app they can't load the fonts. (See pic below)

But the app still runs well with no errors

Marking event as done can mean that the planning for the event is done. Should be up to the user to decide.

Users should be allowed to add events from the past to store as reference for planning future events.

Users should be allowed to add contacts of vendors without having to store their birthdays.

As documented, list -b 0 lists out all contacts without birthdays.

Events are not restricted to be tied to a particular person. It can be for an overall event for all, and does not have to be for birthdays.

To eventually also update that list is the only special kid around the block, with its case-insensitivity

Currently the list in UG already states its case-insensitivity (Case sensitive for sorting by name but case insensitive for searching). Not sure if its clear enough though.

I would prefer it if both of these give the same error message.

Perhaps can change line 49 in EEditAutocompleteUtil.java to

throw new ParseException(INDEX_NOT_SPECIFIED_OR_INVALID_MESSAGE);.

Also agree with @zhengruoxin's comment. Maybe we standardize for both eedit and edit to Index not specified or invalid!

Other than that, LGTM

Need to truncate further, by taking into account the vertical scrollbar:

Optimal length for tags is 41 characters, names is 28 characters.

edit: I'm on Windows 10 with a 1080p screen, is this the same behavior across screen resolutions and platforms?

Also noticed the font @zhengruoxin is using doesn't seem to be Tisa Sans.

Max name length of 22 and tag length of 35 works well for me!

The new message is clearer, though do we want to standardise with the other invalid index message? eg. 0 and 20 are both "invalid indexes" but show different error messages. But both works lah

Technically not same case leh, cos 0 is not valid index (same case with -1, abc etc) but 20 is a valid index that is not in the addressbook.

Thats why 0 causes "index invalid" but 20 causes "person index provided is invalid"

But idk maybe can somehow make clearer haha

TBH 'index invalid" and "person index provided is invalid" sounds the same to me. What about

-ve indexes/0: "Index is not specified or invalid: Please enter an index value larger than 0"

too big index: "Index provided is too large: Please enter a valid index from the list"

Should there be a space after female? Not an issue, just a formatting thing really

Just like the one above, the index numbers in the example are missing the c/ prefix

The index in the example lacks the c/ prefix

Should the javadocs be represented like this or would a single line as per the original document be better?

same goes for here as per above

closing as upon discussion, we agreed that it's alright as checkstyle tests have passed it

wrong spelling for passenger

Address app should be changed back to GreenMileageEfforts

closing, resolved on improved code quality

Could you maybe change this to find a/serangoon returns Bernice Yu, David Li instead? thanks!

adjusted the description, closing comment

is this necessary? thinking because you could just use TripTime's internal toString() method implicitly but it could also be that im not too familiar with this

maybe keeping the requireNonNull might be useful since that's what we're encouraged to do this week

could we actually just change this to isSameTrip to keep the code shorter?

'diver' mentioned here instead of driver, no big issue just to take note for next implementer

Should this be DeleteCommand instead of PoolCommand?

sorry, why's it no longer a requirement to check for tripTime?

right, that makes sense, thanks!

Spelling mistake for efficient here

Full stop for TripDay but none for TripTime, and also TripTime now doesnt have an extra 'the'

Good catch, let me amend that

have clarified with mark, such an implementation raises issues within the compiler as PREFIX_NAME.toString() will not be considered as a constant

Have moved this to ParserUtil as discussed

Resolved this by changing logic in implementation as discussed

Rectified this, thanks for pointing it out!

LGTM

thank you 😃

As we are no longer implementing this, can we close this issue?

In a previous PR this was address but have yet to manually test that this works with live profiles as well.

Will close this issue when I'm able to manually test again live profiles with price

Have addressed this in attached PR. File name has been changed to GMEdata.json

should we put a character limit for tags?

maybe we can change this to HR executives who have been trained at using VBA within the company so they're comfortable working with text-based commands

Categorisation as we've discussed after consult

it does say that index should be a positive integer here, not sure if we need to adjust this

Maybe we can clarify that c/ is supposed to be for the passenger you want to create a carpool with

Maybe we can adjust this to be like pool where it's

delete INDEX [INDEX INDEX...]

Closing issue, same as Issue #199

We have created suggestions that Day should be a valid day of the week but I suppose we could change TripDay to Day

closing as same as issue #201

Similar to issue #201, can show that tags can be [tag/TAG tag/TAG...]

Closing, same as issue #205

closing, same as #166

@chewterence was this issue resolved in a more recent version of GME?

closing, same as #213 and #199

closing, same as #160 and #205

We are marking this as invalid as our group feels that this is the same issue as #159

Not sure how this can be improved

I don't think there are better alternatives. Single letter prefixes are preferred while the full word is a secondary option, another possibility is changing it to ta/ which doesn't make sense either

Resolved in a more recent version of GME

closing, will note that jar file should be named GreenMileageEfforts when creating release

FindPool works now, closing as fixed in older PR

closing the issue, remove pools changed to removing for standardisation which eliminates this issue. in other commands such as add, same wording is used, adding passengers instead of adding passenger which sounds awkward.

Because each section of our project has an in-charge (e.g Yongliang is currently in charge of the developer guide), I think we should assign the in-charge guy of that section to review the pull request. It can allow the reviewing of pull reviews to be more spread out among everyone, as opposed to one person doing a majority of the reviewing.

Maybe you should consider having 2 overloaded methods:

public boolean equals(Object other) and public boolean equals(SendCommand other)

but it's ok if u prefer yr current way.

Will be good to follow the spacing format shown in other MESSAGE_USAGE classes for more readability.

I think this extra indentation is not necessary?

The spacing for here too

I think we should discuss more if we should allow duplicate endpoints because other TA/tester may view it as a bug.

Same duplication comment as above

It will be good to include a check that method can only be "POST" or "GET" or "PUT" or "PATCH" or "DELETE", just like how the email checked that it had an email had @ and .com

Else, the method will throw an error

Would these test cases not being changed cause the tests to break down?

oh sorry :>

Just to confirm, Header's regex checks that a header is in the JSON format right?

If not, such deletion before checking may lead to bugs.

i think the standard is diagram above words

Cause HEADER is a keyword in the table above this, I wrote HEADERs

I put this part in the add/edit/send section original, because this blurb was in those sections:

>div markdown="span" class="alert alert-danger">❗️ Caution:

Multiple headers/tags must be unique and duplicates will be ignored

>/div>

thanks!

didnt tanjin do this

Nice removal of magic strings!

In the future, it would be better to use a static method that constructs CommandResult because I think they are a lot of permutations of CommandResult already XD

But since the project is coming to a close, I think this implementation is good enough.

good job moving the code from apiFeedbackHelper to this function as it improves readability by alot!

@ong6

if a user wants to remove a tag/data, they will most likely type

"edit 1 -t" and then its isn't removing the tag/data if the prefix is "-t "

which makes them think it is a bug / something is wrong (i was stuck on this for quite long)

I checked ab3 there are no space in their prefix so i think just follow that bah

I will resolve in another pr :>

O man

done brudda

done too

done

heyo I made sure that all address in the Developer's Guide are "url address", cause our class name in the code is still address but I didnt want the readers to be confused between URL and address

great catch

wrongly tried to merge master instead of the respective branches

refactor name to method (-x)

refactor address to url (-u)

I will update the docs for my 2 pull requests in another issue tracker

I did a quick skim of the files and it seems that the whitespace removed from the likes of PREFIX_METHOD are instead being introduced in the strings they are being concatenated with. Am I overlooking anything?

Hi the only thing in the PR that affects code is the prefixs being changed in CliSyntax.java. For the add, edit and run, I just made the error command messages more readable, for example: from

"add -xget -usomeurl -hsomeheader" to

"add -x get -u someurl -h someheader"

Okie @ong6 introduced the whitespace in PREFIX_METHOD in this commit 5 days ago so I think's best for him to do the review.

@ong6 so heres a more in depth view of whats wrong with PREFIX_METHOD = "-x "

using an example of "edit 1 -x "

when passed into the parseIndex method of ParserUtil.java, it calls

string trimmedIndex = oneBasedIndex.trim(); which trims the string to "edit 1 -x".

then because PREFIX_METHOD is "-x " (with the space), StringUtil.isNonZeroUnsignedInteger(trimmedIndex) will be true, because trimmedIndex will be equal to "1 -x", which leads an exception of the EditCommand.MESSAGE_INVALID_INDEX being thrown, instead of a more specific error message from the parseMethod method.

Also, if PREFIX_METHOD = "-x ", doing "edit 1 -t " or "edit 1 -h " does not work to remove tags/header because of the same reasons as stated above.

TLDR: there should be no space in all prefixs, unless you want to change a ton of other codde

@tjtanjin the run and send test lowly unreliable they sometimes pass sometimes fail on my comp and I couldn't even commit my work on sourcetree.

For me, the mainwindow background disappears after I toggle

oh ooopsie

Uhm, I just tested it. But it seems that the clear command does not show this picture? Is it only meant to be used for list when there are no endpoints?

yes i only show the pic if the user types list when the endpoint list is empty

done

we made the list command error message special for when list is empty

it shows the picture that you see to inform users that endpoint list is blank

thus, this is not a bug at all

this is most likely an inherited bug from AB3

no. some APIs could be http://127.0.0.1:5000/ which would be an API hosted on the user's own computer through port 5000

our find does an OR search, not an AND search

our find does an OR search, not an AND search as it provides more functionality

weirdchamp

thank u for clarifying

I made a hot fix is this ok?

Updated valid index error message too

ok currently i got the tags to show up for these commands, but i realised that the only relevant tag for these commands is the method tag; the other tags do not make sense to be included since no api is actually called, so there is no data to be shown in those tags unless we want to actually run it like the show command.

We want it to show "No Data" in the little box at the top, just like send and run

Great changes, just two minor comments:

the phrasing might make users think that INDEX is an optional parameter?

for the other invalid command format errors, should we still keep the [ ]? because [ ] has the meaning of Repeated parameters in UG, not sure if this is still what we intended to mean in the error message

I think [] is the best way to express that a parameter is repeated w/o writing a lot of words

there is a large chunk of spaces(?) here, not sure if it is intended

There is a space here, not sure if it is intended?

is this sout suppossed to be here?

I think this part was accidentally refactored.

Btw do we need this file? We dont have a find booking feature right

i think we dont need the {@code} tag here? not too sure

Might be accidentally refactored

@code Booking* ?

unsure but similar to above, do we need {@code String}?

maybe can just write Returns string representation of this {@code ResidenceAddress}

same as above, could just be string value.

we should be testing Residence's Name here instead of TenantName?

this file will be morphed into JsonAdaptedResidenceTest?

should be LocalDate end

i think it deals with how it renders the javadocs in html format, not too sure how it will look like when it renders though.

I'm also not too sure when we should use it but i dont think it points to anything

i think can include all the optional fields of residences also? we are allowing them to edit those as well i think?

this part too

Thanks, done!

need to catch invalid date format (caught by soorya's pr)

and handle index number 0 of booking as invalid (will fix a few other bugs reported as well)

update ug

This is sorted by unclean first?

Sorted by unclean only. (update ug)

update ug

Should this part be reflected via an optional frame, or should the fact that it was successfully executed be an underlying assumption? Maybe the branch here is better explained through an activity diagram, and the sequence diagram should show the "Happy path"? What do you think?

I think there's a typo here, it should be AddressBookParser

It might be helpful to add a note saying that this function does interact with storage, but you've omitted it here for brevity.

Would it be helpful to future readers to show that the isRecursiveKeyword and isReservedKeyword check is also done in this process?

Please remove the comments.

Perhaps it would be helpful here to link to the cascading impact on commands like rdel, redit, odel and oedit, which will need to be modified to block editing until deallocation happens. It would help explain the design decisions made on those commands.

Just a syntactic/clarity thing: Perhaps update the sentence to say "Run dealloc on the resident you are editing first." and then provide an example command

I think the formatting of this should reference AB3: https://se-education.org/addressbook-level3/DeveloperGuide.html#design-consideration

For consistency with other activity diagrams, perhaps state the actual condition in the "happy flow" and "else" for the flow that terminates.

Could you add a clarification here whether the name match needs to be an exact match or not? And does it have to be case sensitive? Would be a useful caveat to have for users of the system who may not be 100% familiar with the implementation of the function.

Same as above for this dealloc

Suggest adding INDEX here as well. Its done for rdel too.

Seems like there's a typo. Extra } at end of YEAR.

I think you accidentally duplicated a line?

I think it would be better to change this form to use the standard if-else syntax. There are 3 reasons for suggesting this:

It improves readability of what the function is doing.
The code-base throughout does not use ternary operators in the compareTo or equals function. They typically write it out in full form.
The module's coding standards require if-else type statements to take a certain form: https://se-education.org/guides/conventions/java/intermediate.html#layout

Thus, I would recommend changing it.

Would it make sense to just reference the variables from the room.RoomNumber class instead?

Would suggest updating the aggregations into compositions as stated in the module guidelines.

The phrasing "to store the mapping between the name of an Alias object and itself" could be improved. Perhaps rephrase to "to store the mapping between the name of an Alias object and the object itself"

Similarly, would suggest changing this to composition.

In addition, perhaps it should be a dotted arrow as the main mode of interaction is through the hashmap, and so, similar to the storage diagrams, it should be a dotted arrow.

Ref: https://nus-cs2103-ay2021s2.github.io/website/se-book-adapted/chapters/uml.html#what-4

Could you follow the general class diagram styling?


skinparam arrowThickness 1.1

skinparam arrowColor MODEL_COLOR

skinparam classBackgroundColor MODEL_COLOR

Done, thanks for pointing that out

Done, thanks for pointing that out.

You're right, I have updated it in the commit below.

Done

I don't think its necessary as the points above clearly indicate that Rooms are initialised with occupancy "No" and the state can only be changed via alloc or dealloc.

Yes, resolved.

Will update.

Updated.

Updated

Fixed

Right I missed that out

I brought it in because an edit operation may be intended to change the allocation status. I think alloc and dealloc should both be mentioned in edit commands.

Fixed

Removed

Fixed

Removed the justification and only set up the domain of the parameters.

Fixed

Fixed.

I wanted to specify that t/one t/two t/three will create a list of tags as {one, two, three} as opposed to taking the latest occurrence. Do you have an idea on how to improve the phrasing?

Yes. I've specified that and added that most command trim leading and trailing spaces.

Updated

Updated.

Yes.

It is auto-added by Intellij as part of the normal way of providing paragraph breaks in javadocs. It is conformant to the javadoc standards: https://www.oracle.com/sg/technical-resources/articles/java/javadoc-tool.html

This was automatically done by the code formatter, and checkstyle seems ok with it. It seems to follow the "conventional indentation" guidelines set out by oracle: https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html

However, the textbook (https://se-education.org/guides/conventions/java/intermediate.html#layout) says line breaks should only double the indentation. Let me know what you want to do about this.

Yes.

Yes, fixed.

Good idea, thanks

Okie done, thanks

Done

Resolved

Updated.

Done

Good catch thank you

Good catch, thanks.

Done, thanks.

Done.

Done

Agree with Colin. We should discuss this at the next weekly standup.

Beyond that, LGTM.

Thanks for catching this, seems like we all missed it.

I've also added a destructor to show when the AddRoomCommandParser goes out of scope

@colintkn could you specify under exact match to also indicate that it has to be case sensitive? Don't want people playing with words during the PE on this.

This method has been removed. Perhaps we can close this?

This method has been removed from the codebase.

This import style is necessary to disambiguate between the two classes and is unavoidable.

Duplicate of #206

Duplicate of #203

Duplicate of #206

Duplicate of #221

Duplicate of #206

Duplicate of #214

Duplicate of #247

Duplicate of #222

Duplicate of #199

Duplicate of #206

Duplicate of #244

Duplicate of #202

Duplicate of #199

Reminder to self to also ensure that docs state room numbers need to be non-zero positive integers.

Incorrect PR, please ignore.

Overall looks good, thank you for composing an explanation of the parsing process for potentially confused users. Perhaps this should have its own sub-section entitled "Command Parsing"? It seems a little long for a note.

I'll move it into a new section.

Closing as there is nothing for me to update, my roles have not changed.

Closed manually as I forgot to include it in the PR description before merging

Nothing to update as my roles have not changed. Closing.

Need to make the change for iclo, alloc, dealloc too. I have not done that and will do it soon.

Need to make the change for iclo, alloc, dealloc too. I have not done that and will do it soon.

This has been done in commit 06fed88

All comments addressed.

Missing javadocs comment? Missing test?

I think the javadocs comment doesn't match the purpose of the constructor. please use the other command available as reference and rewrite the comment.

When override, Javadocs will use superclass javadocs when there is no javadocs comment on child. I don't think it necessary to redefine the javadocs comment here.

Missing javadocs comment, Missing class test

Update the test case on DictionoteParserTest? I notice there no test added, please add all the required test for all the method you added, if applicable.

Update ParserUtilTest?

May I ask why does the addressbook store note list? I remember there is a ReadOnlyNote class.

Missing javadocs comment

Update the javadocs comment?

using wrong placeholder

FXML not defined in MainWindow.FXML. please use noteListPlaceholder instead

The stud is used for AddCommand, It is unnecessary to add note method here. In addition, AddNoteCommand test should be done in a separate class.

mayble we should be consistent here, and use week/ header/ maincontent/, or w/ h/ mc/

addnote [c/CONTENT] [t/TAG]... instead of [c/CONTENT]... [t/Tag].. as '...' indicate mulitple

maybe mention what the note is sort by? e.g alphabetically

the UI here refers to the panel, not the model definition. When using ListDefinition, you use UiActionOption.DICTIONARY_LIST, this will open the list panel to show the definition

The UIActionOption refer to the Panel, not the model. hence DICTIONARY_DEFINITION do not exist as no such panel exist.

p.s. please remove DICTIONARY_DEFINITION and use DICTIONARY_LIST

DeleteNote?

I suggest doing this in a separate class. Model should not be responsible to be writing to file.

resolve conflict?

can you try edit an existing note with the same content and see the result? It might introduce another bug.

I have asked the question via the forum, the lecturer said no need to follow java coding standard for fxml file generated via scene builder

https://github.com/nus-cs2103-AY2021S2/forum/issues/195

I have asked the question via the forum, the lecturer said no need to follow java coding standard for fxml file generated via scene builder

https://github.com/nus-cs2103-AY2021S2/forum/issues/195

yap

The tester did not type listcommandu

The command being type is 'open' command. as shown in the image

It designs choices if we put setdividerdictionary, setdividernote, setdividerontact, setdividermain. The command will eventually become too long and unusual in a long run. the 'intuitive' part does depend on experience, as user use the app more frequently, they will notice the same theme going on. n stands for note, d stands for dictionary, c stands for content, and m stands for m main screen. The same format has been given to multiple commands, hence the pattern is there for the user to learn. the command is also designed to be similar since they are the same command just working on a different component. to improve the intuitation, we will add note to userguide.

yes, it an intended by design.

If the user closes note content, why would it want to change the divider orientation in the first place? (they cant see the divider!)

The logical reason will be that the user will like to see the note content too.

Hence it is logical to open the note content, this way, the user will be able to see the result of the command as well.

since this behaviour is not stated as UG, it will be added.

user is not supposed to edit the JSON file in the first place.

We will refer them to userguide -faq if such stuff happen

More error handling will be done in v1.5

Will add in the detail to differentiate -d and -dl.

scroll up the user guide. the details panel name is there. it literally just on top of this command

We do think this is secondary as it is more for an advanced feature. the main feature for the application is note-taking and dictionote, hence call dictionote. manipulating of GUI is secondary.

the divider position is saved when you moved the position manually too.

open -a ensure all panel is visible, it does not reset the divider position,

it will ensure the divider is back to it last known position.

I assume your "not working properly" is because the divider not reset

as I can see all panel content is visible. mean it working properly as all panel is visible.

One will be ignored, another will be invalid. they are not the same thing?

there is an error with the markdown conversion.

Minor error in userguide - incorrect format given

Minor error in user guide

change from semi bold to normal font as well as quick formatting. tried console font but isn't ideal : courier new font example

I think you set your default program to open your jar file wrongly.

added better error message

Adding to FAQ, not to change json file as it not intended for user to change

Perhaps this line can be broken down into smaller parts for better code readability?

Perhaps this line can be broken into smaller parts for better code readability?

Maybe this is not needed and can be removed?

Perhaps this can be broken into points for easy reading.

i.e. Reason for current choice:

For the steps in the scenario, perhaps we can standardise to "Step 1", etc. Like edeline's and the undo portion which existed in AB3 before hand.

Thanks for correcting this, totally forgot about this 👍

Would be good if you could separate the export and import into 2 different parts.

Perhaps you could separate the guide for exporting and importing data?

Looks good 👍

Is "all clears all" a typo?

Maybe don't need to edit checkstyle.xml here as the previous indentations look correct?

Same comment as for checkstyle.xml changes.

Can remove this part if not needed.

We should make sure that parts of code that require option use this class for code standardisation.

Maybe change name to tags instead, since it is a list?

Perhaps can remove this since we already have toString()?

Perhaps, tc/ should just clear child tags only.

It's an "and" relationship if I remembered correctly, so maybe "with the exact same name, date and address" would be better?

Okay 😄 👍

I used startsWith to avoid interacting too in-depth with other logic class (like via any command parser), not sure if this is the right way though, as it feels a bit brute force-ish.

I think this might be a bit "brute force"-ish, but I didn't want to break the abstraction of logic and i needed the scene from MainWindow.fxml to set the stylesheet

To standardise error message so that if index non-valid, will have same error message.

Once #224 is fixed, check if this is solved as well.

More specific error message, one for invalid format and one for invalid date.

Add clarification in user guide as this is an expected behavior. Should also add this as design consideration in developer guide. Make it clear that equals for contacts checks by duplicate name or tag. Can do so via use cases.

Expected behavior.

Update screenshot for find command.

Expected behavior of sort command:

If find then sort should still be able to view filtered list.
If find then sort by a certain option, actual list will also reflect this sort option.
If sort by certain option then find, filtered list will also be sorted in that option.

More specific error message.

Should be solved once #246 is done.

Should be able to solve this once #246 is done.

Should be solved one #246 is done.

Closed as similar to #190.

Add disclaimer in user guide that tags are not sorted.

Should be solved by #234.

Closed as duplicate of #222.


        if (lst.isEmpty() || isDifferentFromLatest(s)) {


    private boolean isDifferentFromLatest(String s) {

This doesn't seem like a very robust check, since it would allow dates such as 2020-99-99, which would be an invalid birthday as well.

I think we could instead use the Java LocalDate class, which provides the parsing methods as well.

You could refer to what I did in my IP, for the deadlines. https://github.com/nickyfoo/ip/blob/master/src/main/java/duke/command/DeadlineCommand.java

or here for usage of LocalDate class

https://www.baeldung.com/java-string-valid-date

It might be best not to catch all exceptions here, perhaps writing the specific ones which might be thrown by the Birthday constructor?


| `**` | Night owl | Enable dark mode | Use the app safely in dark environments |

Reminder to change this to not show an X as it's kind of unsightly

No, we decided that the cross for an undone Event would look very unappealing, and so we've removed it

It seems like the method is doing more than it should, in the sense that it is checking if the person has tags, and adding it to editedPersons, which might violate some abstraction principles.

On that note, the method name is misleading, since it implies that it only checks if there are tags.

I would suggest to change this method signature to private boolean hasTags(Person personToCheck), which will return true if the person has the tags, otherwise false, and leave adding the person to editedPersons to the execute method


* The birthday must be in a valid date format, with or without year, and must be in the past if the year is specified, e.g. 13 Jan, 13 Mar 1997


Can be invoked repeatedly until there is no more history from the current session.


* The date must be in a valid date format with year, e.g. 2022-05-07, 2 feb 2021

Method name is a little misleading, as it seems to imply a check (i.e. returns a boolean). I think this method shouldn't be calling deletedPersons.add(person), as it might violate some abstraction principles.

It might be good to abstract this out into a boolean hasTags() method, that checks these things, and then leaving the adding to deletedPersons to execute.


   be stored. For instance, the Welfare IC might want to store the email of a catering company, or the address of a bakery for cake pickups.


   not important. For instance, the Welfare IC might want to store the address of a member to hold a surprise party.


3. Add in past events to store for reference when planning future events. As most parties in CCAs are repetitive, it would be


   useful for Welfare ICs to store past events for ease of reference when planning future events that are similar.


   has to be stored for each event. 

   For instance, a farewell party for the graduating batch needs to be planned in the next month, but the date is unconfirmed. The welfare IC can add this as `eadd -n Party for graduating seniors -r Confirm availability of seniors to fix date`


   month only) with `list -s u` so that they can plan for the parties accordingly.


   month and year) with `elist -s u` so that they can refer and plan for the upcoming parties accordingly.

Thanks, corrected.

Added, thanks

Incorporated into latest commit, thanks!

LGTM

INFO: Added state to stateHistory. Current number of states is: 2. Currently on state: 1 is the logged message. Seems like we can have a feature to easily redo as well.

Yup, definitely planning to in a future iteration. I mentioned it in a currently unimplemented nextState method in StateHistory

Ah that's true, will do that instead.

Yup, I think it'll be good to have the help command provide both immediate (summarised) help, and a reference to the link at the bottom for users to explore the nuances

Apologies, it slipped my mind that Birthdays should be sorted by Month and Day instead of including year

The same exception is thrown when tags -f [CHAR] is called, where CHAR is any character not in any tags, e.g.

tags -f z for the sample data.

Fixed by PR #161

As discussed before, since the StateHistory is refreshed on each running of the application and does not carry over between sessions, it is unlikely that it will cause a memory problem, and so it will not be implemented for this milestone.

Should the KeyCombination event handling fall under the same handleUserKey method? They seem to conceptually belong together.

Added to the latest commit!

A more recent PR in #209

Fixed by commit ba56e71

Is there an extra 'the' in the second sentence; 'determines that the the command called is...'

Should the 'ParseException' be formatted as code i.e. enclosed by ``

Should AddressBook be StudentBook?

Do we wanna indicate the multiplicity here? Is it 1-1?

Correct me if I'm wrong, does this mean a student can have 0 or many school residences? Shouldn't it be only 1 school residence for every student?

Have you not merged with the latest master branch, to reflect the new DG?

Should you use the method StudentBook::isExistingMatricNumber that yien implemented for this instead? Also do we need reference-type Boolean or is boolean sufficient?

Is there a reason you use LocalDate and LocalTime here instead of String?

Do you think it would be better to abstract, this check for whether the target appointment to edit exists, as a method in Model? So that the Logic component doesn't access the internal structure of Model directly.

Is the check for whether the student exists necessary, as the existence of the appointment implies that the student must exist? Or do you consider this as defensive programming? Does it mean if the Model happens to have an appointment that corresponds to no student, this appointment cannot be edited?

Correct me if I'm wrong, shouldn't CommandException be thrown only in the Logic component?

What's the difference between this method and isValidFaculty method?

is this field textUI used anywhere? it seems that no method uses it.

Should the error message talk about clashes or duplication?

I don't quite understand this sentence. What does it mean to 'detect'? Does it mean to reflect the changes in the UI?

Wouldn't our app reflect any changes to any field in the json file? Would mentioning only matric number gives a false impression about the difference between editing matric number and other fields in the json file?

Ah I forgot about the app making matric number unmodifiable.

What if we say that, while users can edit the matric number in JSON file even though the GUI doesn't allow, extra care must be taken to ensure data integrity. Specifically, if the user decides to edit the matric number of a student, they must either (1) edit any appointments for this student to reference the new matric number, or (2) delete all appointments linked to the student.

Btw what would happen if I edit matric number in JSON and the matric number in appointments are not edited? We should specify the expected behaviour in this scenario somewhere in UG also?

Yup I don't think it's a contradiction coz the writing commands thru the GUI and editing the JSON are 2 distinct interfaces to interact with the application.

This is very good!!

good idea! will make the amendment.

on a second thought, would it be better to repeat the information? the reason is that if a reader navigates directly to a feature, then they will know the relevant conditions for using this command. If we refactor and put this in the parameter format section, the reader might miss it. another alternative is to have an in-page hyperlink that directs to a subsection called "Conditions for valid appointments" (which would also talk about no clash and pre-existence of student etc.)

What do you think if we remove this line?

https://github.com/AY2021S2-CS2103T-W10-4/tp/blob/15c156a02d6463b9dae9bac73a8e90628f763229/docs/diagrams/AddSequenceDiagram.puml#L43

I thought more about this and wonder if this is a self-invocation, which entails calling another method of its own instance. If we remove this line then it would be that AddressBook is activated by the method call addPerson() from Model, then returns and gets deactivated.

Also can you update the image in DG to match the new sequence diagram?

LGTM

These two commands have distinct usage. find searches by a unique identifier, that is the matriculation number, hence would return a unique student and their appointment if present. filter searches by a condition which can return non-unique values.

Do we want validate name or is this beyond the scope of our project? I personally think this might not be necessary. @SiTingST @fairyinabottle4 @yienyoong

Do we want validate address or is this beyond the scope of our project? I don't think this is necessary. @SiTingST @fairyinabottle4 @yienyoong

Shall we validate the phone number with the condition of the length being 8? So it must be a local phone number. @fairyinabottle4 @yienyoong @SiTingST

I think this is a documentation bug as we agree that users cannot edit the matric number of an appointment, and yes they would have to delete and add a new one. what do you guys think? @SiTingST @yienyoong @fairyinabottle4

@SiTingST do you wanna put all the issues about lack of ss as invalid and close them?

#220

This is an intended feature so that users can add back appointments that they might have forgotten to add. Similar to a calendar app.

#213

#211

This is a documentation rather than functionality bug. Shall we update the UG to indicate that NOT LIVE ON CAMPUS is a default value? @SiTingST @fairyinabottle4 @yienyoong

We'll update the error message to say that the appointment for this student already exists, and/or that one student can have at most one appointment at a time

How shall we address this? Initially I think our group agreed that vaccination might have multiple shots, but this seems to contradict with our implementation that a student can have at most 1 appointment. Shall we remove the latter restriction then? @SiTingST @fairyinabottle4 @yienyoong

#220

In view of this problem, should we either (1) make matriculation number uneditable for students, or (2) implement a hidden id for Student class that an appointment will reference rather than matric number? I would prefer (1) coz it's simpler haha. @SiTingST @fairyinabottle4 @yienyoong

@SiTingST Shall we remove this line in UG, since the second last point in the box "NOTE ABOUT THE COMMAND FORMAT" already addresses this?

related to #222

#201

#234

@yienyoong do you think this issue is invalid?

#234

#222

#234

#222

I can't seem to replicate this bug. Might clarify with the author of this bug report.

@SiTingST i'll fix this coz i'm editing some other small details for appt command documentation too. will make a PR soon.

Also need ensure contact info under appointment is updated after student edit.

then @fairyinabottle4 do you mind doing the removal of edit matric number functionality for students?

Priority and phone has the same prefix, may need to be careful later

I suppose this file is not updated fully yet

are we gonna change the prefix_phone and email all that?

oh ok haha

this should not be imported yet.

are we gonna change the prefix_name and phone and email etc

this may not be an issue but I am thinking maybe we will need something similar for our tests later

ah jiahe I also made this changes, we may have conflicts later

can we rephrase the message to "Please ensure the deadline provided is not earlier than today. This means only today and date later than today are allowed." or something similar haha @SoulUseless a better suggestion? same for the error message for event because the original message sounds a bit wrong hmmm

wait ah I think we are trying to allow today to be added? like today is 2021-03-29, it should be allowed as a deadline?

happen before today?

can try to abstract out some processes? This looks like a deep nested or too long method:(

I think this should be allowed

which means only invalid events should be disallowed. overdue tasks and past events should be allowed

needs because it fails some test case, I suspect storage is not working properly or something

this format follows java syntax, I cant recall the difference hmmm

oh if you are removing it I can add it back

Looks great thanks for the update!

@ljhgab i think this may have been done?

@ljhgab I think this may have been done?

This is an invalid input, do you mean an error message should be shown?

temporarily on hold

need to write as close #200 close #201 haha otherwise it only closes 200

pending

@Icelenaugust We do not agree that this should be considered as a feature flaw, but rather a possible suggestion. This is because it does not significantly hinder users' usage of the function (takes less than 1s to scroll).

It is allowed to add a task with deadline today. The screenshot given is adding an event with deadline earlier than today, which is invalid.

Again, optimisation is subjective. In the shoes of a user, it is more common to done many tasks, but not undone many tasks. This can be a possible enhancement, not sure if it is allowed to change the undone feature dramatically like this in v1.4.

done_task is dup with issue #261

closed in PR #322

No change in code done, removed 'ongoing' in UG as it is misleading. Uncompleted tasks with deadline before or on the given dates is the intended behaviour.

will be split into many subissues

need

dup with new issue

@YuFeng0930 is this closed?

done fixing mine

Hi guys, please kindly ignore this issue as it worked now. Sorry for the trouble!

This can be shortened to just this.zeroBasedIndex - index.zeroBasedIndex. (I think)

While it may already be intuitive, maybe you can add a comment that the function sorts the dates according to the earliest to the latest.

I am not too sure what the variable value means here.

I think this should be a DeleteOrderItemCommand object instead of a DeleteCommand object.

this should be OrderItem instead of order

Are these println statements deliberate

for examples adding incorrect inputs as well would be good

^type of characters add eg

precede is too chim

the term fields and prefixes should probably be specified in the glossary

add no character limits for address, request and email

these two statements contradict each other, today is not a future date

first statement can be deleted, a little confusing from the perspective of a tech noob

this statement is a little confusing,

indexes must be added to the glossary

probably not needed

fixed

yep, changed the conditions to be more strict.

oops, meant to be RemindCommand

changed

Looks great!!

Also, wanted to ask whether inputting an add/find command after a remind command changes the address book back to the original person list? Not sure if the addressbook already takes care of that somewhere else.

@pavz02 , RemindCommand acts on a different list than add command, but on the same "filtered" order list as FindCommand, it will not affect the state of the original person list.

it should be initialized as an empty string, thanks for catching that, i forgot to test the addcommand

changed

added more requests

i was wondering why the ab3 tutorial added a prefix too, i think its used to mark the start of the request, but im not too sure why they added it in the first place, so i left it as it is.

yep, for now it looks like the tag and undelivered tag, wanted to make it stand out more.

changed

i was thinking that alphanumeric might be too technical jargony, so maybe i can change characters to letters instead

sounds good

NO......

LGTM

LGTM, maybe you can update the user guide as well to reflect the changes that have been made.

LGTM, will be merging this to the master branch so that I can fix some merge conflicts on my end.

Fix #85

Skimmed through it and left some comments you might want to consider. Other than that, LGTM 👍

edit: also I'm guessing you're not planning to add requests using the Add command?

I am still unsure of how an order requires a request but the request is not added with the add command. I thought you would be implementing it with the add command as an optional field (optional like the tags), so if I misunderstood your implementation sorry haha

It is implemented with a separate command, but now that i think about it i should have probably implemented it with the add command lol i thought it would be neater to use a separate command to add requests instead of overloading the addcommand. In my implementation, requests are initialized to be empty at first and added with a separate command.

LGTM

Fix #93

The files you've edited look good. Can I check if the json file created as expected in your data directory? If so LGTM 😃

Yep, there's a json file created in the data directory, the json file currently contains the SampleDataUtil OrderItems Model's data.

I believe the peer reviewer had a wrong understanding of what it meant.

fixed.

Update UG to be more specific in this, add screenshots too

can be fixed by putting request below the other fields (i think) or restricting character size of the special requests, expecting the same bug for tags.

fixed.

I dont think this is a bug since orders with delivery dates in the past can exist in the application, and editing the json file directly is probably out of scope of the pe

repeat

oh looks like i had the wrong understanding oops

It can be that the order had a wrong delivery date input in the system before sending out for delivery and for accounting purposes, updated in future.

Great job, Good formatting

Good value proposition

great job!

great job

Great job, follows SLAP everywhere!

Good, follows SLAP

Great Job, SLAP used

SLAP-tastic!

Great job

Good job

Good Job

Great documentation

SLAP-TASTIC

Good SLAP

good job

Great Job

Merging to main, DG should update for everyone

ignore this

implemented help command

implemented delete command

implemented edit command

Remember to clean up the comments to match Residence instead of Person

Address Book comments need to be changed to Residence Tracker too

Class name has to be UniqueBookingList I believe?

I think you meant .isSameResidence here?

do you mean seedu.address.model.booking.Booking? I think you might have forgotten to refactor the person package to 'booking' instead?

Once you refactor, you probably don't need this import statement since the Booking is also in the same package and you can use it directly in this file

Hey use logging instead! I need to add more logs myself.

Can we refactor this class to be named as VisitorName? similar to how we did for Residence by calling it ResidenceName?

And we could call this class just Name?

I think we can allow any special characters for ResidenceName because why restrict the user unnecessarily right?

So a validity check could be to allow any non-empty strings and no " "?

I think we need these to make bookings to be used in tests later but maybe could rename to PHONE_DESC_BOOKING1 and PHONE_DESC_BOOKING2?

I left this commented out to be built on later when we add more tests so could we keep sorry!

probably need to keep this line too to make bookings in tests later?

Hey, I think you could use these Prefixes directly by importing them without the need for these getters! Since they're public static similar to how we see it used it other command classes 😃

Nice thanks for adding the new commands in too!

I'm thinking maybe instead of showing c/[y or n] we can write c/VALID_CLEAN_STATUS and then mention that VALID_CLEAN_STATUS for clean: 'y' or 'clean' and unclean: 'n' or 'unclean'?

Yup!

oh I was trying to refer to the parameter booking instead but not really sure where to use @code and when not to to be honest...

Yup deleted this and it's corresponding test file

yup fixed!

I'm leaving this since it's the toString method and seems relevant...?

Yup such differentiation is possible and reasonable to accommodate residence names like Pinnacle@Duxton while having regular names for visitors

Regarding the tests maybe we could keep them commented and re-evaluate in v1.4?

Note to team: this was fixed in my PR that was merged yesterday but will be good if the rest can verify if it is fixed!

I think you must make a new class called EntryTagContainsPredicate which implements Predicate>Entry> and do your implementation for filtering tags there, then pass an instance of that class as a parameter into the updateFilteredEntryList method. The ListEntryFormatPredicate is used for listing entries only.

This class can be deleted.

This class can also be deleted.

Change to contact

Please add the methods setContact(Contact target, Contact editedContact), getFilteredContactList(), updateFilteredContactList(Predicate>Contact> predicate), and implement these in ModelManager

Predicate>Contact>

I wrote a small intro last time:

Welcome to the User Guide of Teaching Assistant!

Are you a JC/Secondary school teacher, having troubles keeping track of all your consultations, meetings and your students' contacts? No worries! Our application, Teaching Assistant will provide an all-in-one platform for you to organise your entries (tasks and schedules) and contacts!

Teaching Assistant mainly uses a Command Line Interface (CLI). This means that a user can use the application by typing into a Command Box. For users who type fast, they can use this application more efficiently than other applications that heavily use Graphical User Interface (GUI), where a user uses the application by interacting with graphical features such as buttons.

If you are interested, jump to Quick Start to learn how to learn how to start using Teaching Assistant.

Can add hyperlinks to each command under the Contact category, same for Entry category.

Can add screenshots from our demo under each feature (but is optional for now)

Change the pic to our actual Ui.

I've changed the implementation such that Hans Bo will only return Hans Bo (i.e. AND search)!

Will not return anything unless there is a person called alex david

for your Teaching Assistant

provided that it is not the first or last character and provided also that it does not appear consecutively

#139 Are we following this person's suggestion?

This is used in line 20 to ensure validity of quantity

Will be adding test cases for empty String

Any reason why this has to be public?

Not sure if I misunderstand this, but shouldn't this be for orders?

Likewise , please refer to the next comment

maybe we should rename this to be more a more boolean name?

Don't think its a good idea to have method name similar to the field name

Is the original set equals not working? I think the original equals for set do checks the individual elements according to the API.

i think the d/EXPIRY_DATE needs to be change to e?

WIll be good to mention that if there are some orders completed , the cheeses assigned will be deleted as well.

i think there is a missing note of 'ORDER_DATE' must be any date .....

its a hidden folder .data/chim,json

Any reason for the deletion?

likewise here

Sure. Merge his PR and then i will resolve the conflict and add in the missing actions

Noted.

Yeap , will merge his changes into my branch after his PR has been merged

Will update in the next commit

Yeap but even if dont have it's by default false.

Will add it in the next commit.

Could you elaborate?

I was thinking of changing it to status : (Assigned / Not Assigned)

Don't think we should do a counter, as I was thinking of setting quantity's value to be private.

setCheese , yes will be moving it out. realized that I might have not considered an edge case

Sure. will be adding this in the next commit

Will be making this change in the next commit

Hmmm based on the doc , it should work but when i was debugging that was giving me some problems. Will look into it again.

Yeap, will be updating in the next commit

Sure. will fix it in the next commit.

hihi, do resolve the comments in gdrive too

Where are the comments?

Duplicated Issue as 65

duplicated issue as 65

duplicated issues as 66

duplicated issue as 56

Shouldn't these import statements be explicit in order to comply with the Java coding standard?

Shouldn't the length of any line of code be limited to 120 characters maximum?

Does the maximized="true" part starts the program in maximized window mode by default?

Should the code block in lines 18-20 be written inside the constructor in line 22?

Should both paths use the same "\nLocal data file location : " string prefix?

Should this semicolon be here?

Shouldn't the JavaDoc for this method contain a tag for the parameter note? (i.e., @param note >description>)

Oh I see, sorry for the misunderstanding.

Shouldn't it be from the notes list instead?

This issue appears in other parts of the code as well

Shouldn't it be new DeleteNoteCommand object instead?

This issue appears in other parts of the code as well

Shouldn't it be from the list instead?

Shouldn't it be show no note instead?

A minor issue, but shouldn't there be a space before and after and note book and and dictionary content?

Shouldn't this be listnote instead of editnote?

I notice some class may need to be renamed:

PersonUtil -> ContactUtil?

PersonListPanel -> ContactListPanel?

PersonCard -> ContactCard?

JsonAdaptedPerson -> JsonAdaptedContact?

otherwise, LGTM

Right, but those were left unchanged because other Contact commands rely on them.

I will rename them when I update the other Contact commands 👍 .

Addresses may differ in their formats; therefore, it would be difficult to adopt one format and enforce it upon each Contact entry.

This is the behavior we aim to achieve, but we will update the user guide to emphasize so.

Proposed change: "...materials and writing notes about them." -> "...materials , writing notes about them , and sharing these notes with others."

Proposed change: Add "This command sorts the entire contacts list, including the contacts that did not match the latest findcontact query."

Proposed change: add a disclaimer to highlight the changes done to the user interface through user commands.

Proposed changes:

Add a detailed example for searching with multiple prefixes.
Add an examples with a supporting screenshot for searching with tags.
Add an examples with a supporting screenshot for searching with multiple prefixes.

Just a suggestion. Would it be better if you put everything in a try-catch block?

try {

if (test.matches(VALIDATION_REGEX)) {

    LocalDate.parse(test);

    return true;

}

} catch (DateTimeParseException | NullPointerException ex) {

return false;

}

Personally, I think this is okay since this is within the test folder and we are abstracting the value through key-value mapping. Furthermore, we do not many variables so as long as each JSON object follows the same sequence I am good.

Why did you remove this check?

I think if you can avoid nesting if-else it would be great. So you can do

(test.matches(VALIDATION_REGEX) && value > 0) {

return true;

}

It increases readability as well.

But as long as your Long.parseLong(test) is the second condition to test.matches(VALIDATION_REGEX), it will be fine due to short-circuit.

I assume you use this line of code to debug and forgot to delete it.

I get what you are trying to do here. But your code here seems like you are comparing two items instead of comparing the item's quantity.

For me personally, I feel like this entire code should be abstracted to the item class and name it as quantityPriorityComparison.

What do others think?

Details are in quantityComparator and item class

Same as the quantityComparator, I think this method body should be abstracted to the item class.

What do others think?

Carry on from quantityComparator and ExpiryDateComparator

All this method can be removed and replace with a method like quantityPriorityComparison and expiryDateComparison. It would somewhat be like a compareTo method in the Comparable interface.

You forget to add the throws exception in the javadocs

Agree with kums!

Prevent using magic boolean. Other than that LGTM

Just a suggestion. Would it be better if you abstract the inner if-else clause into another function? Because both the if-else clause looks similar. Maybe, you can have the function takes in another argument to differentiate these 2 different if-else clause?

Just wondering, does removing this test decrease the test coverage? Would it be better if you change it to assertParseSuccess since we are allowing negative numbers now.

All right noted!

Yes, it will work as normal. I am using inheritance to achieve both showing all items when no argument is given and also showing filtered items when arguments are given.

I think it is fine. I follow the AB3 format, but we can always revisit the User guide and developer guide along the way. 😄

Great catch! Thanks! I will change according!

I agree that the message is the same as the above two lines. But, the description doesn't fit my usage, that's why I added a new string. I shall change to a different string description.

All right noted! Will change accordingly.

In my ItemExpiringPredicate Class i use a method called days.between to check for the difference in dates and it returns me a type long.

There are actually no ways of going about this. It's either I parse int to long in this class (which I did) or I parse long to int in my ItemExpiringPredicate Class. Since this class name is called ReminderCommandParser, I feel all the parsing should be done here hence I chose the first method.

@Md-Fazil All right I will try to do so.

@JayChenYJ I personally feel it's not good to allow the user to input "reminder 6 hahahaha" as an acceptable input.

We have to split the string because the parameter can go can be 1 or multiple digits so I just do substring, I have to abstract out the number. With input as "reminder 3 hahahaha", I still have to abstract out the 3 using split.

I feel like prefixes should solely be used to detect each attribute of the items. Whereas this is more of detecting a keyword.

All right! I will make it case-insensitive.

All right! Will change accordingly.

All right will change according!

So I should break into 2 statements?

ExpiryDate expiryDate = item.getExpiryDate();

LocalDate itemExpiryDate = expiryDate.expiryDate;

This wouldn't be the case. It will still work regardless of how many spaces are in between the reminder and the number.

Eg. "Reminder 3" would work the same as "Reminder 3"

Basically, I abstract the user input string into arrays of string. The stringArgsArr[0] has to be a number in a string format and the stringArgsArr[1] has to be a "days" or "weeks". With these 2 valid arguments, I will proceed to parse the number of days in total. If no days or weeks are declared in the user input, by default the number given is in timeUnit days.

All right because initially, the plan we discussed was to make the input more lenient to allow the user to input "reminder 3 days" or "reminder 2 weeks". But I can make it work using prefixes as well, but I probably going to do it on another branch "Modify Reminder Feature" for v1.3

All right!

I made changes to the assertion. It's no longer in this class hence the if clause is still valid.

I added the test back.

All right thanks!

I am just following the format of other use cases.

All right will do after i merge the master to this branch! 😄

This itself is a variable already. Does it still count as a magic number though? Because from my understanding, magic numbers are when it appears in the method and reader has no understanding of what the magic number represents.

All right!

All right noted.

All right noted!

Yes they do!

But it was stated that "given today is 30 March".

Solved through other platform.

All right will do! I will create the same method as you.

Nope it wouldn't. The value 1 to 7 signifies the number of days from today. It's not iterating through the items.

I don't think there another way of doing it. I guess it would be fine because streams are usually implemented this way.

All right noted!

all right will do!

All right noted!

I like how detailed and comprehensive this is!

Just a minor typo here, should be "managing your children's contacts"!

Minor english issue, I think it could be "Finds all appointments with names containing any of"?

Did you change this from "option" to "Option" because it's now a class? If yes, I'm not sure if it's necessary for the user to know that it's an Option class, so "option" might make more sense to them?

I think you meant for this to be "FindAppointmentCommand.MESSAGE_USAGE" instead of "FindCommand.MESSAGE_USAGE" right?

Message usage here is also supposed to be FindAppointmentCommand

another minor typo: "appointments" instead of "appointment"

are we standardising "option" or "Option"?

Will users understand what preamble is referring to? Maybe we could rephrase it a bit

Do you think we could include this as one of the examples? I know some of the other commands show examples of what happens when we execute the command after certain commands

Minor thing but maybe instead of "however", we can phrase it into "The sorted state will be saved, so the full address book will also be sorted."?

Maybe this tip can come first instead of the previous one!

maybe you can delete the comment since you don't need it anymore?

maybe you can delete this comment too

Okay! I'll update it accordingly.

Resolved by Clarissa

Same problem for optional phone and address

Resolved by Weicong

Perhaps you could condense this to the same line

This validation allows invalid dates like 99-99-2021. Perhaps you could check it with DateTime classes or use #41 dateUtil?

This may not work for stuff like tar.gz

This might be an extra space

Move these to FileUtils?

Inconsistent spacing between command format and >br>...

Line 286 should be: Advanced users are welcome to update the data directly by making edits to these files.

I think we can rename Picture#isValidFilePath to isValid or something since it checks more than just the path

capital 'i'

typo in 'subtract'

perhaps you can specify that the first date is deleted?

broken link

I'd like to keep Goal as a class that store frequency and not associate it with meetings. I'll just change it to getGoalDeadline or something.

It's updated as a binary file with the same file name.

Maybe use logger instead?

My bad that was supposed to be removed

That is intentional

My bad this was unintended thanks for catching it.

I merely did this as TypicalPersons has a getTypicalPersons method. I suppose we could have a test equivalent of SampleDataUtil in main

jpg and jpeg are the same file format. The different magic number are just subclass of the jpg formats (JFIF, EXIF, etc.)

"set bit" is a correct terminology I believe.

Thanks

Actually it's best to just remove anything after 3 bytes since most JPGs starts with 0xFFD8FF anyways

Byte and byte is treated differently by java and apparently you need explicit casts here lmao

Oops you're right.

I think this point should belong in the UG

with is correct

Conforming to RFC standards is not feasible due to the following reasons:

https://tools.ietf.org/id/draft-seantek-mail-regexen-03.html#case-sensitivity-of-local-part,

https://tools.ietf.org/id/draft-seantek-mail-regexen-03.html#regular-expressions-for-email-addresses,

Also, there are multiple RFC standards, 2822, 5322, 6532, etc., each with conflicting rules. If there really is a need to implement a full blown check for ONE RFC spec, there probably is a need to write a lexer that parses emails, which is too time consuming.

A more elegant way of checking if an email is valid would be to send a mail to that address and expect some form of reply but that is overkill for this project. A simpler fix will be to keep the current isValid() function as it is and the onus is on the user to verify that the email is correct and update the UG accordingly.

This is the output from jshell:

String.format("%s hello", "%s bye", "test")$1 ==> "%s bye hello"

As you can see string substitution is only applied on the first argument and does nothing to the %s in the replaced portion. There doesn't seem to be any situations that forces concatenation of email in the first argument so I don't see any issue with this.

This PR is currently used for CI on git. Please do not merge

How did u manage to solve the error ah?

I was working on a out of date branch and was making use of EventBuilder which was removed in another PR.

Can't replicate issue with provided steps.

Fixed with this PR.

Fixed with the following PRs

217

218

219

merged with this PR

Minor spelling mistake here.

Should be matched instead of matches.

Would it be better if 60 is declared as a constant?

Can I ask what's the consideration for changing .trim() to .stripLeading()?

ratio spelled as ration. Guess you love outfield alot 😄 .

Extra line breaks in lines 71-72 and 74-75.

This lambda expression can be replaced with method reference '''flags.removeIf(currentStrings::contains)'''

commandStrings == null is unreachable. The reason is because if commandStrings is null, a NullPointerException would have been thrown when you called commandStrings.length().

Therefore commandStrings == null should be checked first before you check commandStrings.length() == 0.

I don't think you need to split the commandStrings in line 197.

You can just call commandStrings.startsWith(AddCommand.COMMAND_WORD) and it will still work.

Same here, I do not think it is necessary to split the commandStrings here.

This way to extract the index could potentially be problematic. For example, edit 1 2 3 -n and edit ! 1 -n will be counted as a valid index because any non-digit characters will be removed and they will become 123 and 1 respectively.

I think a better way to deal with this would be to first split the command and command arguments using a Matcher.

You can reference the AddressBookParser for example on how it separates the command and the arguments.

After which, you can depend on the ArgumentTokenizer to get the preamble which will be your index.

You should replace the magic literals here with AddCommand.COMMAND_WORD and EditCommand.COMMAND_WORD.

I agree with @yaowei-soc, maybe saying Results will be shown in alphabetical order might be easier for the user to understand than saying Results will be sorted in dictionary order.

The link should be team/darkdestry-t without the .md

@oeiyiping I have actually pondered over this for some time, did some research and decided to use the same class name.

As mentioned by @justgnohUG, since they are clearly differentiable by file path, and on top of that, there is an extremely low possibility that you will be referencing both Command classes in another class, I don't see any issues.

Feel free to share your thoughts and opinions again.

For this, I followed the original AB3 boolean variable name showHelp and therefore named the boolean variable showAlias.

How about changing both to shouldShowHelp and shouldShowAlias?

I agree with what you have said.

Will update it, push it into the branch and request for your review again later!

Update this code.

There is currently no sample or default aliases data, that is why a new UniqueAliasMap() is initialised here instead.

Added Javadoc for the aliases param.

Updated this code in handleAlias and similarly for handleHelp.

Updated this code.

Updated this code and added missing Javadocs for both parseTagsExceptLast and parseTags.

Will add this once I merge PR #77 into my branch.

Added Javadocs for this unchecked exception.

Would it be okay to refactor this in Milestone 1.3? I will raise an issue after this PR is merged.

Updated the boolean variable to shouldReturnAlias.

This is a temporary solution. I will be looking to change this in the next issue #97 I'm working on.

For Amy, the description strings are in the following format -nAmy while for Bob -n Bob.

Amy has no space between the prefix and the argument itself, while Bob has space.

There wasn't any strong reason when I added the extra space, but what I have in mind was so that there are two variants of test cases.

Added it back.

Updated code for this issue.

Updated code with this suggestion.

Updated code for this issue.

Added this test into code.

Didn't have the idea to use streams when I was writing this code. Agreed that streams would be better, therefore updated the code to use streams.

Added test cases for both different indexes and different tags.

LGTM

In ModelManager, should line 107

updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS); of

public void addPerson(Person person) method

be updated/removed to ensure the filter is persistent even after adding a person?

Other than this, everything else LGTM for Logic component.

This line should not affect the filter after adding a new person

Alright, LGTM.

Conventions are not compulsory to be added for DG and will be tracked and discussed offline. Closing issue.

Implemented in PR #76.

After testing the new prefix parsing implemented in this PR, I think there are fundamentally a few problems here, especially with the filter and alias command.

The filter command is having trouble working as intended. For example, if I want to filter by address, I would need to input filter -a with whitespace behind.
Similar, typing filter should clear all existing filters. However, without trimming the trailing whitespaces, the filter command will recognise the command slightly different and instead filter the list of persons to show just the name.
Alias commands are also having problems when parsing and checking the validity of the commands to be aliased.

LGTM

All done, closing issue.

Closing issue since it is implemented in PR #121

Not implemented in PR #121 yet.

TODO: Missing aliases screenshot

All unfinished parts and images will be pushed back from Milestone 1.3 and updated in Milestone 1.4

Need to add the company and job title flags to command summary. Otherwise LGTM.

Updated User Guide field summary with company and job title flags.

Everyone has completed this requirement. Closing issue.

LGTM overall, but just a note:

When bulk deleting tags eg. tag delete 1 2 3 -t test, when only person 1 has the test tag, the output message will still show that 3 persons have had their test tag deleted.

Not sure if testers will consider this to be a bug (due to the inconsistency in actual effect vs output message), so maybe it would be good to change the output message to reflect a more accurate count, or include a note in the UG stating that this is intended output.

Will be looking at solving this bug in v1.4.

Closing since we are not implementing this

May be related to #205

Steps to reproduce found, commands executed (in order from top to bottom):

find VALUE
list
filter -n

Invalid command typed. Requires space between INDEX and -t tag.

Closing issue, not enough information.

Related to #205

Intended behaviour, filter is persistent even after running list command. To remove filter, run the filter command without any prefixes.

Filter is applied onto the list of persons, and filter is persistent unless it is removed. Closing as behaviour is expected and intended.

Related to #205

Could not replicate the issue. Alias list will disappear from the list view when there is a keystroke.

Thanks for the honest review and suggestions. Closing the issue.

Duplicate of #203. Closing this as #203 has more details.

Fixed with PR #208.

Related to #205

Closing issue as it will not be implemented/fixed in Milestone 1.4.

change to "different predicate" line 37

change to "different command" line 53

could add a few more tests just to be safe, for both failure and success, maybe something like "ModuleTutorial" for user input and predicate is {"Module", "Tutorial"}?

change the comment to "// missing description prefix "

change comment to "invalid description"

Following the comment, the assertParseFailure() in line 115 should have 2 invalid values. Can change either the description or date to an invalid value

similar to a previous comment, should change the description to an invalid one

i think there should be a test for parsing with invalid args

I think it would be better code quality wise to add an else if clause for CommandResult.isUncompletedTab, then the else clause throws an assert false

Nice use of assertions!

line 15 should be deleted

I think .getStatus().toString() is a violation of Law of Demeter

I thought line 26 would automatically fail regardless of whether the tasks in the two arguments of assertNotEquals are the same because ReadOnlyTaskify doesn't have an overridden equals? Cn explain ltr on discord?

ParseExceptions are thrown in line 59 and line 64 for unexpected user input, my assertion in line 57 was mainly to warn whoever make changes to our code against using this public method. It should only be called if the user's argument input passes #hasMultipleValidIndex first, as seen in line 31 of DeleteMultipleCommandParser and line 59 of TaskifyParser.

Sorry, can I clarify which line you are referring to?

done

Close #9

I think it is. However, you will need to use the exit command so that the storage saved the latest updated task list

I'm not entirely sure, but i dont think we need to use exit command? For the test, can't we just instantiate a new TaskifyStub and then check if its tasks are sorted?

could add a few more tests for parsing using TagSearchCommandParser. Have a few additional comments too

By additional comments, do you mean comments to explain the tests?

I'm referring to changing the comments for line 37 of TagContainsKeywordsPredicateTest and line 53 of TagSearchCommandTest (just the first two reviews for this PR)

Duplicated issue

But the user won't be interested in tasks to be done by today but are already completed. Isn't the "Due Today" panel meant for users to make a better decision on which task to do next? There is no point in keeping completed tasks that are due by today to be in that panel

already solved by #155

@noelmathewisaac try running the master code now, the help description for delete should be ok now

Maybe assign Set>Tag> tags = firstTask.getTags(), to make code more readable. But not a big issue.

LGTM!

It might be more "visual" to write this in a few more lines. But no big deal lgtm.

Perhaps it'd be better to use variables and methods to decide the size of String[] expectedTags, since "multiple" doesn't always mean 2.

Looking neat!

nice defensive programming

maybe medium and high's first letter should be capitalized like Low?

cool! Wld be good too if u can include a total workload count for each module? Thought that'd be a nice thing to have.

Hmm "increaseCorrect" kind of confused me on the purpose of the method. Maybe increaseWorkloadDistribution suffices. But not a big problem!

I thought this implementation is quite nice. Good work!

like the defensive code!

maybe its better to keep useful comments?

Nice to see some new unit testing 😃

Okay will do 😃

Yeah u right, I think maybe git pull doesn't record the changes properly?

oops

I thought the initial checkstyle rules stated that a space is needed before the brackets

sure!

will implement after we all agree on this new feature in meeting 😃

resolved 😃

yea haven't added. Resolved now 👍

haha

yeah. This will only happen when u manually edit the json file with module codes which are not supported. So the tasks with invalid module codes will just be ignored

Agree! Will resolve now

All resolved!

Yep! Resolved 😃

ah right!

resolved 😃

yep all resolved 😃

hmm but what do we assert here? As in assert(?)

Ah.. I see. I think it works let me change it

Yep included them. I went out for breakfast halfway lol

seems like I can do this in 1 line. Will change it later!

oops! will change now

Close PR to prevent merging into team repo

Merge to include image in docs/images

lgtm!

Resolve merge conflicts.

I also commented out a chunk of code for 2 tests, pls ignore, I will either add or remove them according to our next discussion 😃

lgtm

I feel that its better to keep things simple, but if its too troublesome maybe we can state somewhere in the DG/UG on the 2 very similar commands. For @AiwassPrime and @umergta 2nd problem, I think the ModuleBook should check the deadlines and recurrence on every start-up so that the "updating" does not get stuck after 2 months of not opening the app.

LGTM, but I also recommend describing the implementation of recurrence in DG and updating the monthly to biweekly in UG

Yep, remember to add to UG.

Looking good!

LGTM

Did you mean to edit all the portfolios?

Did you mean to edit this as well?

Not all commands will be inside. Unless we want to change the implementation

Refer to line 262

Can consider refactor through law of demeter?

Should we delete this instead?

I have edited the help command already in the new PR.

All of the message constrains for commands have a certain format that we use, is that format applicable here?

Is this test case correct?

Did you mean for this month to be valid but the frequency to be invalid?

Should the startTime be made 12:30? Or can it be empty?

Is the javadocs okay in this format?

The UG does not mention about reflecting tasks in the calendar.

The calendar section is intentionally darkened to show that the date is not in the current viewing month.

This feature is intentional. The user only needs to view the most recent upcoming few tasks. Listing out more than 3 would clutter the user's view and lower the efficiency of PlanIT which goes against our user stories.

Merged with refactor command code PR.

This has been resolved in the fix-ped-issues PR.

This has been updated in our latest UG.

This has been fixed in our latest UG.

This has been fixed in the latest UG.

Title is indicated compulsory in the error message since attributes not in [] are compulsory.

This has been fixed in the latest UG.

This has been updated in the latest UG.


* At the most recent input, pressing `Down` arrow key once more clears the text box.


* Pressing `Up` arrow key in the text input panel reverts to earlier input.


            + PREFIX_BIRTHDAY + " 1999-06-01 "

Will writing "You can write anything in remarks, " be more easily understood?

This might sound a little bit ambiguous, as the user may confuse it as the person he wants to edit does not have an empty remark. Maybe can change it to something like “You have already typed something!” ?


            stringSort += "Sorted names ";


                stringSort += "Sorted birthdays ";

and in "chronological order" instead of "ascending" maybe?


                stringSort += "Sorted by upcoming birthdays. ";


                model.getFilteredEventList().size()) + " No events met the requirements.");

Name sounds like a person imo, maybe "titles" to differentiate? like birthday & date, remark & details

requires/ required? require might sound like asking the user to do something


                + "\nNobody met the requirements.");

That's true. I considered LocalDate but wanted to keep to standardising using isValidBirthday boolean to check for validity. Will try to see if I can use both, else will switch to LocalDate. Thanks!

Used LocalDate to check for validity in latest commit.

Separately caught IllegalArgumentException (for invalid year) and DateTimeException (for invalid format) in latest commit.

Adopted in latest commit.

Will leave it to after append is implemented to see how they fit.

This method is following the displayPersons() method in all the delete commands to standardise. Should we change it for all occurrences?

Adopted in latest commit.

Adopted in latest commit

Good catch! Have edited the implementation in latest commit, changed the method name to hasTags that returns a boolean and leaves the addition to execute.

Keeping the original because it looks a bit neater

LGTM

The year can be useful to remember a friend's age though, so you won't eg. accidentally wish your friend. "Happy 21st" when it's their 22nd.

Some ideas (screenshots from online):

I think it can be done for the filtered list, so the user can subset the group he wants to delete the tag from.

Maybe make the new theme a separate file and keep darktheme (for a possible future enhancement to let user switch between themes

Oyea good idea! Have adopted in latest commit

When the user input invalid parameters after a flag, the result is the same as elist and also displays a "Listed all events" success message. Optional though can consider to display another message to remind them about the missing field (can be error or just a message).

eg. elist --any sdjsjhf, or elist --exact xcvxg

(Actually this behaviour is also in list for persons haha can leave it or do "for fun" next time if want)

delete without parameters is the intended replacement for clear and edelete works to clear events list.

((sorry i forgot!!)

Behaviour is already specified in the UG

This is intentional. If user accidentally marks an event as done, he can revert it using undo (in the same session).

Has been documented in the glossary of parameters:

Should the isTooLong method calls be in the constructor instead of the parser? Otherwise direct initialization of names and tags will not trigger the check.

Oh yes, thanks for pointing it out!

Are you missing the "task" in your example?

Is it possible to add a constructor with some parameters instead of just an empty class?

Instead of having separate class files for startDate and endDate, it might be better to condense into a single Date class. Same for the startTime and endTime

Is it possible to add a constructor with some parameters instead of just an empty class?

Javadocs not updates here.

DateTimeFormatter and Regex validation format should follow that of the UG: YYYY-MM-DD

I think you mean ".json" here.

right, missed it. will work on this now.

right, but i think instead of storing a null value ill set it to a default priority value

I am not sure whether Deadline should extends Task. Except from that, LGTM.

Might be better to have a single Date class under models/commons instead since the functionality will be around the same since they are all dates.

Adding of constructors to underlying attribute classes delayed.

Added DG updates to the PR:

Created skeleton DG for future edits
Updated AB3 Storage documentation to Sochedule Storage documentation (closes #158)
Added Implementation details of sortTask into DG

State that initial state is not given

2 checks, the error message split into 2 lines

duplicate

forum

duplicate

noted with thanks

document design choice inside DG

duplicate

abstract into Task class

done

Good explanation. I was thinking if we could add a line mentioning that this would be more most apt for situations where the review could be too long => using the view feature shows more of the review.

Line 39: ... e.g. the review element may contain a long review that is shortened in the main window; using view will be apt for the user to view the whole review.

Good addition 😃

Good addition.

Good additiona

Makes more sense

Good write-up, will check again to see if it mentions everything that's needed to be mentioned. Thank Sidney

Good. Should be clearer

Format of writeup looks good 😃

Good description, very detailed

Add a line spacing, tab the code too, will fix for you

Revised the phrasing for you

Will change to 'entry', thanks 😃

This is now 130.0 (instead of 100), to accommodate for 4 lines of comments shown without scrolling

I did styling on TextArea individually instead of using DarkTheme.css, might have to change in the future if colour scheme changes

Added Food Categories and School Locations enumeration types in the Help guide, to allow users to see what types they can use

Thanks Marcus, yeah probably merged wrongly

Okay, will edit and push again, thanks Sid

Removed internal styling in the FXML file, put into CSS instead

Reduced the window size (height) of the resultDisplayPlaceholder from 200 to 150, felt that it looked better

wrapText="true" is the most important addition here

Basically spaced out the help guide more, as suggested by one reviewer from PED

A whole new UI section has been written up, please take a read 😂

Using the word "KEYWORD" instead of "PARAMETERS" now, applied to all cases throughout. Updated in command summary as well.

Note the syntax. It's been put inside of the [ ]

Marcus, I shifted your Notes and commentary below the Format and Parameters part for the Revise feature

Fixed the link in the HTML user guide. Now redirects correctly to our repo

Centralised Ui image in Readme

Internal: Change codes to fit The Food Diary (ie. no "Persons")

I'll fix the checkstyles

I accidentally merged Marcus' work-in-progress, which is causing checkstyleTest test to fail, but I can't resolve it yet

I'll wait for Marcus to finish the 'edit' function first, then resolve it.

Meanwhile, the HelpWindow is done.

Resolved, used hard reset

Just touched-up the UG, have a look at your sections 😃

Not a feature flaw, this is intended.

UG formatting needs to be addressed

Will think of a way to present it more neatly. Priority should be set to very low. Thanks

Will use angle brackets > > to make it clearer

Extra wIll be removed

This was due to a slip-up on our part on the documentation, which misled you into the wrong syntax.

Will change documentation.

It is inconsistent, will be addressed.

Wrong documentation, will be addressed

Will add this.

Error Message needs to be fixed, agreed

There is a difference between the delete and add documentation. Will disregard non-alphanumeric syntaxes and make it clear to users that it is feature limitation for this app, both in the result display and UG. In a way, the meaning of the name can still be conveyed without these syntaxes, such as @ ! ? ' ...

Image attached is probably wrong and cannot prove that listing is wrong. Besides, find is supposed to return entries that match the user specified condition, and not list in another form of order. Invalid.

Will enhance by making it clear in the UG

In terms of address, we will not check this. This is a Non-functionality requirement: the address will be left to the integrity of the user to decide and fill in appropriately

Enhancement: Will address to users the purpose of putting elipsis in each review that is very lengthy

=> Keep each entry window small

=> view feature is to be used to see the whole review

i.e. whenever an elipsis is present, it is because

A character limit is reached, and the review is truncated
A second review or more, exists

In this context it is not clear what review he added on. We suspect there are 2 reviews

Cheese fries ... 2. !!!11

It's not clear from the result display, that's a separate issue

But it's because of 2 reviews that the elipsis is used to maintain the short height of the entry window

Invalid, bug reporter is unable to reproduce error clearly.

We have checked the following issue and determined that it is working correctly. Tried and tested.

Explanation: addon will take on the filtered list after the find command.

Documentation error, will address.

Will consider different colour scheme for text, thanks.

Might consider changing display output, slightly trivial. Thanks.

While we agree that it is much better to show the error in the revise window, the core functionality of throwing an error whenever an invalid field is typed, still works. We will not address the following. Thanks

Wrong documentation => wrong syntax used in delete command. Will be fixed. Thanks

Documentation error, will fix. Thanks

Will state clearly about the restrictions to names (alphanumeric syntax only). Thanks.

Agreed. Will explain it more clearly. Thank you.

Fixed the separation of words. Thanks

It's technically updated and matching the UG, unclear of which part you feel that is not updated.

Will fix the grammar in the HelpWindow nonetheless. Thanks

Will state clearly in the UG.

Legitimate. Addressed by Sidney, thanks.

Actually, the revise command works upon the edit command. Hence the wording and the meaning is still correct. Thanks

Refer to UG for differentiation between Edit and Revise. Both commands serve a slightly different purpose that we feel is still pivotal to the usage of the app. Revise complements Edit, and provides a much better UI for the user. We are open to more discussion. Good point raised OP. Thank you

Will add categories, and school tags functionality. We feel that this is essential as well. Thanks.

Gokul, I'll handle this, thanks 😃

Legitimate suggestion, we believe so as well. Thank you for highlighting

Will do away with the appendix. Will include pictures relating to the command in the middle of the UG instead

Solved. Thanks

Unable to reproduce this bug, but the first review of the entry should be followed by an ellipsis if the entry has more than 1 review. This has been ensured.

All issues have been solved.

Please see the cleanups for the UG

Each feature has the following: Description, Format, Parameters, Notes (some), Example, Images (some)
New UI section added above of Features. Take a read. It should describe the geist of why we designed The Food Diary as such.

Resolved merge conflict.

Changed to light pink. Thanks

Fixed: entry/entries. Thanks

Isn't toTest.isBefore(acceptableDate) sufficient haha? Because dateToday is before the acceptable date? And Also because remind is for upcoming deadlines right, you could consider making sure all the dates are after today. In case a person/order with a past delivery date is still in the system.

What exactly does "in the context of the FindCommand" mean?

Wait so whenever the input is an add command the request is initialised to "Give me more pineapples."?

Because you implemented request seperately and not in the add command, do you need the request in the addCommand parse function?

Request only takes in the request field right? So does it need a prefix? Because it will always be r/ and never anything else.

Maybe you can use toString() here instead of value

So the request is like a tag?

ohh icic!

Do you need both isSameOrderItem and equals? You could consider using the equals method only because the same order will probably have the same cost also.

Is there any reason why it should only contain alphabets? Maybe can relax it a bit for types like 12" chocolate cake or something haha

Maybe we can consider taking out cost from order item entirely.

Any reason why you took out the number part haha

Where is this method used?

There is no way two help cards will be the same because there are only a few fixed set of commands which are fixed throughout the program which is why I mentioned it. But no harm leaving it.

Okay!

Originally when I switched from the help page to main, I used fillPersonListPanel() in the resetMainWindow() function to fill in the vBox with the person list again, so as I was using it twice I abstracted it out. I changed it to re-using the same person list so I don't need it anymore but forgot to take out the abstraction. Do you think ts better to insert a new person list using fillPersonListPanel() or reuse the old one?

yup

Okay will change all the person and address book references you've pointed out

Lmao okok

Yup, I originally used the function to use from HelpCommandPanel to change from the help to person list there but it was quite inefficient to get everything from there so I ended up just sending a reference to the main window itself to help which is a cyclic dependency now that I think about it, oops probably have to change stuff then.

Hmm the data can change because you can add orders when you are in the help page, you just cannot see them in the panel, so I think that is a better idea too thanks

Oh really? Did not know that haha

I tried using a static method but it cannot access non-static variables so that does not work either

I guess I'll try the association class then, or leave it if I cannot lolol

There's a method underneath haha

The reason for updating the endpoint card later is because?

A possible future refactor could be moving the animation to CSS and have it triggered at the start of execution and end when the result returns. But this is decent at this stage.

Small typo in the comment, should be a post request

Perhaps timeout could be extracted out as a static constant to avoid magic number issues?

perhaps can consider using an actual valid url? This example seems fake.

I suppose the comment is outdated? as it refers to phone, email and address?

is MainStreet a valid address?

the comment is wrong?

Is it necessary? because is Address.ValidAddress already invokes isUrlValid method within in it

Perhaps can logger.error or logger.warning here?

Would the use of American spelling be better? I think it is mentioned somewhere in textbook

Interesting that you passed the message into the parseIndex method to create a custom error message. I think the alternative is the previous structure which is fine as well, as the exception of an index parsing error need not know which command it is in when the exception occurs. It is when the error is being caught at the higher level, the exception is transformed with added details of the command usage. Let's keep to what you have since this change affects various test cases. Just some thoughts.

Alright will remove the two

Thank you, resolved in my updated commit

good catch, fixed in the following commit

I think we should treat the shorthand syntax just as a unique syntax. This is because if u say it is optional, then entries such as 'run -x get ' and 'run -u https://test.com' might be seen as valid.

Also I believe the inconsistency u are referring to is #518, if u look closely, it is not about that but about the table showing different format.

Good point, I have updated the UG such that the format is explained separately.

will remove thx

given that it is never empty, using .get() or orElse() makes no difference, so I think it is better to avoid get

This is the format for all commands, I think it might be ok in terms of an imperative verb, like the requirement for Commit message to start with Update instead of Updates

Same reasoning as above

ok will change

er, ... endpoints do not ...., my grammar is correct, right?

This is the reason why we need all members to run through the UG once.

I think depends on what context do you use list in, right now it seems to be ok without it.

ok thanks, it involves changes to all command so maybe the next person can consider if there is a real need.

no prob

yea more can be added in the next update

😂

Yes sorry, will fix

ok sure

Looks good! 😄 Just a small note, the image and portfolio name needs to match the github handle.

Thanks! Didn't realize this is required. I have renamed accordingly.

@tjtanjin When rendered as HTML it looks like this:

@tjtanjin FYI I will experiment with this for an hour or two now. If anything I will update this thread.

-update1

Use of Platform.runLater(new Runnable() { ... can schedule the execution and update of GUI to a later stage. But right now there is still some lack before displaying Running test and it does not seem to return immediately, which means the place to invoke the call seems to be important and needs to experiment more on this.

LGTM 😃 Just a trivial point that the comment for endpoint attribute in CommandResult is the same as isApiResponse.

Good catch. Fixed and will now merge.

Great job, while you are at it, could you reduce the 5-second delay that emulates the wait time of an API response 🥺

Curious:

how did you fix the lag?

if we are disabling the user's ability to input while running the request, wondering if it will be better if we still show what he entered in the command box and clear it after the request is done? Not sure if this is the case already... for discussion only

I'll make a PR really soon to remove the wait time :3

Shifting Platform.runLater above the sleep code removed the lag (which came from the initial 1 second sleep)

Yup the entered command stays in the command box when frozen 😄

Alright cool, I guess it's the sequence of calls that messed up the thing.

Damn, I am eating my own poison... will fix this when I am home using my desktop...

Sample endpoint 3 periodically returns an empty result with the following error:

"JavaFX Application Thread" java.lang.StackOverflowError

There is no known way for the user to directly cause it as of the time of writing this. It seems completely random. What is worth pointing out is that sample endpoint 3 returns a very long json result which is also reflected in the extra 1 second it takes to load the result into display.

This seems to be a performance issue and we should consider how to address this as soon as possible.

Have tried a few times and wasn't able trigger it, if it is a peculiarity with regards to this API, perhaps we should remove it as of now.

interface as in the screen?

I would prefer to remove it i.e. maximize the space by expanding the result display. This is to keep the UI simple and more consistent by ignoring screen size differences, which might be error-prone because we need to cater to various sizes. Just my 2 cents.

I think this is a great suggestion which I suppose you have specified in #203, let's put it in 1.2b or future milestones...

Given that we can also retrieve the status phrase from response.getStatusLine().getReasonPhrase(), perhaps we can have a hover over effect that when users hover over the status, they can see the textual response phrase.

Perhaps we could try it out and determine if it makes sense visually. My hope is that it should not be displayed in such a way that clutter the essential information that we are trying to show.

If the length of response is a concern, perhaps we can check the response length and limit that to a reasonable number such that we display a proper error message when the length exceeds that.

I think this might be a UI tweak/task where we explore better ways to the layout of the response(both what we extracted out and the actual response entity-body of the API request). Maybe anyone who has thoughts of how our UI could be improved can have a go at this?

Let's start adding required tests as issues to be fixed by 1.2b so that we don't ignore them anymore:)

Ok I think I need to see how find command works first

Seems like it's fixed, @ong6 can verify again.

@tjtanjin the run and send test lowly unreliable they sometimes pass sometimes fail on my comp and I couldn't even commit my work on sourcetree.

Yes @JulietTeoh if run & send have issues, please include in the error message so that I can take a look 👁️

A link to a video on RESTful API is included in help window by #300

I agree with your observation, though instead of removing the menu bar outright, I feel that we can replace it with a banner saying History and Response, much like your original UI mockup. We can discuss this tomorrow along with other UI tweaks we can make this coming week.

Great suggestion, let see what others think tmr

Codecov Report

Merging #327 (0e3a546) into master (a276db4) will decrease coverage by 0.07%.

The diff coverage is 100.00%.

@@ Coverage Diff @@

master #327 +/-

============================================

Coverage 67.99% 67.91% -0.08%

Complexity 557 554 -3

============================================

Files 100 100

Lines 2037 2032 -5

Branches 202 201 -1

============================================

Hits 1385 1380 -5

Misses 588 588

Partials 64 64

Impacted Files Coverage Δ Complexity Δ

...n/java/seedu/us/among/model/endpoint/Endpoint.java 96.51% <ø> (-0.20%) 23.00 <0.00> (-3.00)

...ava/seedu/us/among/logic/commands/EditCommand.java 96.15% <100.00%> (ø) 12.00 <0.00> (ø)

...du/us/among/model/endpoint/UniqueEndpointList.java 92.85% <100.00%> (ø) 21.00 <0.00> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more

Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update a276db4...0e3a546. Read the comment docs.

Dude I deleted a bunch of lines and coverage decreased?

Closed by #393

Anyone is currently working on this? If not I chop first...

Is this going to be added in the form of a new feature?

yes, I am thinking of upArrow to retrieve the last command.

If this gets added before the night can update the UG as well? 😄

yea sure

@tjtanjin After this PR I have nothing else to add for UG, feel free to submit tonight 😃

There are a few areas where we need to address, at least base on the coverage analysis report by IntelliJ. While some areas such as UI could be disregarded, we should try to cover those cases in Logic, Model, and Commons, possibly discuss further on specific work allocation in the afternoon meeting

Possibly discuss the progress on this task in the afternoon meeting. From my perspective, I think the UG styling & structure are of decent quality, largely thanks to @tjtanjin. If all features are finalized, perhaps everyone could go through the UG at least once again just to make sure no stones are left unturned.

https://data.gov.sg/developer

https://github.com/public-apis/public-apis

Resolved after today's meeting.

Closed by #456

Fixed by https://github.com/AY2021S2-CS2103T-T12-4/tp/releases/tag/v1.3.1

Will add a min size restriction so that the display is complete.

need to close the issues not auto closed. @ong6

Possible to explore a larger minimal screen size (in terms of horizontal constraint). I think a size that is larger but slightly smaller than a typical laptop screen size (1024px) should still be reasonable as the app will not be operating on tablets or ipads anyway. @AY2021S2-CS2103T-T12-4/developers thoughts?

Possible to add in that "it should not contain space", just to be extra clear. @ong6 thoughts?

Will try to make the error message clearer.

Fixed by PR #545

Already updated in past PRs.

YES!

@tlylt Is the allowed range mentioned anywhere in case this gets raised as a bug

will add in a section to explain index in UG

perhaps this is the same issue with the quotation mark raised in some other bug reports? If so I think we can close this

I made a hot fix is this ok?

I think this is a great point, does it also apply for all other commands when user just do 'add ' or 'run '? If so we can probably give a parameter cannot be empty error as well.

PS. Ok for other commands they will show invalid command format, which is fine as well.

HI! I think it may just be an error in the formatting and the quotation marks because i could add a Task without any data and header. Sorry for not clarifying further!

Thank you @tashawan23, will close this as we have already resolved this issue.

Already mentioned in UG.

In case it was missed out, the appendix for this and Effort are already included in the DG but still needs quite a lot of touchup.

Yes in view of the seriousness of this section, extra attention may be required.

Implementation(Request)

@tjtanjin I think the diagrams and descriptions are very accurate. A few minor suggestions below:

perhaps step 2 -3 can be rephrased to leave out some low-level details or make the overall flow clearer. I think the few components that are quite important are the following:
- Create a EndpointCaller with the endpoint selected
- EndpointCaller#callEndpoint()
- Generate the right request object to be executed
- Execute the request, perhaps with a mention of HttpUriRequest used
for the design consideration, perhaps instead of talking about error handling, we can talk about the OO design that we use to create a EndpoingCaller -> Request etc. I feel that the design you created is quite extensible and follows OO fashion well, so perhaps we can highlight that. If sticking to error handling, perhaps can include the description of how the exceptions are escalated and handled at various levels.

When I open the app and click on view -> category statistics

should be able to see the same thing using the following data file

budgetbaby.zip

Hi, btw I think I just discovered a possible bug. When the category statistics window is opened, and I typed exit in the command box to exit, the app closes but the graph window is still open. This is not consistent with the behavior of the help window. i.e. the help window will close automatically if the app exits.

This update is no longer required as it was changed in another pull request, can revert to the current master revision.

Sorry I think there was some miscommunication as I also updated the user stories! When merging you can see if you want to keep your version or mine, your version looks good as well.

Is this use case not completed yet?

Is this precondition required? I think it is fair to assume that a list always exists and it might just be empty.

Can move to either the parent package model or to a new package model.appointment

Sorry small change needed here, I made the AppointmentDateTime parsing follow more closely with the user guide so an AM/PM is required now. Setting to 12:00AM instead of 00:00 should work.

I am slightly concerned about having Model extend ScheduleModel in terms of design, but I understand why it's done this way for abstraction and to maintain compatibility. If there is no better solution then it LGTM. Perhaps in a future PR we can abstract the different model interfaces out (for tutor, appointment, etc) and then have Model extend all of them for consistency.

I think that [index] is incorrect. The square brackets indicate that an argument is optional, which it is not here. Furthermore, index and name should be uppercase

Why does this only check for PREFIX_TIME_FROM and PREFIX_TIME_TO? What if PREFIX_TIME_FROM is present but PREFIX DATE is missing?

It should be INDEX [n/NAME]

The argument should be [n/NAME] here

Please restrict pull requests to only the required changes. This pull request includes tutorial code as well as other code updates which is inappropriate for updating the developer guide.

While I really appreciate the creation of the new class AppointmentBook and the other changes, I must warn against these kinds of monolithic PRs. At the current moment there are too many changes to look through and accept, and I am unsure how some of these changes will affect other aspects of the code. I worry that with the amount of changes made we may be unable to fix all the test cases by this week's deadline.

May I suggest splitting this PR by creating new branches and cherry picking the relevant commits?

Duplicate, resolved by #126

There are also pending merge conflicts to resolve before we can approve!

Also see above for my updated comment

Dismissed as it is logically possible to have 0 years of experience (eg. a new tutor)

Side note, I notice we didn't really use Tag attribute from AB3.

Any ideas to use it or just leave it

maybe more user friendly to change to "dob/ " instead of b/

I assume this works on the GUI

Not really proficient on fx language haha

We will shelve number plate away first, its not necessary

I think its break point 3.

But should be ok, can merge this PR and fix it later

The main idea/use cases

User filter by c/Honda+

Means that filter by car brand "honda" only

User filter by c/+Sedan

Means that filter by car type "sedan" only

User filter by c/Honda+Sedan

Means filter by Honda Sedan, means just customer who prefer only honda doesn't pass the filter

Can check again once, once this PR is merged, then can test

Sidenote non-crucial:

Rename x into something meaningful like car

My bad, thanks rajarshi

Redundant comment

take note

idk whether got regression

Hey,

yup yup, my mistake

Already amended it.

Can check it again:)

hey, I just changed to Car@leads psps

Hey im not really sure abt "hash code account"

I amend to return this.hashcode;

this refers to the car object

agreed, changed to Car(String carBrand, String carType)

Yea, should e no issue, very very minor edit of the naming of the java doc commetns, not like adding test code

LOL, this caused recursion, stack overflow, but I corrected it, its works now

I don't think this can be merged.

the photo needs to be your name and show ur face, in low resolution at least, according to the week 7 website requirements

I have already helped to change the about us and added ur image in the pull request aboutus/shizheng

Yup looks good, so we start afresh with the UG and DG

@rajobasu

I will close this, I presume your week 6 tutorial task has been fulfilled.

Don't want to clutter the open pull requests:)

@rajobasu

I will close this, I presume your week 6 tutorial task has been fulfilled.

Don't want to clutter the open pull requests:)

DONT MERGE YET, STILL TESTING

WE ARE DONE ! address is back in!

WAIT LET ME REFACTOR

AFTER I MERGED SHERMAN PR, there were some conflicts, unintended behaviours

This should be at heading level 3 to be consistent with the document.

This should be in the quotes to match the other "examples" you changed.

Should this be in a different format to match the other "examples"? Additionally, perhaps the newline is not appearing as intended?

Should price be Optional>Price>, similar to driver?

STUD->STUB

Perhaps this chunk could be simply passenger.getDriver.map(x -> x.equals(driver)).orElse(false)

This should be in the constructor

NullPointerException is probably the wrong exception to throw

Should this be indices/indexes?

Should we implement it like this (i.e. delete the passengers at index until we hit one with a pool, ignore the rest)? Perhaps a better implementation is to delete all that don't have a pool then error at the end. Also, I think it would be more intuitive if we printed the deleted passengers names rather than size.

Would it be better to use argmultimap here rather than implement a custom parser?

Fixed in commit 1c344c7.

Fixed by commit 0c1b0db on PR #78

This method is used to ensure we don't create a "duplicate" pool, so if we checked for passenger equality, the same driver could potentially be driving 2 pools at the same time as long as the passengers were different.

Hi @vvan-essa, I believe you have the wrong team repo, this is for W10-1 (i.e. G01 - Team 1). Perhaps you can check your team here.

LGTM

Closed by #31

Closes #43

Closed by #41

Closed by #73.

Closes #59.

Closed by #76.

Closes #58.

Closed by #60

Removed most traces of AB3. Remaining traces will be left as-is.

Closed by #103

Closed by #96.

Closed by #125

Something seems missing here?

Very minor suggestion but you can consider renaming the method to updateDeliveryStatusToDelivered just to make the name more descriptive.

Remember to add Javadoc comments for this method and also the other public methods,

There seems to be a stray Javadoc comment here.

Oh XD

Actually true, I guess we can work on making them more descriptive in v1.4

Should be modifiable.

Good catch! I didn't think about sorting them first.

I think this can be better phrased as "The name of the person who placed the order."

Character by definition includes numbers as well. Maybe you can say it can take in alphanumeric characters?

We should probably remove this from the final version 🤣

I followed the same convention as the Person model where they use value to store the value of the object.

Oh yeah good point about the parser! I will edit the regex accordingly.

I think the regex in the Name class does not accept single characters.

oh yes didn't think about that! Will update it accordingly!

I am not really sure whether there are any use cases for equals. Probably will leave it in for now in case it is needed and remove it later if it is not used.

oh yeah that's a good point, will do that

Sounds good!

Fix #12

Fix #5

Fix #14

Apart from the replacement of person by order as already mentioned by @xiinweii98, LGTM as of now.

Fix #78

Fix #105

Fix #106

I believe the peer reviewer had a wrong understanding of what it meant.

I don't think this is invalid. The warning should say that this is not an undo-able action. So we are missing the not.

I am guessing all of these errors have to do with the parsing of the IndexList so assigning to myself.

I think this might be happening because of the regex that I set for order items so probably it isn't able to convert the order description to an order item. Will try to allow the regex to accept special characters as well and see if it works.

Fix #187 #154

Linked to #165

same like before, would it be better to put expectedModel as a class variable?

For expectedModel, would it be better to declare it as a class instance variable instead?

The method name should be modified too since the function no longer returns a boolean while 'isNonZeroUnsignedInteger' sounds like a boolean method name! Maybe 'checkIndexValidity' would be a better name

Also, should the parameter 's' have a more meaningful name instead of simply 's'?

I think there is a typo here, should have a hyphen 'non-positive'

Similar to above, should this method name be modified such that it does not sound like a boolean?

I think you inserted the wrong portfolio under Dylan's one!

Same here and Rachel's one too

I think for the extra spaces, can specify 'extra spaces in between 2 words' since extra spaces before/after the entire name is allowed.

Extra words typo?

Since we are using NAME here, we can just change NAME_IN_LIST to NAME for editMember

Yes, you are right!

Sure

Ok!

Ok sure!

Ok!

Ok sure!

Sure!

@code can refer to the parameter input too

Okay fixed

Ok, noted

okay

lgtm

findTasks is able to find tasks that are not in last view too. Also, findTasks does not search through a task's deadline.

duplicate

UserGuide still seems to reflect "iclose INDEX"? Maybe userguide can be edited to reflect the change

I didn't know how to use multiple tags at first. Can consider putting command example for both:

single tag

'iadd r/10-100 d/Broken light c/Furniture g/ HIGH

multiple tag

'iadd r/10-100 d/Broken light c/Furniture g/ HIGH g/ URGENT

Might want to consider ending sentences with full stops.

Any reason why it differs from UserGuide? XY-YYY in UG vs XY-ABC in help message.

Is it necessary to bring in alloc ? Wdyt.

Ok. I'll add it on my side.

Maybe want to break it up ?

Change to:

Can remove " .... residents matching a specific criteria".

Rationale:

rfind only supports searching based on name. (can't find email etc)

Can change to SunRez

Final detail. But maybe Can add full stop here.

Yes, its optional. I showed two variations in the use examples. But I'll explicitly put that r/ is optional under the radd explanation

removed this chunk of code. Thank for pointing out.

Noted. Added actions to represent the checks. And used guard clauses.

Ok. Added the example command to the userGuide.

Added this point. Thank you.

Good point raised. Will make the changes.

This resident is used solely for allocation command tests.

Good point. Thanks.

I think to follow the java coding standard, this should be changed back to listing imported class explicitly instead of the star import.

Same thing here, should probably import the classes explicitly.

Good work. Good use of SLAP.

Thank you for changing to the correct link. Same for the others.

Thank you for updating the diagram.

Good job on the documentation of implementing review feature.

Could probably add in assertion or requireNonNull for defensive coding. Other than that, good job. Code looks neat and follow SLAP.

Wild card import that you missed out when changing.

Wild card import as well.

Wild card import here as well.

It is okay, the documentation will be reflected as step 1 and step 2 correctly.

It is okay, the user will not be able to search by multiple criteria, it will be either by question or by category.

Thank you for pointing that out. I have changed it.

Yes, thank you for the suggestion. I have tried changing the sequence diagram accordingly.

Unable to replicate this problem.

Avoid using wildcard import, it would be better to list all the import explicitly

Should move this to the default branch of the switch statement.

You can add which methods you implement for this stats command, you can refer to sort and undo/redo implementation for more details "It implements the following operations:" part.

>div markdown="span" class="alert alert-info">ℹ️ Note: The lifeline for StatsCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

>/div>

Add this note under the sequence diagram to indicate the limitation of PlantUML

I'm unable to see the image, you might want to check the link again

Remember to add these 2 commands in the table of content.

You can consider enlarge the image a little since I find the text in your sequence diagram is a bit small.

This should be alias cmd/add al/a right?

Similar as above

Fixed

I suggest that you add an additional constraint to the alias, that it can be alphanumeric only, no space is allowed (similar to the constraint for tags). This can handle this error

Fixed

Invalid bug. This is clearly specified in the User Guide

Not a bug

Need to add a check requireNonNull for alias

Already specify in the documentation

Invalid bug. This is already mentioned in the User Guide

AB3 has the same behaviour.

The flashcards are supposed to be appeared in random order in Review Mode.

Fixed

The question in Review mode is supposed to be appeared in random order.

This feature is similar to AB3

Fixed

Specify that this command only sorts cards currently displayed in list view

Looking good. I think it is okay to merge now

Looking good. I can merge now

Fixed

Err..is this space suppose to be there?

I think one more test for "tag does not exist"?

An empty line between description and parameter section. According to CS2103T coding standard.

Similar issues in the rest of code.

Empty line here.

Here

Should there be some test for execute?

Nice suggestion, updated!

Fixed.

This is what I thought and planned to do, but I implement this way is to achieve consistency with editCommand.

Updated

I have changed this to addTwoTags.... In this case, two and multiple have no difference, and adds a set of methods just for this test is a bit.. wasteful?

Updated with javaDoc

Documentation (UG) updated

Solved

nice suggestion, fixed

I move this line to note of command and delete it in addCommand. It only means, you cannot give an invalid format for the optional field, just because it is optional. Otherwise, some may think since it is optional, the MB will ignore the wrong format and proceed with the rest of the command.

YEY!

This is done!

Done

Done!

Any task without a startTime cannot be recured

#103 is related to this, after command out #103. Bug seems to be fixed. Please check this!

Fixed.

Nice! LGTM although I recommend adding OptionalFieldTest unit tests.

It is implemented.

Now can delete recur and startTime by using editCommand (just like tags).

Example: edit 1 a/

This will delete the startTime of task 1.

hmm i definitely agree with you that we shouldnt stay in the middle.

When implementing the recur command, I thought it was a good to have a command on its own because:

Personally, i would have more 'one-time' tasks than recurring tasks if im using a a task manager. E.g. we would only have 1 assignment 1 in a module. So for recurring tasks, realistically speaking, it should be made into a command rather than just a normal field like 'workload' for example. This is also a justification we can give for the criticism on 'why does recur have to be a command on it's own' if we get it?

With regards to your 1st problem, I am not quite sure as to why the book will stop updating weekly? If a task is recurring weekly, it will refresh the deadline every week regardless, no? Might need some clarification there haha sorry

The second scenario is actually a v important consideration. One possible implementation can be when a user marks task as done, we can update the deadline (and remove starttime maybe), so that the user can see the next deadline already? what do you think? Another possible solution would be to maybe add a next deadline: field in the task card which is way simpler i think?

For the refresh command, i think it is a bit unsafe to add a new command with only a day left because I think quite a few changes would need to be made? and we only have (only a day at most) to implemement the feature? I am scared that it will be too tight for v1.3 deadline?

Overall, I am still fine with either though cuz for me, both ways work fine and (i think) either way can be justified hahaha

For 1, I think your justification is also valid, maybe need a vote?

For 2, let's say you added a task whose deadline is 2021-4-1, recurs daily, and then you close the software. After two months, you open the software again, it will become 2021-4-2. But if you do not enter any command and close the software straight away, the storage will not be updated, it is still 2021-4-1.

Missing UGDG update, other than that LGTM

Yup, I did not get consent from anyone to add this feature. Just put it here first, if everyone thinks this is good. Then I will update those.

In addition, findTag &*(, will also throw exception but never catch

Linked to #136

Maybe can use StoreMando instead of storemando

Instead of “value”, maybe you can change the variable name to “date”

Maybe you can use StoreMando instead of storemando for consistency

Agreed

Would "expiry date" be better than "expiryDate"?

Maybe it will be clearer to put it as "2nd item of the current list" as user may think that it is the overall list.

"sort quantity asc" is now the updated command for sorting items in ascending order of quantity. There is also the "sort quantity desc" command for sorting items in descending order of quantity. You may want to update this! 😃

Just a minor concern, but does the number of spaces matter? e.g. Will 'Room Living ' match 'Living Room'?

I think both are fine. Since it's just an additional word, I think it's ok to leave it as it is!

Just a minor language error, "is neither day(s) or week(s)"

Please look at the updated version. I have modified the sample names, they are now in alphabetical order.

Yes, this will not work, and it is supposed to be that way. This follows the "add" command, where location "bed (lots of whitespaces) room" is considered a different location from "bed room". Hence, when I clear items in location "bed (lots of whitespaces) room", items in location "bed room" will not be deleted.

Noted, I have changed the method name to parse_emptyArg_returnsClearCommand()

I think this is a good suggestion, but not a compulsory implementation since the current implementation is still a workable product. Maybe we can do this in the coming iteration.

looks good!

#10

LGTM

looks good

LGTM!

should be flashcards

need a new line at EoF

Can we turn isNotAns to isAns and flip it inside the method? A bit counter intuitive to read haha

This file (and some other docs) are like no longer needed but for now we just keep them for references bah haha

Perhaps this part can be applied abstraction on? Now the code is getting more and more imperetive haha

should remove this file (user local storage)

I think the .gitignore needs to be modified s.t. data/* won't be version controlled. Previously it was working but now due to some refactoring issues it no longer ignores.

update: (fixed jn)

LGTM but having a separate method like:


public static Flashcard[] getDatabaseOfFlashcards(int numberOfQuestions) {

    return Arrays.copyOfRange(getDatabaseOfFlashcards(), 0, numberofQuestions);

}

is nicer as my pending PR has many tests related to this method so I would imagine there would be lesser conflicts if you have the above instead. Thanks!!!

lgtm if we don't potentially need more booleans for CommandResult (do we?)

It would look fancier if we add descriptive words before users; E.g. as a dilligent user/learner or sth?

should be json array of all tags of one single flashcard

Originally that Interface is to help with a generic method to change the content of flashcardListPanelPlaceHolder. Now the current version it is no longer needed. Will fix it thanks!

This is the dummy history data generation part. Since (now the Score handles the LocalDatetime which is the Score's creation time internally) && (The precision of LocalDatetime is only limited to seconds in our application), a consecutive creation of Score object will result in duplicate Score objects stored (which, by the same principle of how we store Flashcards, will throw an exception).

When the data is no longer dummy, we can safely assume the user would at least take 1 second between finishing the current quiz and finishing the next quiz.

If the above is not a legitimate assumption, I can change my implementations (but some efforts are required).

I forgot since the entire test class is ... dummy :>

Will change it back.

It is essentially because


int index = -1;

        if (isShowingHistory) {

            index = flashcardListPanelPlaceholder.getChildren().indexOf(flashcardListPanel.getRoot());

            if (index != -1) {

                flashcardListPanelPlaceholder.getChildren().set(index, scoreHistoryListPanel.getRoot());

            }

        }

the


indexOf(...)

method would return -1 if the object to look for is not in the List.

Thus a static variable seems not very ok but I kind of cannot think of any elegant solution to it...(?😬)

Wrong PR chosen. Sorry.

The weblink for the previously updated README.md is also incorrect (cs2103t -> cs2103 in url, at line 16), please change it as well. Thanks!

Closed #8

This PR will be made as draft until we formally assign tasks for members on 28th Feb.

Reason: to link with issues created after that

The deadline is soft 👀

This is just to 'figure out', so after you know what is going on you can just self-close it or create a draft PR containing the experiment you ran with the code base.

igtm~ probably should merge this first then merge the flashcard class? because classes like phone etc dont exist anymore and not sure what would happen if we merge into that

😮 I will try to merge your flashcard class first; this one is less dependent on other stuff so should be relatively easy.

@xyzhang00 Some simple modifications are needed for README.md as per W7 tasks. お願いします!

I suggest since commands like

AddCommand
ClearCommand
DeleteCommand
EditCommand
FindCommand

are probably not of our concern here, can I try experimenting to remove them? @Jellybeano This will make morphing slightler easier 😃

Added greetings message for the app.

Perhaps create a PR for it, as it will probably be something useful for the application? 😃

Will close it for now, perhaps will reopen and discuss how to properly merge this during team meeting.

Will close it for now. Perhaps will discuss later how to merge it during team meeting.

@xinweit after I merged my previous PR into the code base there seems to be a conflict. The conflict is in MainWindow.java and it seems its relatively simple to resolve from your side. Its a bit troublesome from my side as I would need to make changes of your PR locally, so can help?

You can resolve it by trying to pull the latest master branch to your GUI-display branch. Thx!! 😃

Just clarify: is it clear now where can this Mode class be potentially useful (i.e. help change the mode of display)?

GJ!!

With this commit the GUI now magically can differentiate between learn mode and quiz mode display. But the modification here is only tentative (and far from elegant) and mainly to provide some idea of how GUI works; to further support the next and check feature, more work needs to be done.

Looks like this PR shares a common commit history with previous one, is this intended?

Err so this PR is a super set of your PR 74 and 76? Sorry I am a bit confused

lgtm!

...

The pr is on thank you @xyzhang00

(hopefully) no need to add any new features

Apologies :_)

lgtm

Got some overlap with #176 haha sorry I forgot to switch branches early; should have no conflicts

Good use of assert statement here!

Plural form here helps to identify the multiple values available, good job!

There's a redundant new line here, can remove if not required.

Good use of for-each loop, its very readable!

Good use of ifPresent!

Rating is from 0-5

Not sure if your revert worked correctly, because my implementation was initially HashMap. I'll merge in yours probably the last since it already takes in my new changes.

Nice catch!

It is now easier for users to read the help window commands with the spacing, good job.

Duplicate Issue that has already been created.

Task Complete.

Completed Task.

Feature already implemented in AddressBook.

Already implemented in AddressBook.

Completed.

Tutorial, not required to merge.

Sidney updated the UI.

Revise feature is supposed to allow for edits on top of existing data. The current edit feature replaces existing data when editing. The shortcut keys, such as Ctrl+S/Command+S to save, Esc and TAB keys already allows users to quickly navigate within the window which is for for fast typists.

The program only accounts for 1 user, not multiple. However, we will add in square brackets for multiple reviews in the logging box so that it is clearer.

Similiar to #145

Increase padding between tags and reviews

Sorry, i pull requested to the wrong team project.


**View Tutor** | `view_tutor INDEX`, <br> e.g. `view_tutor 1`

I don't think the variable appointmentList and its respective methods are required in the Appointment class, since Yuting is handling the List classes, which already have an AppointmentList.

This line may not be required, as referenced to #12, Tag is not a superclass of Name, Email and Gender.

I think we might need another dateTime variable here because from what I see, the tutee can only edit either the timeFrom or timeTo. If we update one of them, the another's value will be overridden due to how updatedTimeFrom and updatedTimeTo is instantiated. Maybe @kingsleykuan can double confirm on this? Thanks! The rest of the codes LGTM!

This should be EditBudgetCommand instead?

I think you forgotten to remove the debugging print statement

I think you forgotten to remove the debugging print statement here as well

You have used the Enum correctly! Just a small recommendation, sorry I kind of forget how secondary school grading works, but maybe the Enum can accepts values such as "A1", "A2" to make it as close to the real world context? Otherwise it's fine to retain as single alphabet! Not an alarming issue!

I think you forgot to remove debugging print statement here

Noted! Will omit during the merge.

This meant to serve as a base template as I modified the styling slightly. Can choose to adopt this styling or go with the default style from AB3.

Noted, I have removed it & committed.

Noted, then I'll shift it back to Model for meantime. If we decided to adopt this approach then I'll reinstate back in this file

Resolved the merge conflicts and used the Ui image from the master branch instead.

Will resolve the conflicts after PR #2 is approved due to accidental merging of branches.

Noted @kingsleykuan, will proceed to merge and remove the stubs in a followup PR instead since there shouldn't be any interference with the rest of the codes.

In meantime, please also try to fix the build error (I think it's located in the test cases) as we have turned back on the blocking of merge if there's any build error.

Fixed merge conflicts and shifting of Schedule's interface methods to Model.java.

Rmb to update the java doc!!

Time is not a compulsory field for event right? Only date is if Im not wrong! Is it necessary to throw missing field message format?

Maybe you meant Jackson-friendly adapted "task" object!

in the adapted task

Priority is an optional field?

Rmb to edit the java doc!

Maybe can edit this javadoc or can leave it when removing dependency!!

Rmb to update the javadoc!!

Javadoc not matching the method!! You may wanna update

That is the intention of the feature. I don't think hard to test because of the intention of the feature is considered as an issue. Moreover, it is quite unreasonable to label it as high severity.

why not..

Was this always there as a duplicate since the initial commit?

Missing Equality Check test


command = 1 -&gt; false

command = null -&gt; false

command = new command of same parameter -&gt; true

command = same command -&gt; true

command = different command -&gt; false

Missing checks


predicate = 1 -&gt; false

predicate = null -&gt; false

predicate = same predicate object -&gt; true

You missed the Same object check

Hmm not sure why test coverage missed it but I guess its fine.

Do either of the following

Sort the collection again in the test case and compare element by element
Use the string comparator to compare every element with its subsequent element in a for loop

The test is to check lexicographical.

If the add command is renamed and no command starts with A, this test fails incorrectly.
If the add command remains but the list is [add, find, alias, edit, delete], this test passes incorrectly.

You seem to have misunderstood my approach. This is not testing the sorting order of your getAutocompleteCommands. This is testing the sorting order of the Collections.sort function.

What you should be doing is

get a completely clean list of command unrelated to your autocomplete command.
Sort that list of commands as per your expected sorting order Collections.sort(cleanlist)
Iterate through this clean sorted list and compare against your test list

This existing test will fail to achieve its purpose when

logic.getAutocompleteCommand("") returns [add, clear, alias, find, delete]
Collections.sort sorts it into the correct order
asserts verify that its the correct order.
Note that the command actually returned a bad order but all the asserts passed.

Any particular reason why an extra space is added for some test strings and not others?

Makes sense sure. Just a potential issue if and when we decide to fix the prefix to enforce the space. Otherwise LGTM

Fixed in https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/76/commits/c6feea1138bcaae29f8cbfd1591ee31680590f7a

It isnt intended but has been the case for the original Name predicate. I think as a predicate its equal technically but shouldnt cause any issue if it isnt.

Non-issue. As comment says, white space is part of the test case.

Fixed to put whitespace between prefix but not between keywords. The whitespace is part of test case

Fixed

closed with #39 #40 #37 #38 #41

closed as duplicate of #2

Depends on #85

Depends on #84

Depends on #85

Closed by #130

Closed in #129

Investigating right now.

Issue is due to the webkit package

Is the large file an issue?

User story #96

We implemented a web view using javafx webview

https://github.com/Cheng20010201/ped/issues/3

Need more info. It is similar. How so, and how is it different.

Nevermind. Info is given in the title.

Resolve by key check after toLowerCase

Closed as duplicate of #201 and #200

May be related to #205

Needs more specific 100% reproductivity reproduction steps.

To document the lack of email client will cause no action to be performed.

Change on the application result output as well.

Do a toLowerCase existing tags check

May be related to #205

Changes

Output message to include and should not contain spaces
Documentation should remove invalid exmple

Duplicate of #152

Not exactly a duplicate

Documentation to include that no flags will restore original filter

Closed as non issue

This is not an issue. Output is as expected.

To change the wording of output and document that the adding of existing tags will not change the set of tags.

May be related to #205

Related to #82

Title of Window

Documentation should include that selection is incremental and can be cleared using select clear

Note that your file name is not lower case.

can you replace lines 1-2 with these


---

layout: page

title: User Guide

I think this is needed for the website to display UG and DG links and you removed these lines in the previous PR.

Currently, if you check the netlify build for the website, there are no links to the UG and DG

Could you update the user stories to show the edit status and sort by deadline stories. Also, I think all the priorities should be High or Medium for the current user stories

I think exceptions are more suitable as we are trying to figure out errors with user input

Should an exception be used here instead?

I was commenting on your comment on line 63 haha

Ok makes sense

Should we also add explanation for what each of the statuses mean? Also there's a space missing in line 132

Ok can

The \ is appearing as part of the text. I think you should remove it.

Ok, will add! The tests I wrote so far follow the same format as the ones for the find command.

The tests in TagSearchCommandParserTest checks if the parser splits on space correctly. The test you mentioned should be part of TagContainsKeywordsPredicateTest. I have added it there.

Nope that was for debugging, good catch

I think scene builder automatically changed haha

I am still updating haha. Can help merge this version first

could add a few more tests for parsing using TagSearchCommandParser. Have a few additional comments too

By additional comments, do you mean comments to explain the tests?

could add a few more tests for parsing using TagSearchCommandParser. Have a few additional comments too

By additional comments, do you mean comments to explain the tests?

I'm referring to changing the comments for line 37 of TagContainsKeywordsPredicateTest and line 53 of TagSearchCommandTest (just the first two reviews for this PR)

ohh okay 👍

would be good to test if the list of tasks is sorted after reopening the app

I think it is. However, you will need to use the exit command so that the storage saved the latest updated task list

If its too much trouble to use the exit function then just writing unit tests to see if the sorting logic works correctly would be good.

Closes #49

Closes #52

This is expected behaviour. Due today will display all the tasks with the current days date regardless of status

Changing this will require a lot of changes in the codebase especially in the implementation of the edit command. For now, we can consider renaming the panel to "Today's Tasks" and push the feature to post v1.4.

Status has been changed from Not Done -> Uncompleted and in progress-> Expired

statuses have been changed and switching commands have been updated

Updated tags so that newly added commands have uncompleted status

Same as #114

Since we have disabled switching of tabs through click and the user can use the dropdown arrow on the side to view all the tab names, I think this issue is not relevant. @CSmortal @hengyongming @khiaxeng what do you guys think?

Tester misunderstood docs. the first example was one tag t/ CS2103T and the second example was two different tags t/ CS2103T t/assignment.

This might be violating Law of Demeter, could there be better way to abstract these type of statements?

What about creating methods to switch to learn mode inside the model manager?

Is the change back to AddressBookTest intentional? :0

Is there a reason for calling sleep?

What is this index referring to? Would it be better to set it as a static variable at the start instead of a magic number?

Is there a reason for these 2 list panels to implement list panel? extending UiPart>Region> seems to be sufficient OOP for me :0

I think there is a .contains() method?

I think it is a valid assumption! Probably will be better to document it down in the javadoc later.

Is there a need for isAllTags exist on the right side of operation?

Edited, thanks.

I changed it to isQuestion, hopefully this is better!

Ok!

Check command requires an argument. The command given was both invalid command format and invalid command as the app is not in quiz session yet. However, invalid command format is caught earlier and hence thrown earlier. If a valid check command is provided, it will display the correct error message.

Allow calling learn in learn mode and quiz in quiz mode to facilitate update of tags

@Cheng20010201 I refactored parts of score while doing this, you might want to take a look and see if it is reasonable 😄

You may want to consider removing these extra blank comment lines 😃

Nice use of assertions!

Sorry, just to clarify, is SCHOOL_RESIDENCE now optional? I may be mistaken but based on my understanding, it is still an optional field?

Just to clarify as well, I am unsure as to the reason for adding '>br>' for Add Appointment but not for Edit Appointment and Delete Appointment.

Apologies for the oversight! I understand now.

Thank you! 😃

Maybe this line could also clarify the reason why it is unable to detect changes is because matriculation number is not supposed to be editable?

Ohhh I understood 'unable to detect changes' as if matric number is edited in json file, the application will not detect the edit (so matric number will remain unchanged in the application UI)! Not sure if it is just me but would this phrasing be ambiguous?

I agree! Thank you Si Ting!

To clarify, the whole MESSAGE_NONEXISTENT_APPOINTMENT line was deleted because it was not used anywhere (greyed out). The "Found student with ... also be listed" string is for MESSAGE_STUDENTS_AND_APPOINTMENT_FOUND.

I feel this is not technically a bug, we can KIV first and focus on the more important bugs. How about the rest?

Actually, how do you validate an address? Different housing types would have different formats? (e.g. 29 Defie Road for landed residences and Blk 123 Bedok St 4 #10-04 for HDBs)

I think this is not very important as well, we should focus on the more important bugs then come back to this.

We can always say that we allow for overseas phone numbers as well. However, a limitation I can think of is that the user can input > 8 digits which is most likely not a valid phone number.

I agree with what you said.

I agree with Yien and its hard to validate name since there's no fixed rules to validate it..

I think if validate is just limit to alphabets (?) but I have this friend who has a hyphen in her legal name too so we can decide how we do this later on if we do it.

Yes I think it is valid. I will be fixing it.

Would that be too many? If it is then we just pick a few out of these? Those that would benefit the most from screenshots.

Documentation Bug

Documentation Bug (same as #213)

Documentation Bug

Will check again when json fields are validated.

PR #251 solves this if I am not wrong. Can I close this? @SiTingST @fairyinabottle4

Issue closed because this should not be in UG, the user does not really need to know this. NUS has many international students and we cannot assume ALL of them have a Singapore number. As such, overseas numbers should be accepted as well so we cannot restrict it to 8 digits. If this is seen as a bug in actual PE, we will explain as above.

Just this > **Examples** has an extra space compared to every other ones in markdown, but visual wise does not change anything

Perhaps Deleting a passenger would be more consistent

If I'm not wrong, the regex doesn't validate whether the number given is a negative number or not right?

maybe can do ^[1-9] at start of the pattern to make sure there's no negative sign I guess?

Can also test for negative price as those should be invalid too!

Thanks for the info!

Maybe change the name to NAME_POOL e.g. HOME_POOL and also for other variables ?

maybe can change to case PREFIX_NAME.toString() and the others also for better understanding

should be e.g. instead of e.g.,?

Same for this and the rows below

Good suggestion! The invalid names and phone number currently in CommandTestUtil are with prefixes e.g. " " + PREFIX_TAG + "hubby*", perhaps I can create constants without prefixes to be used and rename existing ones for less confusion?

LGTM, all links added are correct also

LGTM

LGTM also

LGTM

The string "null" could be "no_url" as the insurance agent may not know what is a null when checking the json file.

The log message could be more appropriate.

The code here does not capture the error where user input "lock" has no password.

The CommandResult could have SUCCESS_MESSAGE only since the other values are false.

There could be a break here.

Could include other attribute like address or phone as some clients in the same family might live in the same house or they give their shared home number or email, unless the insurance agent group the family as one client.

Noted thanks for the review

is it just me or is this repeated

here

A Japanese character/word

Yes, it is needed to make sure that the boolean keeps track of the existance of all tags. Like for example if there was a tag that didn't exist, and checkIfTagExists returns false, but subsequent tags exist, the isAllTagsExist boolean will be updated to the last check made.

Enters Quiz mode

Normal users probably will have problems with what 2^32 is.

Probably shouldn't be leaving debugging lines in our actual code.

Wait were we supposed to paste our sections of the UG here?

Imeanlike sure but maybe sometime later. This isn't gonna make or break it for us.

Moved my changes from the other pr here. Now this pr also solves the issue where the input tag does not exist on any flashcards.

i am now tho

Was solved by Xinwei's exception check in Quiz class.

Hey can you remove the role part, since for now I think we are randomly distributing tasks so that we all get to learn equally? We discussed this yesterday i guess. otherwise LGTM!

Hey, I actually changed the names from Car@Tinder to Car@leads as you told yesterday, can you reflect these changes?

LGTM

change this to normal stream, parallel stream just makes things slower on such a small scale.

good idea would be to trim the filterString that you get

um, i dont get why this is so? why just check objects for equality, same information should have same object. I think you should add another field like numberplate if you are worried about collisions. What you can do is if there is no explicit numberplate then just assign a random number to the numberplate (best random number is just the current timestamp in nanoseconds).

why did you delete this? we want to support multiple cars owned by the customer, all the code is written like that.

ig so, we can add this as a testcase handling later on no worries

@nighoggDatatype Need to merge the conflicts! After that will accept

Yep, LGTM

List>Appointment> should be replaced with ObservableList>Appointment>

You can create a MESSAGE_INVALID_APPOINTMENT_DISPLAYED_INDEX to replace MESSAGE_INVALID_PATIENT_DISPLAYED_INDEX here.

This should be replaced with

'(patient.equals(toCheck.getPatient())

            || doctor.equals(toCheck.getDoctor()))

            && getTimeslot().hasOverlap(toCheck.getTimeslot());'

docs to update to EditAppointmentCommand.

I don't think this is needed since it functions the same as hasAppointment method.

I don't think this is needed as it functions the same as contains.

I don't think this is needed as it functions the same as hasConflict.

Yes, it is intended to be in the format of delete-patient --force INDEX, which is indicated in FORCE_DELETE_MESSAGE_USAGE. Will edit the javadocs so that it's clearer.

Yes I think it might not need to be in the try block, will edit later. The reason why I wrote isForceDelete is to avoid the possibility of isForceDelete being not instantialized. Another way is shifting the try block inside the first if statement, which may be a little ugly, almost arrowhead style. What are your thoughts?

The reason why I do it this way is so that if the index is wrong for delete-patient --force notAnIndex, the parseException will be raised as well. I will add in an invalid index message before the message usage to improve on the clarity of the exception.

My bad, missed out on this one

Meant to align the tail of the comment, will commit the changes.

I don't think an exception is needed as indexToParse = args by default, so aisjdhabakahbakshdbankdjashb 1 will be captured as a ParseException when ParserUtil calls parseIndex on it.

Yes, it'll look like this:

I think we should be specific, if not one might think clear or list on their own are valid commands. Will add in the 3 clear commands.

I guess this is a problem since we mentioned that:

"Parameters can be in any order.

e.g. if the command format specifies n/NAME p/PHONE_NUMBER, p/PHONE_NUMBER n/NAME is also acceptable."

Would it be better if we say parameters with prefixes e.g. n/ can be in any order to avoid confusion?

I will also add in that --force before the INDEX is required in the sentence for greater clarity.

Resolved with links from patient commands to doctor commands and the other way round. (bidirectional links)

Sochedule?

No need to check null?

Maybe consider YYYY-MM-DD (all upper, instead of partially upper), then hh:mm (all lower)

Should this be removed or it's waiting for model dependencies removal?

I think for user, "YYYY-MM-DD" would be better, as "uuuu-MM-DD" is lower level stuff.

(Side info: "uuuu-MM-DD" can deal with leap year 0229 problem, generally speaking, it's just a strict version of "yyyy-MM-DD")

The exampleDate can consider to be put in CommandTestUtil as a constant, otherwise, it looks like magic number.

Once these magic dates are put in CommandTestUtil, you can just import and use them without initialising them again.

Thanks for spotting the error:)

Yeah I think Deadline should under Task package. LGTM:)

Can these changes can pass all the current unit tests?

It didn't pass, since the unit tests now are mostly old ones that haven't been updated yet.

Need to enable four tests in AddTaskCommandParserTest and AddEventCommandParserTest

Yeah correct, now is like user can't even input the thing and stuck there

Specify in UG that can add an ongoing event

Add Documentation

I'll fix this

duplicates

Fixed by #322

Perhaps this line can be broken down for better readability?

Maybe this can be phrased as "clears all entries from the address book if tags are not specified..."

Should "the option" be capitalised?

Should this example be changed to match the usage

Should this be thrown as a warning instead?

Should contacts be capitalised here?

Since listAppt currently doesn't have options, perhaps this can be removed?

I was thinking about that too, but when they used step 1, step 2... it was to describe the actions a user performs. Mine is more of the sequence of how the code handles the scenario, so I was not sure if it will be confusing if I use the same convention.

addAppt implemented when setting up appointment logic.

Resolved by #132

Perhaps this can be named AddVenueCommand?

Perhaps throwing VenueNotFoundException would be better?

I think CommandException is correct for commands.

Is there an issue with modifying the list while streaming it?

Use removeIf instead possibly

Ok but change the command name when it is fully implemented

This is still work in progress, do not merge for now

Hi @wangtao0717 I believe you should change the filename to your github_username_in_lower_case as specified on the website. Otherwise this LGTM!

Hi @wangtao0717 very minor typo here, will approve when this is fixed!

@awzhenyi Very minor but there is a typo (double space) between 'the' and 'user'. Otherwise, LGTM!

@jaredtengsw minor but apartment should be changed to residence here!

Apartments should be changed to residences

Just to clarify, should upcoming bookings include bookings on the current date and bookings 7 days from the current date? The use of isAfter and isBefore will return false for boundary values.

@VRSoorya So booking should be its own package under model? Because I recall someone saying booking should be under residence, but I can have it in its own package if that works better

This sounds sensible, I have replaced references to "Amy" and "Bob" with "Booking1" and "Booking2" respectively.

Fixes #29

LGTM! @wangtao0717 should this say 'fixes #45' or are there more changes to be made?

Addressed by #110

To clarify, the current Name class should be more restrictive in the types of symbols accepted (people's names should not have special characters such as ^) while there are no restrictions for ResidenceName (apart from only whitespaces)?

Maybe can create a constant for DateTimeFormatter, same for the output to string

Some notes are bold, while others ain't. I think it would be better if it was consistent

Same comment as above.

maybe using toEditIndex makes its purpose more obv?

Good use of constants!

maybe referencing what the booleans are used for would make them clearer?

TitleContainsKeywordPredicate implements Predicate. Therefore in terms of LSP, having it as Predicate would be more accurate.

Complete UiMockup image

Solved in PR #28

To delete: Address, Email, and Phone

Delete Address #63

Delete Email #64

#67 Add Exam class

#85 Add ExamList

for assignment and assignment list

add, edit, clear, find, delete, done

I can do clear, find and generaleventlist

Done for modules and persons

Clear event too

I can do clear, find and generaleventlist

clear, find and generaleventlist are done.

find is based on description

Add to UG to say this functionality clear all tags.

We encourage students to have the freedom of inputting their own modules. This includes customized version, hence we do not check that a module title is invalid.

Remove square brackets

Make the name not optional in UG. Ensure error msg for edit person is updated too

Update UG to say that commands are case insensitive

Update UG to say benefits of both GUI and CLI

@jellymias Can you include in the intro that RemindMe reaps both benefits, something along that line

Do you think we need an exam list as well since a module can take in multiple exams at the same time.

If this is only for GeneralEvent, is it better to have AddGeneralEventCommand instead to be more specific and clear

Perhaps can add example of the exact delete exam command

maybe editIndex can be a better attribute name in this context.

Possible assertions can be put here to detect null values after assigning.

is there a reason to not use TitleContainsKeywordsPredicate

Update CI status, codecov, sitemap and acknowledgement

Fixes #61 #62

solves #66 #111

Should this be 'Tutor Tracker'?

(minor) Will removing 'I can' be better?

should it be 'deletes the application'?

Tutor Tracker

should Set>Tag> be TagList?

Thank you. This part is deleted.

Thanks guys! I'll merge this PR first in order to continue adding the command and I'll make the changes based on Vinleon's suggestion later:)

Good job in adding both valid and invalid prices

Good idea to check all the different price ranges. Perhaps consider checking for the case when the price is MAX_INT and MIN_INT as well?

Good idea to hide windows!

Should it be 'entry' instead of 'food review'?

Good Addition to make the feature more clear for users

Merge Gokul About us

Thanks for catching this! We will fix this

Thanks for catching this bug! we will fix this

We will standardize! Thanks for reporting

Thank you for pointing it out! we will fix this

Since no feature improvements are allowed in v1.4, we will close this issue

Appendix section removed by @Donavanty in pr #185

We copy this from the original implementation of AddressBook

Agree, to be consistent with the other prefixes in the CliSyntax.java, I think w/, h/ and mc/ is better

ListCommandCommand? How about ListOfCommandsCommand?

Add my github link also for consistency

please add my github link here

I have moved it inside the command itself

merged already

This phrasing is to be consistent with every other command because the other commands have the format of what the command do followed by whether it is dedicated to note/contact.

The ... means that you can add multiple tags so arguments like addnote c/Do Homework t/tag1 t/tag2 is allowed

Maybe something like clear appointment and clear property? As well as a clear all to clear everything at once?

It seems weird to me that next() for Completion returns a Completion?

Since it implements Status it needs to have a next(), and Completion shouldn't lead to any new statuses anyway, so I guess it's fine to return itself? Creating new objects at a terminal step may lead to some undesirable side effects. By checking if .next() returns the same object it can even be used to check if something is calling .next() on a Completion.

Very minor nitpick, but n/ here should be referring to the property name right? Would it be good to use a property name for the example instead?

Will the user be able to change back to DarkTheme?

i think according to the validation regex price can have cents. Should we still consider that for the price?

The and here is referring to the logical AND, I think I made it quite ambiguous here. Will go change it.

Wasn't thinking straight when writing this. Somehow thought this part will be combined with appointments in the future.

For completeness I guess, maybe can remove.

The keywords have no prefixes though, so I think a for loop like this would be more convenient.

I don't think any property prices bother including the cents part though, other than perhaps after tax calculations? But anyway will go add another field.

Doing that causes quite a number of tests to fail due to having hardcoded comparisons. Since most tests don't actually interact with Client or AskingPrice, it is safer to just implement a new method for properties with clients.

changed to dollars + cents.

I think I meant to say if the user is searching for bob, the command will search both lists for properties with client bob and appointments with Meet bob. I'm using name here since it searches for the string in the name attribute of appointments.

added 313 to 315

oops sry.

The default keywords don't have any prefixes though.

Alright sure.

Alright sure. Anyway I just realised a user can search for containing all given tags by using multiple r/ parameters.

Oh right eveything has prefix. Ok will go change the find name one to n/.

Need to decide on how to store housing type first before this can be implemented.

Add github actions badge
Add acknowledgement

Add use cases for everyone's own parts.

Closed as there are changes made to the branch.

15 March discussion:

Limited set of tags
Housing types
Currently not under tag but under property type
Reuse the code from addressbook
Add extra tags: bedroom and bathroom numbers, both existing as compulsary tags

What do the others think of this refactoring of PocketEstateParser?

Looks fine to me, passing checks means the other functions are proabably not affected much anyway.

closed with #167

Closed due to another branch continuing from here.

closes #196

Achieved with usage messages and user guide.

closed with #223

It might be needed as we should allow the user to add themselves to the system regardless of whether they have been assigned a driver or not

Is the toString method call required? if this Pr is just for renaming was removing the call a mistake?

I think you might have to 'change delete my profile to 'delete employee profile' as the user is the HR exec now and they're managing other employee's profiles.

Is it necessary to update the passenger list after adding the pool? As far as I understand there shouldn't be a change in the passenger list after pooling?

Is there a better way to test if the right pool is shown instead of checking the size of the filteredlist? maybe getting the pool object from the filtered list and asserting that it equals an expected pool?

Thanks for the comment! To clarify, the VALID_[VARIABLE] constants are not used as replacements for user input but rather for the personbuilder and other such utility functions during testing. As for tests concerning user inputs, the constants declared below of the form [VARIABLE]_DESC_BOB, and as they are supposed to emulate user inputs, they are of the String datatype. Hope this addresses your comment!

Thanks for the comment! I will make the relevant changes.

Oh nice catch! I'll make the required changes!

Thanks for bringing this up. I think it might be useful as it would prevent the violation of the Law of Demeter when other classes try to call for the TripTime strings.

Good point. I removed it as Intellij suggested doing so as double data types aren't nullable but I'll add it in just in case.

Nice catch! I didn't think of it but I realised when testing that the \d+ already catches negative cases as "-" is not a digit and so the input string would fail the isValidPrice check!

You're right. I was intending to throw the same exception that the requireAllNotNull() check in the line above it does but an illegal argument exception would be more fitting.

Noted thanks for the heads up.

Resolve issue #10

Good change! The addition of new lines after each component of the flashcard will help to improve readability.

Should this be "This card already exists in FlashBack." instead?

Should this be step 2 instead of step 1?

Perhaps you should also state that the user can search by specifying both the question and category. eg. "find q/ >keyword> c/ >keyword>".

Should we list out all the imports instead of using a wildcard?

Great suggestion. I have updated the section accordingly.

Fixed. It should show now.

Added. Also fixed the broken links in the table of content.

Updated, thanks for mentioning!

LGTM!

Good job! Code is written in high quality with evident use of OOP and abstraction.

LGTM! Tests are well written and have a good coverage of the Find command.

LGTM! Code is concise and easy to understand.

Looks good! Documentation is detailed and well written.

CI failed to run

Shouldn't this be under 1a? Since you type the index in step 1.

Shouldn't there be a MSS for this where you state that you request for the list of events to be set to the current date?

Consequently you can put this under extensions 1a 😃

Can just use getFilteredEventList().size() + 1

Are all these commented out test supposed to be added back in later?

Is the else supposed to return a cross instead of empty string? If not maybe change the javadoc accordingly.

This is pretty inefficient I guess, can change to utilise a Set.

Set>Event> set = new HashSet>>(events);

return set.size() == events.size();

Alternatively (slightly faster time):

Set>Event> set = new HashSet>>();

for (Event e: events)

if (!set.add(e)) return false;

return true;

Ok!

Alright, I agree with the standardisation requirement. However, since the purpose of this PR is to implement Events, I think it is out of scope to change the UniquePersonList as well to maintain standardisation. We can start a new issue for this.

Added in latest commit, multiple tags shouldn't be allowed, but can start an issue to add that functionality.

This one I not sure but I think because the purpose is to list all tags then tags is better?

Adopted in latest commit.

Changed to "noNameAndNoTag" in latest commit.

Adopted in latest commit.

Adopted suggestion!

LGTM

Will implement/fix find, list, tags methods

LGTM

But when invalid, do we want it to throw error? or isit better to just do nothing

I think we should throw an error so the user understands what is wrong if they try to use the feature wrongly.

Invalid Index:

Out of Bounds Index:

Very minor, but should the JsonProperty be "status" instead of "isDone"?

Perhaps checking whether index > 0 is unnecessary because the error would be thrown from parseIndex method in ParseUtil class?

I get the idea but I think this line could be confusing to some people. Could consider removing the year, like "e.g. 29-02, a date only valid in a leap year" or something to that extent?

Hmm how about "e.g. 29-02-2021, because 29-02 is not a valid date in a non-leap year"

lgtm

Similar to #130

Similar to #142

Appropriate error message since the datetime input by user is blank and not in the specified format dd-MM-yyyy HH:mm

edit 0 has been handled to throw "Index must be a non-zero positive integer". However edit 99 will appropriately throw "at least one field to edit must be provided" because the command did not follow specified format. Once user adds at least one parameter to edit, then invalid index error will be displayed.

Fixed via #189

Split into #232 and #233

Should "Appointment's %s field is missing!" be "Property's %s field is missing!"?

Should update the comment to properties

Should empty Appointment be empty AppointmentBook?

Should update address book to property book?

Updated already

I think it should be one command for both property book and address book? Which one is better?

Ok, I got what you mean. So split the command into 3

Ahhaha, this one is not implemented yet

Not implemented in its class. I will try to add it later

Thanks, will update it

Ok, will update it

Fixed

It is strange that it is displayed as "9:00am" on my laptop. maybe due to java versions?

Restored

Forgot to mention, I changed the sorting order to be compulsory for easier implementation

actually %1$s is replaced by the string "asc" or "desc"

The test for SortAppointmentCommand is not done yet. The current content is simply copied from another file

Yes, so do not merge until I finish the rest

Should be able to merge now. Finished adding tests

The method actually sorts the appointment list but the displayed filtered appointment list is sorted accordingly. Should I change back the javadoc comment?

updated

Fixed. Thanks!

Fixed

Actually, in AppointmentBook::resetData, only the appointmentList gets replaced

I have added getCommandWord(String) in PocketEstateParser

can

fixed

Thanks for your kind suggestion.

Sure!

Only supports undo for add, delete, edit commands. Tests will be added later.

not too important but probably can import the static final variable MODE_QUIZ and MODE_LEARN so that the code looks nicer? 😄 same for the rest of the magic numbers

if possible, maybe add descriptions behind each user? like hardworking user etc

possess 😄

probably "number of correct attempts increments"

Fixed!

Oh thanks for catching that haha

gots it

new commit for added abstraction as well as clearer names for the image variables

oh i was assuming that when they gave 1 page to paste optional contributions to user guide this was what they meant but now that i think about it

Solved in #60

Solved in #86

Solved in #93

Solved in #88

Due to the application being targeted at fast typists, it is assumed that users should experience little to no difficulty in typing an extra 5 characters before checking an answer; which is why we chose to implement the check command this way. 😄

Interesting idea, but as we did not consider this issue very relevant to our target audience, it was decided that this would not be a function of our application. Thanks for the suggestion nonetheless!

For our target audience (fast typists), we assumed that the additional adding of command to switch between modes would be inconsequential, compared to the potential confusion caused by being fast directed back to menu mode after finishing a quiz. Thanks for the suggestion though!

Will be solved when implementing showing all answers to quiz flashcards at the end, as asking for answers during a quiz is not in line with the spirit of flashcard assisted learning. Thanks for suggestion though!

Actually if no number parameter is provided, all flashcards will be added to the quiz. We'll add this to the user guide

same as #156

same as #146

same as #123

Solved in #109

same as #156

same as #123

fixed in #168

Tags now allow for whitespaces between words. but any trailing whitespaces will be removed

fixed in #109

fixed in #172

same as #155, fixed in #165

yea i think can

Are these commented out stuff important?

But i think looks ok overall, let's merge it !!!

yup, or can we use taggedList?

yup agree

Ok, we can standardise to use the Option class to represent a option instead of using a string, similar to prefix.

i'll just tag everyone and myself to remind us to use it @edelinetenges @nicoleang09 @Stratostorm @mechastriker3 @clarlzx

that makes sense

test reopening issues

Looks good

this PR is voided

closes #41

It seems more appropriate to change it to StudentBook.

Perhaps you can consider placing a quotation for the command, for i.e. 'Add Student' to enhance readability?

Lines 200 to 202 are the same as lines 226 to 228. Perhaps you can write this in the parameter format section to avoid duplication?

The in-page hyperlink idea sounds good!

We should use the StudentBook::isExistingMatricNumber method and boolean is sufficient. Thanks for pointing this out!

Since date and startTime are supposed to be of type LocalDate and LocalTime respectively, it would be a better idea to just store them as their own type instead of String.

Yea, it is still an optional field.. Earlier on in our UG, we state that items in square bracket are optional so we should stil follow their convection!

Good observation! I just realized that we might not need the >br> for the commands..

I will fix it now!

Good point! It turns that I can use isValidFaculty method instead of coding a new method.

It's being used in the UI side (StudentCard.java) in which the vaccination status label will be set to textUI.

Good point! Seem more appropriate to talk about appointment clashes. Thanks!

Hmmm.. I don't think its needed since we are just letting the user knows that even though they can't edit matric number through the edit command... But our app will still approve if they edit the matric number directly from the JSON file ... So if they tried to file a bug saying that our UG state that user's matriculation number cannot be edit yet it can be edited through the JSON file then we can refer them to this line.

Yup, I meant to say that the UI will still reflect the new matric number if you edit the matric number field directly from the JSON file. Would "VAX@NUS will reflect the new matriculation number if it is edited directly from the JSON file. " be clearer?

Hmm... I understand your concern... But I think the problem stems from the unmodifiable matric number field.

The JSON file allows every field to be edited but the edit command disallow the matric number to be edited..

I'm not really sure how the user will think if we specified that matriculation number cannot be edited in the edit command section... If they read and think that matric number is unmodifiable throughout the app... Then they might think that there is a functionality bug when it comes to the JSON file since it allows the user to edit the matric number....

Would writing it down to inform the users that they can edit the matric number in JSON contradict with our edit command behavior? Technically, edit command and JSON are separate areas...

The expected behavior for your given scenario is that VAX@NUS will start up with an empty student book. There are validation checks in place to check that the matriculation number for the appointment belongs to a valid student record containing the corresponding matric number. If the validation fails, VAX@NUS will start up with an empty student book.

Okay, I shall make changes to it! Thank you 👍

resolve #113

Would be good to include more assertions

I agree with Yien and its hard to validate name since there's no fixed rules to validate it..

I don't think its necessary to validate address too..

I agree with Yien about overseas phone number .. Seems to be quite tricky to validate phone number unless we want to restrict the app to only store a local phone number.

Yes, per our discussion this is a documentation bug.

Do you think we should have prefix for filter and stats so that we can display a more accurate error message? @yienyoong

Sounds like a good idea and I will do it now.

Yes, we should remove the line from the UG.

Making matriculation numbers uneditable seems to be a better option... As a student only has one matriculation number throughout their study in NUS, there is no need for our users to edit their matriculation field. However, if the user add a student with an incorrect matric number that he/she has to delete the particular record before adding a new student record.

Yes, perhaps @fairyinabottle4 might want to update this part in the UG.

Okay, thank you @picasdan9

#190

We can just add 'DOES NOT LIVE ON CAMPUS' to the parameter format section in the UG. This resolve #190 #226 too.

How about we change the value of the vaccination status to be "vaccinated" and "unvaccinated"?

yup!

I don't think we need to validate it...

Can change the system from addressbook to planit?

Should this be start time?

Using {:toc} allows us to see all the headers so is that better?

Is testing a java class necessary?

Alright thanks!

It is in ongoing works.

this is just a personal preference but i think that lines 38, 39 can be swapped so that the email "peterjack@example" can be above "peterjack@examplecom" so that it follows alphabetical ordering!

i think it would be better if it the space at the end of line 28 can be brought to line 29 just before "if" so that it is more consistent

I think you should replace the full stop after "However" to a comma instead

I think you forgot a full stop at the end of this sentence

ohhh okay can i will make the changes

okay!

ok!

ohh i think i pulled this before u merged ur pr... so i dont have the task status class right now.. what shld i do?

oh its okay i got it!

okay!

i see... i will change it asap

noted!

i actually did that before but there was apparently a checkstyle error

noted!

What's the difference haha?

experience is spelled wrongly

Link to github not included

Alright sure

done

I mean completed and uncompleted is self-explanatory. The missing space I will add it next time

alright will fix that thanks

Should we keep the rest other parts of the DG or delete them since it pertains to AB3?

I think we can just leave it in the meantime and remove it progressively in the future.

Some tests are failing, try running tests locally to see whats happening

Yep, I have fixed the error

would be good to test if the list of tasks is sorted after reopening the app

I think it is. However, you will need to use the exit command so that the storage saved the latest updated task list

LGTM, the command execution only updates the currently active tab right?

Erm I am trying to remodel it such that Users can only edit on the home page. The other tabs are more like viewing the task (completed, expired) etc

Same issue as #96

@rjeez

Thanks for finding bugs for us, we really appreciate it a lot.

However, for this bug, this is the intended behaviour.

add n/hello desc/yes add n/bye desc/no

If there is parameter of the same type it will take the last occurrence which is n/bye for Name and desc/no for Description.

Very detailed and well-written! Looks very comprehensive 👍

Good that you have edited this part out!

Documentation for this method looks great!

Maybe you might want to change the sample barcode to one which is not contained in SampleDataUtil.java?

e.g. 1234567890

LGTM 👍

LGTM!

lgtm

Good job adding the methods required for borrowing books to readers! Maybe we might want to consider separating/abstracting the methods related to borrowing/returning books in the SmartLib class to a separate class?

There were some bugs with my local tp file, this pull request is just to check whether my local tp file has been successfully debugged.

Will merge this first, so that the others who are trying to update the developer guide will not have to perform these edits again.

This pull request looks good to be merged into our group's repository!

This pull request looks good to be merged into our team's repository! 👍

This commit looks good to be merged!

it's not a search-by-name, as the findreader functions searches the keywords independently. Read the UG.

For example, "findreader Amy Bob" will list all the readers "Amy", "Bob", and "Amy Bob".

Will take your first suggestion into consideration though.

Thanks for the suggestion, but we do not think this is a bug.

Did we even implement this feature?

This is a valid bug, oops.

This is a valid concern, our team will look into it.

Oops, will fix that.

This is a valid bug, oops. Might look into preventing deletion if reader still holds onto a book.

The definition of the KEYWORD parameter (read: single alphanumeric word) is stated clearly at the beginning of the section. There is even a "Notes" section below the command description (included in your screenshot) that links you to the table of definitions.

Its a GUI bug, you'll need to click on the record card to refresh it. Our team is currently still unsure how to fix that, will try to do something about it.

Thanks for the suggestion, but this isn't really a bug.

Will take your suggestion into consideration.

u wot

Will fix a minimum window size to prevent trolls

???

We believe you forgot to press the "Enter" button. This bug is not replicable.

Too bad. You can only delete the reader and add him/her back with his/her current details at the moment.

We might consider enabling an editreader command in future.

Betsy Crowe and Betsy Crrowe might be sharing a family email, so we don't think this is a problem at the moment.

We might look into this issue in future though, thanks for the reco.

Oops.

There may be different books with the same name, but with different genre(s).

Cloud Atlas , David Mitchell

The Cloud Atlas , Liam Callanan.

You did not capitalize your A in "and" and T in "the".

Scroll down.

???

Repeated submission of bug by the same author

You can Ctrl+C -> Ctrl+V from the User Guide.

The reader might be some alien from another galaxy, which has a phone number of a trillion digits.

However, you can simply close the help window with a single click.

Wot

Thanks for your suggestion, but our team prefers to have a single numerical value instead.

I like how you explained the implementation of Schedule.

Looks good.

Need to resolve merge conflict.

Name change to all upper case when parsing.
Change all prefix to ":" instead of "/", and update UG and all error messages to reflect as such.
Change regex of name to support "-,/", and update error message to reflect as such.
Change regex of address to disallow colons, and update error message as such.

Add a line in UG to justify not restricting meeting intervals.

Rejected - implementation is to standardize prefixes

Rejected - You can have multiple plans of the same name.

"within 14 days" includes today + 13 days

Our implementation is for today's meetings, not meetings within the next 24 hours.

Rejected. We give user flexibility, in case multiple of the same event occurs in the client's life. E.g. client gave birth twice, so 2 notes say "client had a new child"

UG - specify that "@" not allowed in meeting description

Specify in the UG that clients cannot have the same name, it is up to the user to ensure that there is something in the name to differentiate clients with the same name (such as parenthesis). Frame this as a benefit to the user ("so that the user will not be confused").

Do these ever get used? Neither showm or findm uses them.

Ok I guess this is fine since its java.util.*

We deal with the spacing later

lgtm

Done by maurice.

Lgtm

Go to 1.3

Completed

Added

Move to 1.3

I'll pull this in since there are no conflicts.

LGTM

Actually the tests fail

Nice fixing of test

Should look good to merge.

Oh no the tests fail.

I fixed the tests.

This is done as part of the tP progress.

lgtm

Ok lets just fix the UG later

UG is wrong, it should be ph/ not p/

fixed

Wrong prefix

ok fixed

not really a bug though.

LGTM

yup can create one for the appointment, but the output message would be the same, which is "The patient index provided is invalid"

Just created one. Thanks

agree, thanks for pointing out

updated. Thnanks

Hi this method is different from Method Contains.

Method Contains returns return internalList.stream().anylMatch(toCheck::equals);

Method editContains returns ireturn internalList.stream().allMatch(toCheck::equals);

i think they are different because the editContains is different from Contains

Thank you for pointing out!

Can i keep it for now? because it separates from the functions used by add-appt.

In the future if there will be some changes, i can change it easily without breaking the code for add-appt.

In the finalised version, if they are the same, i will rename them.

It has the flow of : hasEditConflictingAppointment -> hasEditAppointment -> editContains

Otherwise the flow would be: hasConflictingAppointment -> hasAppointment -> editContains.

OK. Thanks for pointing out.

just changed, yes you are right. And i didnt create field for appointment index

you are right. Removed duplicate methods

you are right. Thanks for pointing out. I just removed duplicate methods

you are right. I removed it

thanks for pointing out. changes are completed. Will push again soon

Hi, i just added in the index for appointments

yes you are right. Changes were made. Thank you

you are right.

i get what you mean. i try to change

yup, have made the changes and pushed again. Thank u

oh i see, i saw wrongly

Should be fine I guess.

This should be fine but what model validation logic does Customer have?

Shouldn't be necessary unless this is for future cases and consistency across the models.

Okay will specify that it is getter for the fields. But this is still necessary because we want to keep it hidden from the rest of the classes.

But note that these changes are essential for us to have the objects be testable. Or else, you can't instantiate a ID with some particular fields without changing the underlying counter. Previously, unlike CustomerId; OrderId and CheeseId are instantiated with native constructor, with no way of not incrementing the underlying counter.

By the way, the comment was carried over from seedu.

Yeap this is updated.

Yeap this is updated in the latest push.

Hmm this one we do allow to edit tags, so this would be okay.

2F + Mockup - Wei Xue
2F + DG - Lauren
2F + UG - Li Quan
2F + README - Aaron
3F - Daniel

@daniellau88 it's your call, the workflow build fails because it tries to access the secrets from the master repository. Other than the access issues, it should be working.

Yeap seems like I have included the wrong token. I have updated the secret with the chat ID of our Telegram group.

Actually do you want to squash some of your commits, before merging. But other than that, everything seems fine.

Now the issue is the workflow works for push events, but not from the pr from forked, because GitHub doesn't expose secrets to forked-triggered workflows. Seems like we have to close this one down, as our current workflow, we are not pushing/pr-ing from master repository's branches, the notifier doesn't work in this case.

Since this will not work for our current workflow, unless using plain text tokens, I will close this down. Maybe use it for v1.3.

I will recommend squashing your commits before merging if possible.

There is one class of ModelStub with no useful methods, and the rest of variations are extending from it and overiding methods important for testing. We could make it abstract though. What else do you think we can do. The idea is we have two kind of test suites: 1 with using the actual ModelManager and 1 using just the stubs.

Fixed the above mentioned issues but also, the Json parsing to model for cheese is also not fixed with parsing null fields, and thus have some initialization issues. Have fixed all.

Architecture Diagram

Architecture Sequence Diagram

EditCommand Sequence Diagram

For the EditCommandSequenceDiagram, do include the command string

Yeap done!

I think need to abstract the method here. You can move the null checks to the assignment class and assignment command parser to comply with the other model objects/methods. Since the Model and model manager are mostly facades.

This method i think can be abstracted too. Can call a method in person which calls a method in the session list.

Should we allow multiple student assignments at the same time? Like in tags

Details:

after clear command:
- sessions not cleared
- other session-related functions not showing on the UI (session JSON is getting updated)

Cannot recreate bug

phone, email, address

change image

is this a typo?

mechanism*

should it be feature instead of mechanism?

Yup sorry slipped my mind our project name changed.

yup sorry for the typo!

Yup! i will change it.

Need to fix checkstyle error

lgtm

If we were to set Person as immutable, setDates, setMeetings and setPicture might need to shift to a different class instead. Maybe a PersonFactory?

Either this or state in comments there are mutable fields present in Person.

Add javadocs comment here.

Just make sure to change the command word in the program beforehand.

Sounds good. Added the glossary back in.

Fixed

Test cases seems to make it hard for you to pass in a LocalDate as an argument. I changed the validation to use #41 dateUtil. Should we still make it as a LocalDate field?

The rest of the other 'with' methods doesn't do their parsing in this testutil though. I think what I'm going to do is,

Allow birthday to accept a string and parse the string. This is primarily for testing.
Create an overloaded constructor which directly accepts a LocalDate. This is what the app will be using.

Tried using stream but parseIndex throws an exception. Apparently unhandled exception does poorly with streams unless I explicitly throw it inside the lambda.

add-debt and subtract-debt both have almost the exact same implementation in terms of both commands and parsers. Implementing them separately seems inefficient. Implementing them via the ChangeDebtParser and ChangeDebtCommand and passing a boolean increases code reusability.

I feel that adding in an extra boolean input worth it comparing to the additional bloat that will be added in creating more separate commands and parsers.

Command only accepts positive value, hence the need for add-debt and subtract-debt.

The debt class is to store debt within a Person. We can have negative debt to indicate the person owing money to the user instead.

The ParserUtil.parseDebt is used to parse debt passed into the ChangeDebtCommand, while Debt.isValidDebt is used to validate Debt. I will change parseDebt to parsePositiveDebt for clarity.

The reason for implementing this way is that the user would normally change the debt amount indirectly through adding/subtracting unlike the other fields that would be edited directly using edit.

Hence the Parser requires a different method to parse positive debt amount rather than the default valid debt.

Removing the conditional would introduce even more code by duplicating the behaviour here again in another command.

Will implement toUi() in Debt.

See above.

Sounds like a good idea here.

lgtm! We probably need a new way to let the user know which group is selected (is possible)!

We don't have to. The list cell can still be selected i.e the green vertical bar will still pop out when you type in the command like previously implemented.

Whats all this stuff? Can just delete?

Somemore leftover comments here

I think its probably fine

Yep, thats a typo

This error message shouldn't be displayed to the users, its for the parser's to determine which error message to show.

resolved by PR #22

Add instructions to the UserGuide to teach the user how you can export your contact list to another device running Helibook by copying the data file.

Decided that this issue is no longer in line with project direction

This was originally by design, but looking at it again, it may be better to remain in the found list. Will investigate and see if its implementable.

This is intended behavior, for example, to allow for situations where the contact number is the same due to working in the same office. Eg. 2 different tuition teachers from the same tuition center saved with the tuition center's number.

This is intended behavior.

Duplicate issue with #195

Duplicate bug with #196

Duplicate issue with #212

Duplicate issue with #46

Added commit to fix tag ordering. Fixes #191

Detailed documentation

Great job!

Good clarification

Now we have to integrate Type into matching as well.

Detailed explanation. Good job!

Ordering is sorted in ascending order of the last used date by design.

Selecting a piece of clothing will update its last used date to the current date, which is then sorted to the bottom.

The rationale for this is so that users can see their least used clothes when deciding what to wear so as to maximize the usage of their clothes.

Issue fixed.

Issue solved

UG clearly states that matching of multiple input garments is a feature that is planned to be implemented and as such is not yet implemented in the version tested in the PE-D.

Issue resolved

Issue resolved.

I believe that Model actually has a hasEvent(int index) method that can be used here instead!

Is there a need to change the boolean form here?

Very clear documentation!

thanks for pointing that out!

Ah thats a good idea!

thanks!

yes marcus pointed it out too. I fixed it alr!

hmm the null is okay because we check again in EditAssignmentCommand.java

i can do the event skeleton, add and edit

We can limit the number of characters a user can input

Update UG

This was not encountered during testing

Ignore

@jellymias Can you include in the intro that RemindMe reaps both benefits, something along that line

Of course sir!

@markuz5116 I have updated the intro. Please close the issue when you're done!

I think can just leave it in the old form as ParserUtil is static but looks fine

I think wildcard import is not allowed

Should be a different prefix to category.

I changed the checkstyle to allow wildcard imports since we import considerably from one package. Wildcard imports should be ok if you import more than 3 functions/constants from a package

LGTM

Nice job. Will merge when everyone has updated UG and DG

It seems as if the tester has not reviewed anything so there is no stats to display.

Perhaps this 'Implementation' section can be shifted up so that it's in a new section rather than under 'Appendix: Requirements'?

There's the option to just use elist without the parameters also right? Perhaps can update the message here

Thanks! In this case you can also delete the Label startTime and endTime and perhaps we can change "Date" to "Due date" to be clearer?

Sure sounds good

Is it ok to stick with or time? Cause i wanna try to indicate that it's either date or time that is not a valid range. Could be that start time is after end time or start date is after end date, or is there a better phrasing?

Ok i changed it a little, see if it's less weird like that!

Checks not going through

Can be written in the DG as a future feature

Great idea to add a glossary section!

Good change. FoodDiary entry is clearer to understand.

UG updated.

I agree that the documentation is not clear on how the price range search works. Will change the explanation for find and findall commands in the UG to be more clearer.

Techno Edge consists of 2 separate words while Clementi is a single word. Therefore, Techno is not a partial keyword. Nevertheless, I will make it clearer in the UG that partial keywords cannot be searched.

Not a bug, as it is clearly stated in the UG how each feature expects price to be written. For commands such as add, price is written with a 'p/' as it needs to be clearly specified that it is a price to correctly create an entry. For find/findall commands, prefixes such as 'n/' , 'p/' are not used to make the commands easier and more intuitive to type out (eg: find $6).

Will fix the grammatical error.

The word 'generally' was used to differentiate it from the findall command to make it less confusing. Nevertheless, i will modify the UG to make the title clearer.

Will fix this bug.

Perhaps the command format could be simplified to massdelete s/INDEX e/INDEX instead of having to type out the full words for start and end?

I feel that the exclamation marks are unnecessary and do not fit the style of the app responses. Is there a reason for them?

This is intended interaction as stated in the UG.

The separator is decided by the user and any perceived confusion arising from their choice of separator can be fixed by choosing a different separator.

Same as #118.

Special characters are not accepted as inputs, as it would negatively impact the rest of the fields as well. However, I agree that the UG should mention this feature is meant for easy copying into recipient fields (such as the To field in emails), in which case special characters would not be very useful as separators.

Target user is a CS undergraduate/graduate

Looks good.

Tks for the refactoring.

True haha. Will make the changes.

Got it

Wah tks you are sharp 😃))

Removed

Fixed

Will update EditAppointmentCommand to accommodate both start and end time.

Made the appropriate changes.

Allowed for modification of timeFrom and TimeTo field in EditAppointment

Looks good.

Looks good!

LGTM

Added delete_budget utility
Fixed formatting errors
Updated User guide for budget commands

Added view_budget command
Updated user guide

LGTM

Yup forgot to add new methods to one of the test.

LGTM. But got some checkstyle issues.

Lgtm

Ensure there is a tutor with the name in the appointment in question.

Wah siccck tks so much!

will update to delete customer base on name

Thanks for styling the diet plans nicely! +1.

Thanks for adding the glossary of terms!

PR contributes to #18

This PR contributes to #16.

Contributes to #18 .

#18

Closing, all updated.

Handled by the addition of the progress report.

Thanks for the feedback. The take here is that the speed improvement is not based on the list of food and their associated macronutrients, but with the recording of food on a longer-term scale with the use of CLI-based inputs as opposed to a GUI one (it's possible to copy-paste values and inputs for multiple days, as opposed to doing meal-by-meal interacting using GUI).

Thank you for the bug report.

This is because various other diet plans were added recently. We'll update the UG to match these changes.

Thank you for the bug report.

This is because of the need to reset the sample data in the application before you can set your own data. We'll update this to make it more clear in the User Guide, as well as in the application.

Thank you for the bug report.

This is because of the need to reset the sample data in the application before you can set your own data. We'll update this to make it more clear in the User Guide, as well as in the application.

Thank you for the bug report.

Indeed, we want users to be able to be the "own masters of their destiny" (i.e. be able to set their own weight goals). We'll update the User Guide to fix the grammatical error here.

Thanks for the bug report.

The issue is actually in the feature listing, as opposed to in the quick start as mentioned. In addition, this is also because you will need to clear the sample data on first launch before you are able to input your own data. We'll make this clearer in the UG and the application.

Thanks for the bug report.

We'll include this in the list of commands implemented in the UG.

Perhaps the magic numbers can be replaced with named constants to make the formula easier to understand 😃

I LOVE THE LOGO!! GOOD JOB

Good point! Will update this.

Updated command name.

You are right! Thanks for pointing that out!

Looks good to merge!

Looks good to merge.

LGTM

#90

LGTM!

Hello,

We've made this clearer by displaying the Food name together with the duplicate count should there be an existing duplicate food name.

Actually, the user guide already mentions that for duplicate food names for a given date, they will be appended with a duplicate count - much like how MacOS and Microsoft Windows does it for duplicate file names. So this is an intended behaviour.

Using a count column for each food name will not work, as different food intake may hold different nutrient values.

Please refer here: https://github.com/AY2021S2-CS2103T-T12-2/tp/blob/master/docs/UserGuide.md#35-input-food-intake

Confirmed to be fixed.

Thanks for the report! Fixed in #190

Maybe include my github link for consistency?

Do you forget to add the link? or is this intentional? Also maybe list as examples

I copy this design from the addressbook code,

changed

Thanks Prof~

Decided to push manually due to low number of lines

This is allowed, we will correct the UG.

The one in address/logic/commands is an {abstract} class and exists in a different package from this Command.java.

I think since they are clearly differentiable by file path, it shouldn't be an issue. Because alias/Command.java is named as such logically.

"Paths (or URLs) are nice because they are nested identifiers."

Reference: https://softwareengineering.stackexchange.com/questions/250481/is-it-a-bad-practice-to-give-two-very-different-files-with-the-same-general-purp

Good catch

Made changes to the statement

Fixed and removed.

This test was originally to ensure the commands are sorted. Under the assumption the "add" command will always be present, regardless, the first command at index 0 should always start with a.

Perhaps a suggestion is to test every first letter of each command and see if they are alphabetical?

Modified test case following 1.

Decided to compare element by element.

Thank you for the suggestion.

I get your drift.

It was my mistake to include the Collections.sort() again right after calling the method. It is already called in getAutocompleteCommand().

I have implemented your suggestion 2 as per your previous comment. I am using the comparator method so the hard-coding of commands is minimized.

Thank you for the spot.

I've added a test case to handle Empty spaces / white spaces.

Documentation for the method getAutocompleteCommands has been added.

Fixed! Thanks

Fixed!

I believe it was accidentally added

Yes it is intentional. Thanks for pointing that out.

Added a note in c5811ce

As there are quite a few moving parts for the toggling of flags (e.g Command Box, logic, currentList, lastFlag), I'll still need some time to think about how to un-nest this portion.

Small reduction in code in dc2e88d

I chose not to convert it to that because it seemed quite verbose to me. I will change it. Thanks for pointing that out

That makes sense. Thanks for suggestion.

alright this is a cleaner solution thanks!

Removed command and it works.

Alright I will need time to process this. I will set a "TODO" for now for v1.4.

Very good point. Thank you.

LGTM

@yaowei-soc fixed PR naming convention to provide more context and information.

Thanks for the reference.

Bug found, commands do not show up on start-up sometimes.

Nice. Thanks for enabling assertions.

Works for me.

LGTM.

Closed in #124

AddressBook has been changed to HeyMatez

Just need to change these names to HeyMatez

This is for the editTask command to be added later so that the user can specify which attribute of the task to edit

I thought it was simpler to follow what was already implemented so that it is easier to check whether the description is valid too

HI! I think it may just be an error in the formatting and the quotation marks because i could add a Task without any data and header. Sorry for not clarifying further!

Implemented and merged

Merge add deadline

Perhaps this should be changed to one that fits the ScheduleCommand class

Not a valid bug

There is an existing option to only add the student's name and mobile number.

Not a valid bug

Command format is only considered valid when the index is a positive integer and lesser than 2147483647 (Integer.MAX_VALUE)
Index is only valid if a student with the specified index exists

Postpone feature

Feature can be implemented in v1.5

Reject suggestion

We would like to give our users more flexibility in specifying the time of their lessons.

Looks good to me. SLAP is adhered to and method is not too long or overly nested

is RemindedParser a typo?

I can do general event done and delete

GE attributes, String description, LocalDateTime

general event description prefix - g/

general event LDT prefix - on/

looks good. Follows the same format as the other edit commands and parsers

The GUI similar to the picture below

lgtm. just want to clarify the JSONArray jsonTags passed as a parameter here is a json array of all of the 'tagged' field values in our database flashcards.json?

I think so too. However only the modelmanager is passed into execute and since the mode resides in modelmanager I cant find a way to abstract it out

good idea, implemented

added to gitignore in new PR

thanks for spotting. removed

changed to 1 million maximum

Added greetings message for the app.

Figured out logic behind GUI display

Added greetings message for the app.

Perhaps create a PR for it, as it will probably be something useful for the application? 😃

Sure yucheng, created the PR

@xinweit after I merged my previous PR into the code base there seems to be a conflict. The conflict is in MainWindow.java and it seems its relatively simple to resolve from your side. Its a bit troublesome from my side as I would need to make changes of your PR locally, so can help?

You can resolve it by trying to pull the latest master branch to your GUI-display branch. Thx!! 😃

Sure bro ill do that, no prob

updated

right now to change the mode of display we are hiding and showing the flashcard panel using setVisibility(boolean) method of javaFX. but I think this mode class will come into handy next time when we want to say parse different commands based on the current type of mode (quiz or learn), ie. commands specific to quiz or learn mode

nice. lgtm

Should only be able to start when user is in quiz mode I think. Working on it.

Err so this PR is a super set of your PR 74 and 76? Sorry I am a bit confused

Yeah it includes those as well.

Will be closing this pull request due to a problem in pushing to this quiz-duration branch.

Feature, not a bug

Hi, that's a great query. However we have decided to leave this feature for future implementations and as of the current version, by managing flashcards we mean adding tags and removing tags from flashcards. We will clarify this further in the user guide. Thanks!

Maybe can change the parseTags here to a parseCategories? 🤔

Ok thanks!

Maybe i will hand over this part to you haha.

I haven't inspect on that deeper so I am not quite sure 🤔

LGTM

It is meant to be in this way. delete_task/event + an index out of bound and delete_task/event + an index that is not a positive integer are treated as two different types of invalid inputs. The former one is indicating that this index might be correct given sufficient tasks/events in the list, while the latter one is indicating that the index itself is meaningless.

The deadline entered is 2021-03-04, March 4th, not April 3rd, and the app does allow to add a task with today as a deadline

closed along with #282

This link doesn't work, there is also a typo in "commands"

I think it should be address/logic/commands/DoneCommand.java?

Maybe they can serve as examples of low priority tasks?

I wanted to use the same autogenerated TOC as DG

The data folder appears for me.

Duplicate of #77

Nice catch!! 👍

LGTM!

im so sorry i clicked the wrong link!! thank you!!

java version should be less than or equal to 11

Done with the merging of ui-for-school-tags

place angle bracket in Keywords

removed first additional list

add this in ug

User Guide has 'Command Summary' and each command has 'Format" shown.

Add range to price and show before and after for edit and addon to show the difference

"only add on extra things" as Tester has said, thus the command "Add On" is suffice, but will be more explicit

edit Delete UG to remove being able to delete by name

Two shops can be in the same place, eg in a kopitiam, cannot limit user's usage of the application.

allowed same name but different address

have specified as such

removed extra

delete should only allow index

will include screenshots

agreed, rectified

rectified

removed price range.

bug was written due to incorrect inclusion of delete name.

closed issues with pull request that could not be linked #125, #123, #122, #121

would this cause a problem where name will be searched when user searched for a student's school

User can choose not to use mouse by simply using alt-tab and alt-f4 to close popup and switch between tabs

execute method looks good but might want to do abit more abstractions to make the method LOC to be less than 30!

Yeah this line I feel you should change to "No appointment found for this student". So it tells the user that the student exists, but no appointment is found for that student

Amended

I amended and placed quotations around Add. However I did not place quotations around Student as well because I do not want to give the false impression that that is the correct input format for the Add command.

Amended

Amended. I also changed the SchoolResidence to be "0..1" to enforce that there can only be 1 SchoolResidence if present.

Amended

Noted, I'm now using an assertion for defensive purposes instead of throwing an exception

Or do you consider this as defensive programming?

Yes, this is defensive.

Does it mean if the Model happens to have an appointment that corresponds to no student, this appointment cannot be edited

Yes

Thank you and noted, I have abstracted this in Model in my latest commit.

Noted on both, I'll make the changes

@picasdan9 I have pushed the changes, I also added the 'x' under AddCommandParser to indicate that it is garbage collected, as you suggested earlier

Hmmm I don't think it's a documentation bug. I think I need to make it clearer that if the School Residence field is left blank, it will default to DOES_NOT_LIVE_ON_CAMPUS. Then maybe in the filter/stats command we can also specify that DOES_NOT_LIVE_ON_CAMPUS is a valid input.

But @SiTingST, I believe that filter DOES_NOT_LIVE_ON_CAMPUS should not return nothing?

@picasdan9 @SiTingST I like the idea of using boolean values, since it is unambiguous and yet keep the command format intact.

In fact I think using 0 and 1 would be the best. This is to prevent ambiguity regarding the capitalization of the boolean values e.g. true vs True. We are already using enum for this, so it should be quite similar

Yup agreed. No such restrictions as discussed.

More of a documentation flaw to me. Let's explain why it is not restricted to 8 digits

No need to validate address

Agreed, option 1 is the best

Strange, I'm not able to replicate this. I think it's because of that one big problem that led to all these smaller issues

Add a tip in the UG for add command: If r/ is blank, it will default to DOES NOT LIVE ON CAMPUS

Not a bug.

for the MESSAGE_NON_EXISTENT_APPOINTMENT, can we mention explicitly that there is no appointment found? So I would word it as " "Found student with matriculation number %s \n" + "However, no appointment was found in the records." I think this would reduce ambiguity greatly.

Other than that, looks great!

Introduced amendment to disable editing the matric number of an existing student to prevent confusion. The user guide has also been updated to explicitly mention the different inputs for the two commands

Updated UG in the add command that the default value for SCHOOL_RESIDENCE is DOES NOT LIVE ON CAMPUS

Contact instead of persons

Used by getTypicalTeachingAssistant method

Merge this

Is this printing intentional? If it is, should use logging instead 😃

Looks good to merge

Reopen to link PR

Looks good to merge to fixes #9

Reopen to remove traces of AB-3

fixes #9 as well

Fixed by #28

Fixed by #23

Closing this issue because is fixed with #53

Closing this issue because is fixed with #48

closed for potential feature

Closing this due to duplicated issue #157

Closing this as it is resolved with #150

Unable to replicate this issue with any of device. Closed for invalid bug.

Closing this issue as it was fix in #218

Closing this issue as it is fixed with #218

Closing this issue as it is a suggestion, not a bug

Closing this issue as it is a suggestion not a bug.

Closing this as it is a duplicated post #200 from the same user.

Closing this issue as it is a duplicated post #181

Closing this issue because it is an duplicated post #203

Closing this issue because it is a duplicated post #181

Closing this issue because it is a duplicated post #179

I think Jay meant 't' tag is not shown in UG as one of the parameter

Closing this issue because it is a duplicated post #181

Closing this issue as it is a duplicated post #173

Marked as bug instead as customer delete failed is not caught

Closing this issue as it is a duplicated post #168

Closing this issue as it is a duplicated post #173

Closing this as it is fixed in #224

Closing this as it was fixed in #224

Closing this issue as it was fixed on #150

Closing this as it is a similar issue with #189

Validation of negative phone number should be included as well from #215

Reopen due to accidentally closing the issue

Marked as invalid as it is merely suggestion

Closing this issue as it is an duplicated post #211

Closing this issue as it is a duplicated post of both #198 and #189

Should direct user to the help page instead

Closing this issue as it is an duplicated post #211

This is an intended behaviour, will explain this in the User Guide

Variable naming convention

LGTM!

LGTM

Not a real bug, substring search not intended. Closing for now.

Should the link be from our repo instead?

Thanks for the catch, will update accordingly

Understood. I updated the prefix for alias to be "cmd/" for command and "al/" for the alias name

I feel the command should be rephrased to foodintakeupdate for consistency with the rest

LGTM with more detailed descriptions.

lgtm.

looks good!

The issue is now fixed by allowing the parser to allow integer characters.

The issue is now fixed by allowing the parser to take in number and space inputs.

The reason for this error could be because you did not change any nutrients values, which is an intended behavior of the update function. We will update the user guide to be more clear on this and the error message. As what @sjq-sohjunqi mentioned, we have also set a 2dp limit for nutrient values to prevent such use case of many decimal points.

@eksinyue I think you can use the logger instance to print out your debug messages.

@lyueyang Hmm, I meant like crop away the black borders around the screenshot haha, just like your other screenshots in the UG

@lyueyang

Oh, I mean it's just a suggestion. Alternatives like:

Category = c/

Label = l/

Becos tag/ is quite out of place

@jxrrelo Got it, let me take a look!

@eksinyue Is this the same as #115?

@eksinyue Hmm, the exceptions can be seen in the console logs ahaha

@eksinyue I tried to apply the changes on my side and I'm still getting those exceptions 😮

@eksinyue

Hmm I think the root of the issue stems from your addFinancialRecord in BudgetBabyModelManager. The condition always return false.

Maybe you can try this and see if the issue still persist?

Hi, btw I think I just discovered a possible bug. When the category statistics window is opened, and I typed exit in the command box to exit, the app closes but the graph window is still open. This is not consistent with the behavior of the help window. i.e. the help window will close automatically if the app exits.

@tlylt thank you, submitted #202 😄

@eksinyue @natosy I think we just need to set the upper bound of getPastMonthStatistics() to be the current month.

I believe getPastMonths() will be called, which eventually limits the number of "past months" to 6.

Hmm I guess I can implement it via hotkeys in the UI.

@natosy you can decide if you want to implement them as CLI commands

Another one

Just to have a user story to close after we finish adding stuff for v1.2

I'll incorporate your code into mine when I do the other fields since there seem to be many conflicts

I think this is not an issue as there can be family members who register with the same phone number or email.

I think this was an oversight. It is in the user guide under Notes about command format in the Features sub-section.

Just to confirm, is System.out.println() supposed to be there?

Done, added a test case for invalid args

Taskify.java has an equals() method that checks if the list of tasks is equal to the other Taskify object's tasks right?

Ah nevermind, I compared the ReadOnlyTaskify instead of comparing the ReadOnlyTaskify#getTaskList(), I pushed a new commit

LGTM *

PR has been merged already.

Decided not to remove any fields in Person.

If add command does not specify date, default the date to 'today'

Show all tasks with one specified deadline (in 2nd column)

Show Tasks based on State

Example: 'delete completed' will delete all completed Tasks

Did you mean to link issue #81 ?

I believe this is related to the bug of switching tabs via clicking, then inputting commands such as view tomorrow

~~Just need to edit UG saying that if a command does not expect parameters, it will just execute the first command.

eg:

list exit will call list

exit list will call exit~~

Edit: calling list in another tab other than Home tab should prompt the user to go to the Home tab first, before executing list.

(Also good to note down in UG that commands that do not expect parameters will just execute the command regardless of what comes after the command)

This section of the UG resolves this.

This PR resolves issue #120

PR #168 resolves this

Indentation for wrapped lines should be 8 spaces according to CS2103T's coding standard. Not a major issue.

Could you use the [] brackets instead of the >> brackets as per the format above

Edited

I think for this I didn't use the asObservableList method

Removed

Edited

Edited.

Ok, I'll just leave it here and wait for their merge.

Actually I checked this part against the old AB3 legacy code, it was written in this way as well so I think its fine?

Same comment as the one below.

Ok, I'll just leave a line break since most of the code has one.

Reverted.

Reverted, but I found it slightly weird but I'm ok with this, no big problem.

Reverted.

Edited.

Oops, did not know that. Reverted!

Edited.

Fixed.

Was a work in progress, removed for now.

Done.

As of now, I couldn't find. Will try to implement this in the next PR if possible.

No longer relevant.

Refactor UniqueEntityList to remove unnecessary methods that use Entity parameters.

Closes #236.

Minimum requirement: ready for Saturday dry run.

Need to modify documentation.

UI issue, need to differentiate ID from list number.

UG Issue.

Added Entity icon and Entity ID static field

Done.

Typo on this line

Done

LGTM. Nice UML diagram ahaha XD

Will finish it next time LOL

Fixed

Incorrect usage of command(will update UG to make it clearer)

Fixed in latest PR

Unable to be reproduced, seems to be working!

Fixed in latest PR

Fixed

Fixed in PR

Implemented

Fixed in PR

'clear' command now displays a message instead of the old patient's info

Fixed, it now displays the proper error message

Fixed in a PR

Fixed, the UI now displays the year as well

Fixed in a pr

Incorrect usage of command!

Fixed, now docbob prints an error message instead!

vrec is now updated to display the correct error message

Fixed, the viewbox is now updated when a medical record is added

Fixed, the app now displays a custom error message to let the user know that the patient has no medical records to be viewed

Fixed, The viewbox now correctly displays the new patient

The UG is now updated

Fixed, listappt now works

Fixed, vrec works as intended now, and the viewbox updates as soon as the command is executed

Fixed, editing details of a patient now does not remove appointments and medical records

Error message is now updated to inform user of proper date formatting when invalid input is entered.

Both the BudgetDisplay() and updateObservableList() methods appear to have a number of lines of repeated code which violates the DRY principle. You could perhaps refactor your code to patch this up 😃

implement find-fr command

Thank you for your input! This is the intended function of the find command. Should the user wish to apply multiple filters, he/she can do it in a single find-fr command by adding more parameters.

Thank you for input! This has been fixed

Thank you for your input! This has been fixed.

Should it be showEvent( instead?

Would it be better if the regular expression was defined as a final variable instead?

I see! Thanks for the suggestion!

There are issues when calling progress while no active diet plan is selected as well as printing the total adherence to plan

Remove numbering from plan_recommend/use actual ID

Revise parsing of integers

Set upper limit for macros

Immediately show food list after food_add

Set with 2 dp limit for macros

Document this in UG - intended behaviour as users can consume same food during a day

Document in UG

This is an intended behavior as we allow users to input food intakes for the future for forecasting purposes.

This is an intended behavior. This is a duplicate issue with #166 . We will document this in UG. Thank you!

This is a duplicate issue with #155 . We will correct this. Thank you.

Any invalid date after 28 Feb will be casted into 28 Feb. We understand this may cause confusion and we will fix this accordingly.

Thank you, we will remove this.

We are unable to reproduce this error. Can you provide us with more information? Thank you.

We will update the UG. Thank you.

We will limit the input for food attributes to 2 decimal places. Thank you.

This is an intended behavior as food names are not supposed to be capitalized by convention.

Thank you. We will correct this and make the error message more user-friendly. We will also allow for numbers within food names.

Thank you! We will correct this issue and make the error message more informative.

Thank you! We will update the UG accordingly.

This is an intended behavior as the duplicated food intakes have appended with an identifier and should be updated with said identifier.

We will add an explicit message after adding duplicate foods to indicate that an identifier has been appended.

This is a duplicate issue of #155. We will correct this. Thank you.

This is an intended feature. Please use the scroll bars to view the output. Thank you!

We will correct this to allow for numbers to be added as part of food names. Thank you!

This is a duplicate issue of #155. We will correct this. Thank you!

This can be something to improve on for future iterations. Thank you for the suggestion.

Just a thought, is it a good idea to return past month's statistics as a String? Maybe it would be a better idea to return as a List or HashMap? That way, it will be easier to format and display on the Ui side.

Good catch. Thanks!!

Thanks for pointing it out. I forgot to remove it before pushing.

Is this similar to issue #74 ?

@eksinyue I don't think it will fully resolve #73. If I'm not wrong, after adding/deleting a financial record, the budget will still retain at its original displayed value. But apart from that, I think LGTM!

oh okay!! Sorry I misunderstood issue #73. I will merge this PR first without closing the issue.

@deyixtan I followed the instructions and did not get the IndexOutOfBoundsException.

Here is a screenshot of the app after the last delete-fr 2 command

@yuheem Maybe we can consider setting an upper limit to the budget value, and specify it in the User Guide.

Same bug as #189

@natosy Maybe we should specify the months to be included to be current month and 4 months before current months. Currently, we are displaying all months in the MonthList which may not be ideal.

@yuheem I think changing the budget of previous months is not an expected behaviour. However, we can update the UG to make it clearer.

Repeated issue.

Fixed.

@yuheem I have restricted the FR_AMOUNT input by user to be a positive number less than 1,000,000.

Maybe we can add the same restriction for budget amount as well.

Repeated issue.

The issue will be resolved when all UG screenshots are updated using the latest UI design.

Hi @gycc7253 can we ask for more details on how to reproduce this issue? If I am not wrong, the exception is not thrown every time a financial record is edited. Do you happen to remember what were the exact steps you took for this error to happen? 😅 Thank you!!

Probably need to change this class name eventually to accommodate searching by tag

@totoyoyo

Rectified

LGTM

Thanks for informing us of the above.

We have updated our UG to reflect that the actual prefix should be ph/ instead of p/

The reason you see the error above is because there is no prefix ph/ in your command. This causes the application to read "John Doe p/98765432" as the name of the contact. This is not permissible as our name only allows alphanumeric characters and spaces, and not '/'.

As a busy CS student, I want to know which deadlines are coming up, so I can focus on them first.
As a CS student who has weekly quizzes, I can be alerted when the deadline of the quiz is coming up, so that I don't miss any quiz.
As a CS student, I can check my module deadlines and information at the same location, so that I don't have to navigate between multiple tabs.
As a CS student, I can set notes for the tasks, to record information about the task.
As a CS student, I can break a task down into several smaller tasks to better organize my tasks
As a CS student, I can view my schedule in calendar format to better plan my time.
As a first-time user, I can view a help message explaining the features so that I can orientate myself with the app
As a CS student, I can delete tasks that I no longer need to track.

done with my commands

done w my portion

The Ubuntu and Macos CI's seem to be failing due to test cases, so for now we can ignore these.

Not too sure why the Windows CI is failing, could attempt to address test cases first.

Hey, you currently have some merge conflicts in your PR, could you update your local master branch and resolve them.

Thanks!

Can let me know if you need help with this.

Done with User Stories

Need to update the existing bullet points in README.md to include a short summary of our product.

INCOMPLETE:

Needs the current semester and master plan functionality.

@Yihe-Harry Could you close this issue if grades can now be added.

Feel free to link your relevant PR that solves this issue.

The history command does this, dependent on modules being able to be added with a grade.

Now able to work via history command.

Incomplete PR, just leaving it open.

Pls close once everyone has updated their portions of DG.

Done

fix towards the end.

LGTM

Attach to issue

Closed.

Still need to do integration tests of meetings with

-StorageManager

-LogicManager

Tests have not been written, will leave to after v1.3 due to time constraints.

Possibly text may not be able to display in timetable if meetings are too short.

Additionally now the following command works

setTimetable startDate (sets timetable to start at startDate)

setTimetable default to the standard date.

for some reason Mac workflow is queued and not running, could be GitHub issue

I'll just commit first for the release

This is due to LocalDate being "smart".

@totoyoyo can look at this

des should be desc/ but it throws a date time invalid error instead

@totoyoyo flag it in UG. If they do not put the prefix incorrectly the date will be parsed wrongly

@hengyiqun please fix this ASAP thanks

LocalDate Autocorrect. Will add a note in the user guide about it.

@totoyoyo please correct the UG ASAP.

Should be made clearer in the UG.

@totoyoyo fix this thanks

@hengyiqun please look into this for the docs

@totoyoyo please correct this. Should be minor. Just add to the glossary. I have already made a glossary section in the merge request I am about to pull in.

@hengyiqun @totoyoyo please look into this. Thanks

small issue.

Same, add this to glossary @totoyoyo

do we need to change the name or stick to addressBook? @totoyoyo . I think this should be included in the glossary to clear up confusion.

Will include screenshots for setTimetable.

@totoyoyo Should put screenshots

@hengyiqun

fixed

fixed, but this issue is really up to implementation.

I have fixed min column size, though some people might complain they can't see all the columns

@totoyoyo

No clear command has been implemented for meetings.

@skinnychenpi

@totoyoyo

@hengyiqun

Fixing CI

SOlved

Add glossary to explain what addressbook refers to. @totoyoyo @hengyiqun

@totoyoyo @hengyiqun

Solved

Find free time can be done via timetable

Redo PR

LGTM

Made a new PR due to big changes done after this PR

I added it instinctively.

LGTM

probably not.

I see there are quite a lot of repeated code in here, maybe can try to clean it up?

Probably will, though I will still need to see if Ryan has implemented dark mode and light mode, so that conflicts can be avoided

Closed due to a better representation of this feature.

This issue is resolved when the user interface is being updated.

This is closed together with @rjeez's pull request regarding light mode implementation.

Resolved in v1.4

Fixed in v1.4

Turning user's background to black after blacklisting a person provides a visual response and it is certainly obvious for the users to deduce this fact.

Resolved together with #119.

This feature is implemented just like in usual terminals such as Command Prompt and Linux terminal. User guide will be updated to reflect this subtlety.

Duplicate of #88. Fixed in #145.

Duplicate of #101. Fixed in #147.

Will be resolved together with #108.

I was browsing some other repos earlier, then I saw one of the teams decided to address this issue by explicitly stating that adding people with the same name is disallowed in the user guide. They further claimed that this restriction is for the better of users since it minimizes confusion. 🤔🤔🤔

"e" is already used for email. I'm not sure if I should reuse the same letter for a different function.

Are you planning to add support for deletion of nodes in the future?

Will you be editing the background colour as well?

How will the change be reflected in the UI?

Well done!

LGTM

Well done!

LGTM

Indicate different roles and responsibilities of each member

Team lead: Xuanqi

Documentation: Weiming

Testing: Xuanqi

Code Quality: Jiefeng

Deliverables and deadlines: Vanessa

Integration: Jiaying

Scheduling and tracking: Vanessa

And automatic saving

Good observation, I will be removing that check condition then

I understand your reasoning but by omitting the year, won't the tester just complain that the message is unclear because 29-02 is not a full date or something?

Sure, I will update to that and merge then

Another teammate has already been assigned this task

Note: User may create an instance of Meeting but there is no way to use the instance at this point (eg. cannot add to storage)

LGTM

Commit names could be improved. Other than that, LGTM.

Will be merge first to implement MeetingBookParser.

LGTM

Decide whether findmeet's keyword works by AND or OR.

Calling editmeet with same parameter values as the original meeting should return a specific error message to indicate no changes.

Add the ability to find meetings by status and correct the search scope of findmeet.

Change the UI elements for those fields to stop using elipsis.

Duplicate of #161 .

Duplicate of #164

Check again after resolving #164

Remove the ability to edit a completed meeting unless it involves setting it to incomplete.

Similar to #150 and check again after resolving #164

Duplicate of #164

Duplicate of #157

Duplicate of #153

Rephrase the feedback message to indicate the need for a value for the date-time field.

The user misunderstood how the keyword searches any part of the fields, not the whole word.

Consider including search by days in findmeet (eg. findmeet thur)

Tester did not understand that keywords can be matched partially.

Duplicate of #161

The ability for users to execute meeting commands in client mode causes this misunderstanding.

Duplicate of #153

Duplicate of #169

Will be fixed via #169

Will be fix via #169

Tester didn't know about the existence of client and meeting mode which led to his/her misunderstanding and uses meeting command when the application is in client mode.

Will be improve via #170

Will be solve via #169

LGTM.

No more switching between modes

Cannot be replicated.

Fixed via #142 #114

Cannot be replicated.

Regression happened where editmeet with just a name parameter cannot work.

Preventing relocation of completed meetings was handled in #133.

However, it is possible that an incomplete meeting dated in the past may be rescheduled to another date-time but the client has yet to get back on a suitable date-time. Since such a meeting is still open, its location must remain changable.

Indirectly fixed via #186.

Duplicate of #135.

Duplicate of #152

Remaining classes to add tests:

Meeting commands

The remaining tests will be done by #203

done

Everyone's done with individual tasks. Closing issue.

done w my portion

Done with Use Cases, added 3 use cases. Not sure if need to add more.

Completed add/delete plans

Need to standardise user guide formatting.

Done

This task is to add/delete plans, semesters and modules as stated in the user guide

This is for singular adding of modules (i.e. if I add 3230, I may be reminded that I have not completed CS2040), different from https://github.com/AY2021S2-CS2103-W17-1/tp/issues/17

done w my portion

CI matters resolved, matters to note for future CI issues:

Always clear checkstyle before pull requests
Ensure files use LF for line breaks instead of CLRF
Ensure there is a single line break at EOF

Test PR used with Week 7 Tutorial

duplicate issue

This issue is closed with the current semester command, which is already completed.

This is already done with 1.2, with info command.

Completed with #102

Closed after release.

Done

Closing as requirements changed: this feature would have taken too long to do.

this was completed with the early 1.3 release.

Closing as requirements changed: this feature would have taken too long to do.

list does not take arguments. As per the UG:

Extraneous parameters for commands that do not take in parameters (such as help, list, exit and clear) will be ignored.

e.g. if the command specifies help 123, it will be interpreted as help.

This is a feature flaw as pre-requisites are not checked. Decided against adding this feature by 1.3 due to limited time, will add this as a limitation into the UG.

possible to resolve this in add modules as well, not allowing additions of modules without completed pre-requisites but not as a new command.

Add in UG justification or add modules

duplicate with #193

duplicate with #181

Duplicate with #189

As this bug was reported multiple times, see #177, I think we should resolve this in add modules.

After discussion on rationale of add module not checking for pre-reqs, it should be better to add justification in the UG and perhaps add this as a bug fix in the validate command.

duplicate with #198

duplicate with #181

duplicate with #194

This is a feature flaw. Will add justification to this issue in UG as it is not feasible to add all the modules manually in json which is what we're currently doing.

duplicate with #192

duplicate with #181

duplicate with #183

duplicate with #193

done

Done and closed

As a CS student who does tasks near deadlines, I want to know which task is coming the soonest, so that I can finish it first.
As a CS student who has recurring tasks every period of time (e.g. weekly, monthly, etc), I want to add the task and set a recurring time, so that I don't need to add the same task multiple times.
As a CS student, I want to have notes for each task, so that I remember important information about the task
As a CS student, I want to sort deadlines from each module, so I can estimate how much workload needed for each module
As a CS student, I want to put multiple tasks instantly, so that I don't need to submit multiple times
As a CS student, I want my reminders to show the module code and name
As a CS student, I want to move the reminders easily, so that if the deadline change I can change the reminder easily
As a CS student, I want to know how many deadlines I have and how many deadlines I have done, so I can know whether I am lacking behind or not
As a CS student, I want to have the email of the prof or ta of the module, so that I can contact them if I have an issue with a deadline
As a CS student who just finished a holiday, I want to reset my calendar, so that I can start a new semester with new deadlines

wrong issue for current iteration

Yes, i am confused with the additional tasktracker.json. I check the UserPrefs and the default path is to that tasktracker.json instead of /data

Removed this feature

Invalid (cannot add new feature)

LGTM!

Fixes #60

Added switch statement to add mode of contact picture beside their descriptions

Fixes #89

LGTM

#94

LGTM!

Ahh okay, I didn't know about the runtime and checked exceptions part. Will revise it, thanks!

Ok! I've gone with both suggestions:

Deleted Regex class to use an enum in TimeslotParser class
Merged both date and time for the non-next commands but of course means there are twice as many enum variables now, but beats creating another enum class just for time.

Hmm aites! I changed it to use matcher instead, and to catch exceptions with a boolean isInvalidTime to differentiate the messages likein seb's PR.

But I only created one format with the time -> meaning user has to key in the time and will not be able to leave it empty. Unless I add another conditional for the inputs without time and repeat the matching for dates alone, and create another help method to cut short the matching for date. What do yall prefer!


try {

            LocalDateTime currentDateTime = LocalDateTime.now().withSecond(0).withNano(0);

            LocalDateTime parsedDate = null;



            if (nextDateTimeMatcher.matches()) {

                final String nextTimePeriod = nextDateTimeMatcher.group("nextTimePeriod");

                final String timeInput = nextDateTimeMatcher.group("timeInput").trim();



                // need to repeat matching of dates again, because both are separated and process differently for the next command

                if (Arrays.stream(Day.values()).anyMatch(e -&gt; e.name().equals(nextTimePeriod))) {

                    parsedDate = currentDateTime.with(TemporalAdjusters.next(DayOfWeek.valueOf(nextTimePeriod)));

                } else if (nextTimePeriod.contains("MONTH")) {

                    parsedDate = currentDateTime.plusMonths(1);

                } else if (nextTimePeriod.contains("YEAR")) {

                    parsedDate = currentDateTime.plusYears(1);

                } else {

                    isInvalidTime = true;

                }



                int[] hoursMinutesArray = parseTime(timeInput);

                parsedDate = parsedDate.withHour(hoursMinutesArray[0]);

                parsedDate = parsedDate.withMinute(hoursMinutesArray[1]);

                parsedDate = parsedDate.withSecond(0).withNano(0);

            }

hi im facing some issue with this!

currently, if i input without timing:


add-appt pt/5 dr/dr. pluto at/next month dur/1H 30M t/flu t/covid

there will be a NullPointerException and InvocationTargetException (checked). I tried to catch both in the parseNextDateTime and removeMeridian method but no avail... the former says that InvocationTargetException is never thrown too? have yall encountered such an issue before 😊

Think EventHandler not working. nt sure if its cux of the commandTextField. trying to use the scene way instead? but can't identify it in the MainApp

when I tested this there are no inputs being added to the inputcommand storage zz fixing this too

oh got it!

user input is wrong, should be edit-appt 1 pt/4 dur/ 1H 00M, i can help standardize in UG.

but hmm even if the correct input I still get a NoSuchElementException not sure why... does the EditAppointmentCommand handles a dur/ prefix? Or do you think it's a problem with the timeslot parser

Not wrong date! edit-appt will make changes due to the pt/1, hence datetime remains the same. No invalid message comes up cux patient has be edited.

Should the editAppointmentDescriptor check against every field and existing prefix? if not every valid and non-valid command combo will have the same error

also not sure if severity is high, cux it works the way it should, where at least one of the optional fields have been filled.

Closed to allow for new PR to be made without conflicting file.

Clarification: CRUD is an acronym for "Create, Read, Update and Delete".

LGTM

Update EditCommand.java to fix edit bug whereby edit doesn't work if Insurance Plan is the only field of client edited

LGTM

Code well written and follows proper code principles!

Patched with previous PR

LGTM

LGTM!

We disagree with the recommendation as including the Insurance Plan within the Client UI may result in the UI becoming too "wordy", especially if the client has many Insurance Plans. Instead, we will explore showing the number of Insurance Plans a client has within the Client UI, though this feature will be postponed to a later version of the app.

LGTM, thanks so much, Isaiah!

Added Delete Session Command

Added the relevant classes (deleteSessionCommandParser etc) for the new delete command

updated current test files

Added Ui view for List Persons Command

List Sessions Command added

Added Ui view for List Sessions

duplicate

by checking assigned tutor, assigned timeslot

Update Find Command

Mentioned that only last occurrence is counted in the UG under "Notes about command format".

done, ive made the pr

Hi i think i resolved the conflict

Done

As an SoC student I can filter out non-soc and soc assignments and tasks to improve productivity
As an SoC student i can manage CS coded deadlines by itself since they are not mixed with other faculties mods
As an SoC student I can set reminders for CS coded modules to remind myself of deadlines
As an Soc student i often mix up SoC mods deadlines with other modules, reducing my productivity
As an SoC student, I want to know my CS assignments and deadlines well so i will not confuse with other mods
As an SoC student, I can focus more on my core CS modules by filtering out using the SW
As an SoC Student, I can delete, edit and add CS assignments that are often my core modules. So that I can concentrate better
As an SoC student, I want to finish the CS coded assignments first before other non-CS mods, this SW can consolidate all CS assignments

lgtm!

lgtm

is the same person when:

same name & phone number

same name & email

As a CS student, I want to be able to record down all my upcoming deadlines and assignments so that I have a clearer view on how to manage my time effectively.
As a CS student, I would like to sort my deadlines according to the most urgent ones first, so that I can prioritise my work better.
Being a CS students with many other commitments, I would appreciate reminders when I have a CS related deadline approaching, as I might forget some of them due to my busy schedule.
As a CS student that probably has multiple ongoing coding projects, I can tag each project with the language(s) that they are written in, so I know which languages I need to be proficient in
As a CS student, I can tag each assignment with a priority level so that I know where to focus my efforts on.
As a CS student that does work daily, I would like to be able to assign my tasks to a daily to-do list so that I can plan out my day and the work that I need to accomplish for that day.
As a CS student, I would like to be able to make quick notes on the assignments that I have noted down. This could help me get out a quick idea, or leave remarks on certain tasks that might be relevant.
As a CS student, I can mark assignments that I have finished as completed so that it lets me feel a sense of accomplishment.

Will resolve merge conflicts later

Will merge in my own tutorial since this is my part!

Ok, maybe we can discuss this later? Maybe somebody changed the path accidentally

Will fix CI failures

Merging to wrong branch

Looks like some of the tests weren't refactored from ModuleName to TaskName after the merging with my previous branch

lgtm

lgtm!

CI check failed because of checkstyle

lgtm

lgtm!

Don't know why it merged without even requiring reviews, shall revert and PR again

lgtm!

Updated two things:

Added the header for "All tasks" and "Daily tasks"
Enabled colour for the priority tags

lgtm

Invalid; the user input isn't even in the prefix format. Our UG addressed what would be considered a valid prefix.

Update UG and DG to specify that only positive integer percentages will be allowed. Exception thrown to also be updated to reflect positive integer percentage value. Reason being that not many modules have half percentages.

If we want to persist daily tasks into storage, it would also make sense to be able to clear all daily tasks. Check with tutor/prof if this is allowed.

Specify usage in the error message

Specify which index is to be used for every portion that involves index. --> specify whether it's index in All Tasks, or index in Daily Tasks.

Review duplicate task checker (how the code checks for equality - the #equals() method might not be updated for Task)

Modify regex string

Fix if possible (bugs in UI may not be counted)

See if can put them in the same box (bugs in UI may not be counted)

Same as previous

Some assignments might not contain weightage. Update the UG.

Same as previous

Can check Storage component to see if it can be refactored.

The logger might name the file as addressbook; can go and check

Apply notes label

Update UG to restrict to upper case, and also specify in the error message

Specify in the app

Add segment for notes

Standardise the error thrown

Regex to support up to CS6k mods

Same as previous

Check for duplicate daily tasks.

Same as previous

I'm using Big Sur to develop this and there is no problem on my computer

Don't know whether we can implement another function?

Email the tutor and see if possible to add feature for auto complete?

Same as previous

Update predicate

Same as previous

looks good 😃

Thanks for rmbering abt the CI

~From my iPhone

lgtm

nice!

lgtm

noice

nice

goot!!

lgtm

nice!

well done!

nice!

looks good

nice

goot

noice

Changes already merged.

Already mentioned
Not sure what the problem is because no screenshot was attached to the issue + screenshot provided is the same?

testing@gmail nono check the regex

Need to check for venue and persons also

Now allowing apostrophes and hyphens

Due to EOF at newline issue, the CI test can't pass.

But the code should function with no error.

Finish this task.

My checkstyle has some issue, so I can't see where I am wrong in terms of style. Please help me to correct those if you can run the checkstyle, thanks!!!!

Simply add the class, further job including integrate it into the model. (Coming up soon)

Errors occur because of new methods need to override on the model interface.

LGTM!

LGTM as well.

Looks good!

LGTM,

Done!

LGTM.

Complete merging Maurice's modification.

Fix this bug already.

Bugs fixed already.

You mentioned that: "Also seems like we need check a lot of conditions

For example if delete/edit person -> we need to remove/edit from connections

if delete/edit meeting, we need to remove/edit from connections the meeting"

I have already implemented those cases except the clear command. Will do it later.

Also it seems that the CI didn't pass.

Fixing CI

OK.

oh,i don't know when i space here... just delete it

it is for checkstyle i think

good

looks Great

Looks Great!

Looks Great

the posithon of "unclean" is Index1, just like input "status clean no-index 1", so error message "index is not a none-zero undigned integer"make sense.

similar issue to #213, colse first

the issue is same as #211， I have fix it in a PR. the issue can be closed

This is not so important, because we just want to show all list after each time updating

maybe miss some message about sorting way in UG?

same issue as #195, close this first

this issue is similar to #226 , it has fixed in my new pr for index problem

Looks great

Update the index.md file to fit TimeforWheels product

Update DoneCommand

DoneCommand "done [index]" will create a checkmark on the entry

enable assertion in the gradle file

Could try adding test cases for the stats command to ensure it works well

Ok noted will do so asap

import * in DeliveryListParser.java preventing the checks from passing

Change Syntax of the GUI

will update user guide

we will update user guide

think is because done 2 is out of index in the filtered list

for users to undo if they make a mistake

minus done from deliveries due

works fine on our side

update the ug

update ug

update in ug

thanks will update the ug

LGTM

Instead of deleting orders when the menu items they contain are removed, mark them as cancelled instead

Also changed all instances of contacts to customer in the UG.

Also modified menu list to only show dishes that can be produced given the state of the inventory.

Bug in the ammended statement resulted in improper Menu item creation as the ingredientID should be checked against the Ingredient list and not the Dish list.

This might be deliberate so as to accommodate various phone number formats.

Target user profile, value proposition, user stories, and use cases added. Glossary and NFRs are kept the same

LGTM

updated Developer guide

Added user story in DG. Linked PR for the change

all to implement

Failed tests. Close

LGTM

nice LGTM

lgtm, nice \ns

This is for list command, list all tasks the user has

alright ok just for basic instructions then

For now, we will stick to this, it will definitely be applicable and can be extended if required next time.

I have fixed my comment to missing year from the starting date.

I have fix the correctness of month in starting date

I will be refactoring the email field to recurringDate in v1.3 milestone

Remember to link the PR to the issue you have been assigned

I just help to link the pull request #61 of done command and status attribute to this issue

Not required since PR #114 CI check can be rerun

Also can be ignored. Nothing doing

There is no point in leaving so many upcoming recurring dates

since it will not be useful to the user and our current UI design

limits up to 3 recurring dates to be shown at a time.

When the recurring date has expired, a new date will replaced

the old one.

It is mentioned in the error message index must be a positive integer

The conditions are stated clearly and comprehensive

enough for the user to understand in the error message

as well as the add/edit recurring schedule in the UG

General message is being used and

a example is provided in error message

User guide has also mentioned the date format clearly.

There is no point in leaving so many upcoming recurring dates

since it will not be useful to the user and our current UI design

limits up to 3 recurring dates to be shown at a time.

When the recurring date has expired, a new date will be

replaced with the old one.

After thinking about it, I still feel that as long as

the error message displays the correct string

values accepted for day of week and week frequency.

It is very easy for the user to follow.

First of all, we have to account that the users

cannot remember the title fully. If we design full

title matching, it will be a disaster if the user wants

to find the task urgently but only can remember partial

words.

Next, I noticed that there is an input error you did not

state find test 5 but test 5 only in the screenshot.

General message is being used and

a example is provided in error message

User guide has also mentioned the date format clearly.

It is a documentation bug and

not a functionality bug.

I will fixed it under the issue #16

you have opened.

Recurring schedule is designed in a way that

it will find the next upcoming Sat away from

the current system date (non-inclusive of the

current system date when the user entered the input)

It is not a functionality bug but thanks for highlighting

this issue, I will update user guide will update to avoid confusion.

It was mentioned in the documentation already

that the no d/ prefix should appear in

search by title query.

Added a screenshot with example

It is a wrong use of the feature, it is

date prefix set/ that you should

be using for deadline tasks.

I went to look up abit online and ddd is actually

representation of julian day format.

Resolved in PR #206

hanbin ytd already removed the unnecessary part

Ayeee! You're welcome! :DDDDD

Merge will close linked issue #54

Linked issue #76

Closed as mentioned issue proposes fix

I would propose using the format below!


{

  "foodIntakeLists": [ {

    "date" : null,

    "foodIntakes" : [ {

      "name" : "test",

      "fats" : 10.0,

      "carbos" : 10.0,

      "proteins" : 10.0,

      "date" : "0001-01-01"

    }, {

      "name" : "test",

      "fats" : 10.0,

      "carbos" : 10.0,

      "proteins" : 10.0,

      "date" : "2050-06-20"

    } ]

  } ]

}

After discussion, proposed solution:


{

  "foodIntakes" : [ {

    "name" : "test",

    "fats" : 10.0,

    "carbos" : 10.0,

    "proteins" : 10.0,

    "date" : "0001-01-01"

  }, {

    "name" : "test",

    "fats" : 10.0,

    "carbos" : 10.0,

    "proteins" : 10.0,

    "date" : "2050-06-20"

  } ]

}

For issue #77

Thanks for quick fix!!

Looks good to merge!

People's names can have non-alphabetical characters in them. Closing.

Thanks!

Failed CI checks

Failed CI tests

Conflicts

Failed checkstyle

Fail CI tests

Failed CI tests

Pull first then add the date field since the latest commit has passed all the CI checks.

Failed CI tests

Wrong branch

Thanks for reporting the bug, will update the UG.

@Nanxi-Huang did u pull the latest version before you modify the file, cause right now there seems to be a conflict happening.

LGTM

Cannot pass the test

lgtm

Lgtm

Seems like my checkstyle not running in DeveloperGuide.md

@Andrewzhang217 I never add a new line at EOF in one of my puml file. It's fixed now. Thanks

Add a new line at EOF at AddReaderSequenceDiagram.puml should be able to solve the issue

lgtm

I agree, I think the userIDcounter should be implemented perhaps in addressbook instead as certain tests fail currently due to ID not syncing up

Thanks for pointing this out! Will amend the code now!

This will take in dd/mm/yyyy, dd-mm-yyyy or dd.mm.yyyy and helps validate leap year as well. Do you want me to modify it to only support dd/mm/yyyy?

Just male and female

Alright i'll edit this. Does this mean that we input the ID of the owner when creating a Dog?

I agree, will amend this!

Is a set better? Because there is no java implementation of ArraySet

Modified it.

I agree, will change it!

I see, ok will remove these lines!

Will create new issue to add tests.

I think you can proceed to do the adding and deleting, just that the execution part don't call on model to do the adding, perhaps give a successful response and make use of the gui to get some feedback.

Alright, this is so I can test the classes I just created right?

Added DeleteActivityDiagram

Added "Navigating the User Guide" section and added symbols to help the reader understand the syntax in the UG

LGTM 👍

I like the colour change, but it doesn't seem like the issue has been resolved. I think what users expect is that the suggestions isn't selected unless arrow keys or tab is used to trigger the selection, then without those keypresses, the enter key will work for the command box directly, so commands like list and exit only need to press once without dismissing the suggestions.

Ok will look into this!

@kouyk done with the changes

hmm that's interesting. cos i followed the format of the other implementations where the diagram is below the words

I agree with your observation, though instead of removing the menu bar outright, I feel that we can replace it with a banner saying History and Response, much like your original UI mockup. We can discuss this tomorrow along with other UI tweaks we can make this coming week.

did not realise this is intended behaviour...

ok currently i got the tags to show up for these commands, but i realised that the only relevant tag for these commands is the method tag; the other tags do not make sense to be included since no api is actually called, so there is no data to be shown in those tags unless we want to actually run it like the show command.

hmm, in that case i can see the point of beautifying for add and edit, but it would make show a redundant command imo, since the result would be indistinguishable from run/send on first inspection.

I've also implemented roughly the same thing in #568, but with added beautification for the response. I also see a few other changes elsewhere, so I'm not too sure about merging

Resolved with #572.

Closed with #572.

Default theme fixed by @ong6 in #572.

I've been working on this since formatting the DG.

@ong6 where are u printing from? on my end (https://nightraven49.github.io/tp/DeveloperGuide.html) no issue.

okay i will add that!

oh, so we will include finance-related stuff also? okay no prob i will remove number 7!

sorry yk what do you mean by this, it was bc yt accidentally put 1 instead of 2 (its by right supposed to be 2), but bc it was a failure test it still can pass the checks, so i j changed it for her!! but all the other testing functions use ...1 and ...2 if there are multiple programs involved!!

haode!!

okay, ill work on that in a separate commit!! i will add more failure tests first, thank u boss!! 😄

LGTM

lgtm

Tutorial no need to merge thx!

missed check

This is to fix the return unable to update UI issue.

Record's dateReturned attribute to final.

And set record to a new record object.

fixed

Very solid testcases!

Fix #26

UG has been updated

edited

Completed and approved

LGTM

Looks great, good job!

LGTM

Looks great!

Looks Amazing To Merge

LGTM

Yes, we are looking to use more colours in the future interations. Currently we do provide support for the more general colours, such as black, blue, white and so on, but in the future, we would look to add in more colours, and also likely an RGB selector

We thank you for this suggestion. However, as we are not able to add in new features now, we would look to add this in future iterations.

This is intentionally done this way for cohesion across commands as our other commands such as edit do not specify the field edited as well.

As an individual operating a private book loaning service. I can rank least borrowing books, so that I know customers’ preference and reduce importing of those types of books

Looks good to me

Please fix the checkstyle error before merging to master branch

This pull request looks good to me and can be merged to the master branch of our team repository

This pull request looks good to me and can be merged into our team repo master branch

Solved the typo.

Thanks for your suggestion but when the app window is too small it is unable to show much information. Simply magnify the main window can show the full tag.

Thank you for your advice. It is solved alr.

Thank you for advice. It is solved alr

Fixed

Ok thanks! I've edited the code

Error in commiting, please do not merge

Error, please ignore

good edit.

lgtm

looks good to be merged!

looks good to be merged into our team repo.

LGTM!

LGTM

Ctrl-f "address book", "ab3", "AB" etc over entire code base

Accept M/m/male/Male/MaLe/mALe

^ We confirmed this with a real insurance agent. Thanks for the comment though!

The meeting list is already sorted from earliest to latest, so the user can simply look at the meeting list.

Not clickable because the app is optimised as a CLI

The error is due to the fact that he used "/eep" prefix for the phone number field

Make error messages consistent for index 0 and index out of bounds

Change to 1 whole code block

Change UG to tell users not to touch the data file, if they accidentally edited it and made it invalid, delete it and restart the app

Standardise format for notif and meeting

Kenny: change file name to linkme.json

George: change UG

LGTM

Fix "initialising AddressBook", "Will be starting with a sample AddressBook", "addressbook.json", "Starting AddressBook"

Handle both cases where there is no space in front and behind the @ symbol

Allow parentheses for name

Oh I see, I think you're right. Thanks for spotting that constraint!

LGTM

my bad i put ur link in and it just gave me our team's one so i thought it was the same oops 😅

yea i agree that the INDEX_ references are not that necessary

ok i'll look into it another time! let's merge this PR first and i ll continue from there onwards 😃

right my bad!

oh ok i see alright i can modify getTypicalDatabase to contain programs as well then

omg my bad LOL i think i was doing some debugging and changing back and forth

okie!

yea i will thanks i totally forgot that existed!

on it

hmm i tried to add the programs into getTypicalDatabase, but it caused some errors with the JsonDatabase side and caused multiple tests to fail. I reverted back to using a separate one that includes programs, but have made all the other changes 😃

hmm i didnt do this, just changed it to an available constant from the util class, but i can add some in!

I am merging this PR here, since integrating the Date class with the Person class would mean a lot of work. So, better to keep this part of the work intact, and do the remaining part by generating a new PR.

Hi, could anyone tell me why I am failing the test cases?

Okay, I passed all test cases and the app runs fine with all the features working after adding Date.

I think you need to fix the order of imports for the checkstyle test to pass. Apart from that, is it possible to make the filter command more versatile, by filtering data using other criteria apart from deliveries labelled as done?

Also, you need to create test classes for any new class that you create, in order to get the PR to pass all the checks if I'm not wrong. Here is a reference to adding a new command to help you: Adding New Command.

I think some of the fields in the StatsCommand class need to be changed to private.

For the developer guide and user guide, don't we need to put a screenshot of the commands?

Okay, updated developer guide.

Changed the title for the developer guide to the previous version before PR 55.

Updated the User Guide

Enable search by address and remarks.

Enabled searching by all customer attributes.

Okay, fixed bug

I think you need to update the storage files, and also modify the parser tests since most of the issues seem to be from there.

This seems to fail a lot of test cases. I guess you can run the test on Gradle to see which test cases are failing and try to fix them.

Hi, could you tell what the error message is? It works fine on our end. I'm guessing the date format is wrong.

Okay, will look into it.

Will update the user guide.

It's meant to be unmarked in case of mistakenly marking a delivery as done. So, it is not a functionality bug but rather deliberately done in this way.

It's is implemented that way, to ensure that if you mistakenly mark a delivery as done, then it can be unmarked. So, it is not a functionality bug, but a deliberate extension to the feature to make things easy for the user. However, we will look into it to see if we can offer the same functionality in a different way.

Okay, will update the User Guide for this.

Hi, for 2 you get both because both entries have the same telephone number, and the find command allows you to search by multiple attributes for the same command, so you were effectively searching for entries named Mark as well as entries with the stated phone number. For 1, so far we return matches only if the keyword completely matches an entry, so partial keyword will not yield results. However, we will look into this to see if we keep it the way it is based on the requirements of our app.

Will update the UG

Updated my PPP.

Hi, I think you entered the date in the wrong format since on my end it works.

Updated.

Added the edit command to the user guide.

The issue here is that the date is validated using Java's localDate which allows taking in the dates specified above. Now, for the first date included, the date looks wrong but is actually valid. Adding a range for appropriate years might sound good, but may actually reduce the functionality of our app. Java's localDate also allows taking in negative years given that it allows entering date in two eras. For the time being, the advice would be to refrain from entering negative years.

The issue has been fixed.

Yes, I was just thinking about that too. Looking at the other methods that were implemented in BudgetBabyLogicManager, I realised that it shouldn't be a problem if I returned a List. Thanks for the suggestion!

I think it would be good if you could make this title more specific? Like what aspects of a month in particular? As @eksinyue mentioned, I also feel this PR is similar to #74, solely from the title.

Hi, may we get the steps to reproduce this error? I'm not exactly sure of what's happening here and how this graph is obtained. @tlylt

I see, thank you for mentioning the additional bug as well! We will take a closer look into it and solve it ASAP 👍

Could try adding test cases for the stats command to ensure it works well

Looks good, maybe you can try to increase the test coverage further

For your month input its 2 when it should be 02 as the date takes in YYYY-MM-DD hence the error. The error message should have stated that "Dates should be of the format YYYY-MM-DD, and must not be blank."

Thanks for spotting the bug, will update the user guide.

The application is not meant to serve not Singapore hence we didn't limit the phone number digits.

Thanks for reporting the bug, will update the UG.

Thanks for reporting the bug, will update the json file to match the latest version.

Thanks for reporting the bug, will update the error message in the application.

Thanks for reporting the bug, will update the UG.

Thanks for reporting the bug, will update the json file.

Thanks for reporting the bug, will update the UG.

Thanks for spotting the bug, actually calling done on a done delivery will change it back to undone but it wasn't clarified. Will update in the UG to make it clearer

Thanks for reporting the bug, will limit the date to fix this bug

I just wanted to leave the hash-tag before the line.

Yea, you can refer to our submitted user guide.

Mostly formatting issues as far as I can tell, you can just amend your commits and force push to this branch, no need to close and create another pull request. Or maybe you want to do the formatting once after everything is in?

I closed it because idk how to rename the commit message xD.

Ok, I will remove it.

Yea, I know but the codestyle forces me to do so. Idk why lol

I noticed that too

Ah, I see! Coz I was trying to make it to look the same with the MESSAGE_UNKNOWN_ENTITY and MESSAGE_UNKNOWN_COMMAND that were used in addressbook.

Noted!

Yea, I made it public just for the testing. Does that mean I only have to test public methods that are written?

Weird, didn't notice this earlier on. What can I do if something like this pops out?

OK, I will check that again. Coz it shows an error of separator wrap which is regarding the brackets.

The examples are at the bottom. I did it just like the add and delete command format.

I just wanted to make it easier for me to reference the attributes of a program when writing the DG. Forgot to remove it, thx!

Can I just remove >>

Um, I thought u told me to remove all unfilteredList related stuff in the comment from my previous PR?

If you want, I can put them back

Done

Everything should follow this right? Then most of the help command formats are wrong.

So follow the format in UG?

Done!

OK!

I just copy n paste from the previous PR. This part was accepted last time so I assume it works for now?

Same reason as above

I think this part is causing some bugs. Coz from there's no execute() in editOwnerCommand and editProgramCommand. So this execute() should inherit from editDogCommand as well since it already inherited the editEntityCommand.

Remove! Yea, I totally understand, Anli has told that during the meeting. As you can see from my latest commits, I have pushed only small PRs. And also I push this long PR since #281 has already been approved last time. Coz I thought you won't review it anymore as it is exactly the same thing.

Hope you can understand. I apologise for doing this.

Remove!

Other fields are at the top, right?

Wait, I thought this clearly covers the duplicated tags and different tags? I can add different sessions if that will help.

what I need from you is to write test methods that instead test if multiple tags & sessions are all accepted.

You mean to test multiple tags and sessions?

Um, I know how Pawbook works lol. Instead of explaining how the function work, can you specify which part the error is caused? I tried adding dogId to new owner and remove dogId from the old owner before I pushed the latest commit here but it doesn't work as well. I'll push the one I did which follows the approach u mentioned here, but it has some assertion error which highlights that the owner to remove dog id doesn't have that dog id. Maybe, you can have a look at it.

Made the necessary changes.

I think we can finalize the formatting in the meeting later. Maybe when we merge, we can just put the parts that others have edited into this.

Noted! Sorry for the mails.

Sorry, I don't really get you. Can you tell me what's wrong and necessary? I thought I tested on the changes made in your PR?

Sync master

Ignore this! This is duplicated!

I will upload the test cases in another PR when this edit command works yet.

I think some of my feedback for the previous attempt at writing test still stands, like the typical addressbook ideally should be combined as one since there's no benefit to having 3 that's hard to maintain, I do see some effort made to refactor some tests, but some generics are not written correctly. Furthermore, I think while most of the edit implementation can be attributed to you, kindly exclude the edit program ones as you initially only implemented edit owner and edit dog partially.

Do you mean combining the TypicalDogs, TypicalOwners and TypicalPrograms into TypicalAddressBook?

Can you merge this first? I'll make the changes for the typical addressbook thing in the next PR

Although we are not implementing it, I juz changed it to Pawbook for all those diagram so it fits in unless you want to remove. Coz for those parts that we are not implementing is written as address book. This will make it neater.

If you look properly, the addressbook in the uml diagram is changed to pawbook.

OK, I know why it happens coz our master is updated when I changed it. So when I sync my master with team's master. It is left out 😦

Lemme do it real quick

Done!

Idk how to drop it 😦. When I tried rebase in sourcetree then this happens. How can I put this outdated branch on top of the latest current branch? What's the correct way?

Switch to PR #396

Made those changes! Just that after restoring the execute() there's one test case failing in editDogCommandTest which I have commented out. I need your help for that, I have tested the database.equals(other.database) in equals() of ModelManager is failing. I tried printing it, the database is exactly the same object but it fails...

Also, is possible to merge this PR? coz it's getting bigger

This is what I have done so far. I added the part for delete dogid from old owner but it still fails. Do you mind helping me with this part, I'm really stucked. Perhaps, I can start working on developer guide.

Force merged due to MacOS building cannot start

tP comments dashboard

1. KOU YONG KANG @kouyk (188 comments)

2. TAN JUN HAN IVAN @ivantjh (139 comments)

3. KHOO MING WEI, BENEDICT @benedictkhoomw (137 comments)

4. TAN JUN WEI @w2vgd (131 comments)

5. VEVEK SELVAM @vevek (127 comments)

6. ONN WEI SIN @onnwards (121 comments)

7. LEE WEI YI, SAMUEL @samleewy (93 comments)

8. LOW EN HAO @enhao25 (85 comments)

9. FANG JUNWEI, SAMUEL @samuelfangjw (82 comments)

10. NICHOLAS TANVIS @nicholastanvis (78 comments)

11. HO WEI JUN SHERMAN @nighoggDatatype (74 comments)

12. CHEN YAN JIA, JAY @JayChenYJ (70 comments)

13. MOHAMED FAZIL S/O WAHID ALI @Md-Fazil (66 comments)

14. HOW YU HIN CHESTER @chesterhow (62 comments)

15. CAO NGOC LINH @cnlinh (61 comments)

16. DANIEL LAU YEW EN @daniellau88 (60 comments)

17. LEE XUAN WEI, JEREMY @jlxw48 (52 comments)

18. CHONG YAO WEI @yaowei-soc (48 comments)

19. SIDDIQUI UMER HASAN @umergta (48 comments)

20. SUNAGA SHION @nowknowing (46 comments)

21. DYLAN GHEE SHAO KANG @zatkiller (44 comments)

22. GARY LEE JIA JIN @garyljj (42 comments)

23. KUMARAN S/O SELVVARATNAM @kumsssss (42 comments)

24. GOH JUN WEI @JonahhGohh (42 comments)

25. TAN JIN @tjtanjin (41 comments)

26. YEOH HSIN YING CANDICE @candyhy (40 comments)

27. NG WEI XUE @weixue123 (39 comments)

28. SOH XIN WEI @xiinweii98 (38 comments)

29. SOO QI XUAN IAN @stein414 (37 comments)

30. SWA YONG SHEN @swayongshen (37 comments)

31. WONG KOK IAN @wongkokian (37 comments)

32. WONG CHOON WEI @yungweezy (35 comments)

33. ONG JUN XIONG @ong6 (35 comments)

34. CHEW HONG WEI TERENCE @chewterence (34 comments)

35. DAVID AU WEI EN @dvdweien (33 comments)

36. OEI YI PING @oeiyiping (32 comments)

37. LI RUOCHEN @lirc572 (32 comments)

38. NGUYEN DUC DANH @Eriksen2411 (31 comments)

39. JASON TAY @jay9645 (30 comments)

40. TAY YI HSUEN @yhtMinceraft1010X (30 comments)

41. PEH YU XIANG @pyuxiang (29 comments)

Non-functional requirements

@.**** commented on this pull request.

Behaviors: General

Behaviors: Tags

Behaviors: Wrong command format

Additional notes

Side-comment

42. NG ZHI CAI @nhzaci (27 comments)

43. PRINCESS PRISCILLA PAULSON @pPris (25 comments)

44. HE QIYUAN @QY-H00 (22 comments)

45. PANG JIARONG, JACOB @Jacob-Pang (21 comments)

46. LEE PAI JOO, YVELLE @Ellevy (21 comments)

47. LEE YUE YANG @lyueyang (21 comments)

48. JULIET TEOH QIAN YING @JulietTeoh (21 comments)

49. AW ZHEN YI @awzhenyi (20 comments)

50. AZEEM ARSHAD VASANWALA @DrWala (20 comments)

51. TEO HOE KEAT @TeoHoeKeat (20 comments)

52. CLARISSA LEE ZI XIN @clarlzx (20 comments)

53. FOO CHUAN LE, NICHOLAS @nickyfoo (19 comments)

54. TRAN NGUYEN MANH DAN @picasdan9 (19 comments)

55. YU JIAXIANG @litone01 (16 comments)

56. LIM RUI XIONG @RuiXiong2211 (16 comments)

57. ARIHANT JAIN @arihantjain97 (16 comments)

58. V R SOORYA @VRSoorya (15 comments)

59. SHEN YANG @goatygoatygoat (15 comments)

60. LIM LI QUAN @AhQuanz (14 comments)

61. ALZAHRANI RIYADH HAMDAN S @riyadh-h (14 comments)

62. CHEW WEI HAO @chewwh09 (14 comments)

63. EDELINE TENGES @edelinetenges (14 comments)

64. LIN LUE @lue97 (13 comments)

65. TAN BOON JI @tanboonji (13 comments)

66. JOVEN PUA ZAI XIONG @CSmortal (13 comments)

67. LEE ZE XIN @figo2127 (13 comments)

68. MAX NG KAI SHEN @maxxng (13 comments)

69. ZHENG RUOXIN @zhengruoxin (12 comments)

70. YAP JING KANG @SoulUseless (12 comments)

71. DONAVAN LIM JIA HUI @Donavanty (12 comments)

72. THYAGARAJAN PAVITRA @pavz02 (12 comments)

1. KOU YONG KANG `@kouyk` (188 comments)

2. TAN JUN HAN IVAN `@ivantjh` (139 comments)

3. KHOO MING WEI, BENEDICT `@benedictkhoomw` (137 comments)

4. TAN JUN WEI `@w2vgd` (131 comments)

5. VEVEK SELVAM `@vevek` (127 comments)

6. ONN WEI SIN `@onnwards` (121 comments)

7. LEE WEI YI, SAMUEL `@samleewy` (93 comments)

8. LOW EN HAO `@enhao25` (85 comments)

9. FANG JUNWEI, SAMUEL `@samuelfangjw` (82 comments)

10. NICHOLAS TANVIS `@nicholastanvis` (78 comments)

11. HO WEI JUN SHERMAN `@nighoggDatatype` (74 comments)

12. CHEN YAN JIA, JAY `@JayChenYJ` (70 comments)

13. MOHAMED FAZIL S/O WAHID ALI `@Md-Fazil` (66 comments)

14. HOW YU HIN CHESTER `@chesterhow` (62 comments)

15. CAO NGOC LINH `@cnlinh` (61 comments)

16. DANIEL LAU YEW EN `@daniellau88` (60 comments)

17. LEE XUAN WEI, JEREMY `@jlxw48` (52 comments)

18. CHONG YAO WEI `@yaowei-soc` (48 comments)

19. SIDDIQUI UMER HASAN `@umergta` (48 comments)

20. SUNAGA SHION `@nowknowing` (46 comments)

21. DYLAN GHEE SHAO KANG `@zatkiller` (44 comments)

22. GARY LEE JIA JIN `@garyljj` (42 comments)

23. KUMARAN S/O SELVVARATNAM `@kumsssss` (42 comments)

24. GOH JUN WEI `@JonahhGohh` (42 comments)

25. TAN JIN `@tjtanjin` (41 comments)

26. YEOH HSIN YING CANDICE `@candyhy` (40 comments)

27. NG WEI XUE `@weixue123` (39 comments)

28. SOH XIN WEI `@xiinweii98` (38 comments)

29. SOO QI XUAN IAN `@stein414` (37 comments)

30. SWA YONG SHEN `@swayongshen` (37 comments)

31. WONG KOK IAN `@wongkokian` (37 comments)

32. WONG CHOON WEI `@yungweezy` (35 comments)

33. ONG JUN XIONG `@ong6` (35 comments)

34. CHEW HONG WEI TERENCE `@chewterence` (34 comments)

35. DAVID AU WEI EN `@dvdweien` (33 comments)

36. OEI YI PING `@oeiyiping` (32 comments)

37. LI RUOCHEN `@lirc572` (32 comments)

38. NGUYEN DUC DANH `@Eriksen2411` (31 comments)

39. JASON TAY `@jay9645` (30 comments)

40. TAY YI HSUEN `@yhtMinceraft1010X` (30 comments)

41. PEH YU XIANG `@pyuxiang` (29 comments)

42. NG ZHI CAI `@nhzaci` (27 comments)

43. PRINCESS PRISCILLA PAULSON `@pPris` (25 comments)

44. HE QIYUAN `@QY-H00` (22 comments)

45. PANG JIARONG, JACOB `@Jacob-Pang` (21 comments)

46. LEE PAI JOO, YVELLE `@Ellevy` (21 comments)

47. LEE YUE YANG `@lyueyang` (21 comments)

48. JULIET TEOH QIAN YING `@JulietTeoh` (21 comments)

49. AW ZHEN YI `@awzhenyi` (20 comments)

50. AZEEM ARSHAD VASANWALA `@DrWala` (20 comments)

51. TEO HOE KEAT `@TeoHoeKeat` (20 comments)

52. CLARISSA LEE ZI XIN `@clarlzx` (20 comments)

53. FOO CHUAN LE, NICHOLAS `@nickyfoo` (19 comments)

54. TRAN NGUYEN MANH DAN `@picasdan9` (19 comments)

55. YU JIAXIANG `@litone01` (16 comments)

56. LIM RUI XIONG `@RuiXiong2211` (16 comments)

57. ARIHANT JAIN `@arihantjain97` (16 comments)

58. V R SOORYA `@VRSoorya` (15 comments)

59. SHEN YANG `@goatygoatygoat` (15 comments)

60. LIM LI QUAN `@AhQuanz` (14 comments)

61. ALZAHRANI RIYADH HAMDAN S `@riyadh-h` (14 comments)

62. CHEW WEI HAO `@chewwh09` (14 comments)

63. EDELINE TENGES `@edelinetenges` (14 comments)

64. LIN LUE `@lue97` (13 comments)

65. TAN BOON JI `@tanboonji` (13 comments)

66. JOVEN PUA ZAI XIONG `@CSmortal` (13 comments)

67. LEE ZE XIN `@figo2127` (13 comments)

68. MAX NG KAI SHEN `@maxxng` (13 comments)

69. ZHENG RUOXIN `@zhengruoxin` (12 comments)

70. YAP JING KANG `@SoulUseless` (12 comments)

71. DONAVAN LIM JIA HUI `@Donavanty` (12 comments)

72. THYAGARAJAN PAVITRA `@pavz02` (12 comments)

73. LIU YONGLIANG `@tlylt` (12 comments)

74. KINGSLEY KUAN JUN HAO `@kingsleykuan` (11 comments)

75. OH JUN MING `@OhJunMing` (11 comments)

76. JOEL HO ENG KIAT `@JoelHo` (11 comments)

77. BHADANI SIMRAN `@simran-bhadani3` (11 comments)

78. CHEE ERYNNE `@cheeerynne` (11 comments)

79. COLIN TAN `@colintkn` (10 comments)

80. LOO YEOU TZER `@yeoutzer` (10 comments)