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.

[This page was last updated on Nov 07 2020]

I'm not sure if >ins> is the correct tag to use here? (And the closing tag should be >/ins> right) From what I gathered online >ins> is to underline some text in html to indicate it is an insertion, but there's not >del> tag here, so I think it might be more appropriate to use either the >u> tag for underlining or []() syntax if its supposed to be a link

I think we should retain the step of copying our jar file over to the folder the user wants to use as the home folder, as we'll need to do saving in a data folder as well

There's inconsistency between this and the description of the help command below. Also, I think the help contents will be opened in a window and not a page?

Refer to comment above

Maybe we should change PHONE to PHONE_NUMBER, following the original format, for clarity


Shows commonly used commands for TBM.


* Role: In charge of deliverables and deadlines

Following the format for client delete INDEX, maybe add a short one line statement to explain what this command does?

Same as prev comment, and there's also an extra newline here that I think would be better to remove

The indexing is off here

Indexing off here too


* 1a. The list of clients is empty.

Might want to change this to match the original "Finds clients whose names contain any of the given keywords.", and change n/NAME to KEYWORD [MORE_KEYWORDS] as the format section below mentions keywords


* The search is case-insensitive. e.g `hans` will match `Hans`

* The order of the keywords does not matter. e.g. `Hans Bo` will match `Bo Hans`

* Only the name and country are searched.

* Only full words will be matched e.g. `Han` will not match `Hans`

* Persons matching at least one keyword will be returned (i.e. OR search). e.g. `Hans Bo Russia` will return `Hans Gruber`, `Bo Yang`, `Alice Katya`


### Listing all clients: `list`



Shows a list of all clients in the address book.


Finds clients whose names contain any of the given keywords, or whose country of residence contains any of the given keywords.

I think we should just stick to either the abbreviation TBM or the full name in the headers, not both

either that or perhaps change both back to the simple "User Guide" and "Developer Guide". I don't really see a need to have TBM in the title, as the whole website is already about TBM, plus we have introductions and our home page.

Just to add on, I don't think the >ins> tag should be used here, as markup defines it as inserting something? e.g. here. >u> seems more appropriate if the intention is to underline the text.

LGTM


        this.countryName = new Locale("", countryCode).getDisplayCountry();

I think its more intuitive to call this specific method


    private final String COUNTRY_NAME;

    private final String COUNTRY_CODE;

    private final ArrayList<Note> COUNTRY_NOTES;

From the convention guide: Constant names must be all uppercase using underscore to separate words. I'm not sure if countryNotes should be marked final actually, since we are going to modify it in the addCountryNote function.

Also, I feel that the notes should be stored in something like a LinkedHashSet, since we don't really want to add in duplicate notes, and its easier to check if its a HashSet.

I feel like we shouldn't initialize countryNotes until it is actually needed. E.g. Only when the user actually adds a country note, or there are notes for this country in the save file. If not its unnecessary overhead, especially if there are many countries.

Not sure how the rest think @tankangliang @rtshkmr @LeeEnHao

Constant names must be all uppercase using underscore to separate words.

Is there a need for this Map? From what I see, I think we can just keep the ISOCountry String array, then check if the entered String is inside, before initializing a new Locale with that String. This way, we won't have to keep so many country objects, since most of the countries likely won't be used.

Constant names must be all uppercase using underscore to separate words.

Ah ok nvm I think can just stick with this for now. I was thinking of something else to prevent the unnecessary creation of objects, but this HashMap is still necessary for it, my bad.

Btw can change the HashMap to Map, so that we standardize

Hmmmm seems like by constant they mean static final only. Static only or final only aren't counted as constants, even though one of the examples in the website has an example of final only variables being set to all caps + underscores.

No need to change bah

Would be better to standardize with the other commands, for example the ClientFindCommand.

Btw, ClientFindCommand doesnt have requireNonNull(predicate), I think can just add it in there too

There needs to be a javadoc comment here. (All public classes should have javadoc according to the textbook)

javadoc comment

requireNonNull

Might want to standardize with other equals methods. Basically these 3 parts: short circuit if same object, instanceof handles nulls, and state check. Can look at ClientEditCommand for an example

Maybe can add extracting out the messages into a static final string into the TODO: better messages, in case we forget

javadoc comment

Might want to add a TODO here

This whitespace is little bit weird lol, but might just be my personal preference

here too

Might want to change the predicate name to ClientCountryMatchesInputCountryPredicate for clarity?

might wanna change this equals to match the 3 step thing

Probably should calculate and return the hashcode using noteContents, since I think Note is already being used hashed objects

Would suggest changing this to isValidCountryCode, for clarity

Hmmm I was thinking that this CountryManager class holds all Country objects, while every other class should be holding references to these objects instead of any new Country() object. That way, the class themselves should be able to check if the Country has any notes, and this method would not be needed.

Can help to update the parser names for the delete and find command?

Should probably add in a hashCode() function just in case

Actually for this toString, should we be returning countryName instead? Maybe can add a comment to address why we're returning countryCode.

The whitespace is off

Add a comment for standardization


        // multiple countries - last country accepted

not sure about that, but later that guy forget lmao

I think we should just do it now man. From java docs: Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

Yeah, but usually the purpose of the toString is to return a more "human readable" format of the object, so maybe countryName would be a better choice for the return value.

LOL ok then just fix it in that issue bah

Would be slightly clearer if you changed the variables names to SMALLEST_NEGATIVE_OFFSET and LARGEST_POSITIVE_OFFSET imo

Not sure why this sys print is here

Add new tests for timezone pls

We should catch NumberFormatException here, in case people enter a number that is longer than what an int can hold

Extra new lines, and I think the javadoc can be added already right

Would be better if MESSAGE_USAGE is moved upwards for organization purpose, so that public static final is above private static final

Also, its hard to read when the lines are separated so much with the random comment also, would suggest this:

(must be a positive integer should also be moved to the description, not inside the parameters)

Rmb to import PREFIX_NOTE


            + "Parameters: INDEX " + PREFIX_NOTE + "NOTE_STRING\n"

            + "Example: " + COMMAND_WORD + " 1 " + "client note content";

I think everything has to go through model, as it is being used for UI I think

This variable doesn't seem to be used, since you already removed the redundant code

agree with rayson

Would be good to remove the line break for readability

Would be good to move this down, after the if statement

Probably would be good to add a javadoc comment for this method as well

There is a need to implement the hashCode function, since note is being used in a hashSet.

Could you also change the equals method to match the 3 step thing? (1. short circuit if same object. 2. instanceof handles nulls 3. state check)

There's like extra newlines here and above as well

Extra newline

I would suggest that this is changed to a LinkedHashSet, as we will want the order of the notes to remain the same as the order they were added. HashSet does not guarantee order

I believe the country notes are also using LinkedHashSet

Also, I think it would be better if the clientNotes was initialized only if the client has notes, probably can add a TODO here to optimize this.

I think this variable still isn't being used

Other than that, LGTM


    public String getInputCountryStringRepresentation() {

Better to have descriptive function names without abbreviations imo

Probably can be on the same line for clarity

Would be better to move this above MESSAGE_DUPLICATE_COUNTRY_NOTE so that the public static final variables are tgt.

For this, it would be more concise to just use the overloaded constructor of ArrayList ArrayList(Collection>? extends E> c) to make the copy of the filtered client list

Either that or just initialClientList.addAll()

Would it be better to use an assertEquals here?

This can be moved out of the loop I think

The assertTrues and assertFalses here can probably be changed to assertEquals and assertNotEquals for better clarity

Ah ok I missed that

I think it would be better if clientParser accepts a Client instead of a generic Object, then do the casting here. This way, we wont have to do the casting + assertion inside clientParser.

Should these have more descriptive names?

Also, should include param/return tags in javadoc for this method

If this is a temporary method, should add in a TODO somewhere here to remove after its not needed. This method looks very un-OOP-like lolol

Should include params and return tags also in this javadoc

This method needs more explanation using comments/better descriptive names. For example, what is start to end order? Why is there the Math.min with the magic literal 14?

Would suggest extracting out the 14 as a private final static var

Also, I think it should be String... args and not String ...args? At least that's the format google java format uses

Sys.print shld be removed. Also, better explanation should be given in the comments/javadocs, and the variable names should be more descriptive. For example, what happens in the bigger picture if there is no null field that can be set?


public class WidgetModelManagerTest {

Also, extra newlines above this can be removed

Naming of test functions should follow the format

test functions should follow the format: featureUnderTest_testScenario_expectedBehavior()

e.g. sortList_emptyList_exceptionThrown() getMember_memberNotFount_nullReturned

test functions should follow the format: featureUnderTest_testScenario_expectedBehavior()

e.g. sortList_emptyList_exceptionThrown() getMember_memberNotFount_nullReturned

Also, probably should make all the tests public void to standardize

I feel like optional isn't needed in this file? It would be clearer if you do divs[X] == null ? "" : divs[X]

Is this sysprint leftover from debugging? Other than this, LGTM

This should be an assert / exception instead, since our countryNotesMap already contains all possible countries, and if there is a country not contained in our map, it should not have been created in the first place


* SUGGESTION_TYPE must be one of the following: `frequency`, `available` or `contract`

maybe change to command word suggest instead? Make it seem more like normal english

should extract these strings as static final vars

Should add a TODO here to do something in the execution

I think it's fine to leave it as a class for now, since if we change it to an enum it might be hard to integrate. Maybe can just KIV as a TODO.

This needs to be updated to the actual message constraints for note. Commands like "client note add 1 nt/" causes this to appear in the response box, which is a bug.

Would suggest a simple "Note should not be blank"

why are these protected? I couldn't find any other classes in the same package using them

Should return an unmodifiable set instead.

Since the equality checking was updated to include hasSameTags, the hashCode should be updated to ensure the tags are hashed as well, to maintain the contract between the equals and hashCode method.

Should return unmodifiable objects. Also, getCountryNote doesn't seem to be used, will it be used in a later commit?

This doesn't seem to be called in the program, will it be added in a later commit?

I think it would be better if we did a new ClientBuilder(ALICE).build();. The ALICE client itself should not be modified as it may affect other parts of the testing unexpectedly.


    void initMapFromClients_addClientWithTaggedNotes_success() {

This method doesn't seem to return a boolean, so success should be used instead. Or you could change it to doesNotThrowException. The other 2 methods below also need their method names updated, returnsTrue should be <expected outcome>.

Will need to add more tests, but can do in a separate issue probably.

Not sure why only this variable is static? Could probably make all of them just final.

Should probably test the other methods and constructor as well, but can be done later in a separate PR as its not that important for now.

Same comment as in TagNoteMapTest.java

Is this needed lol

Same issue for this, refer to TagNoteMapTest.java for the comments on test method naming. For stuff that throws exception, the format should be ..._throwsXXXException().

Is this needed?

Should not have a newline here

Should probably change this to tagSet.

should probably requireAllNonNull here.

Also, is there a need for this method to be public? It seems to be only used here

This doesn't seem to be used, is it in a later commit?

Also, should requireAllNonNull here

Should do this todo, if not the method name becomes confusing.


     * @param countryNotes The set of countries, each containing their notes and associated tags.


     * @param clients The list of clients, each containing their notes and associated tags.


     * Initialises the TagNoteMap from a list of clients.


     * Initialises the TagNoteMap from a list of countries.

Should untagged tags be added to the note?

agree with rayson, also maybe you can have a static final tag object already created in the Tag class, then your ParserUtil can just find Tag.UNTAGGED

Change this to a todo pls, if not we'll forget to remove it

remnants of debugging?

Done

Removed the other duplicate call

Would suggest adding a requireNonNull / assert != null here just in case. Also, what happens in execute if list.size() == 0?

Actually, looking at this, I would suggest implementing a compound predicate instead of having a list. So maybe something like Predicate>Client> combinedSuggestionTypePredicate = (client) -> suggestionTypeList.stream().map(suggestionType -> suggestionType.getSuggestionPredicate()).reduce(true, (x, y) -> x.test(client) && y.test(client));

^I didn't test this, but I think it should be correct

Should have an equals and hashcode method, so as to standardize with other predicates, and also enforce the contract between equals and hashcode. Since this class doesn't have any vars, we can just return a constant int for hashcode, and have equals return true as long as other class is instanceof this one

Maybe can just put the assert false and return null in the default block? I think it would make it cleaner

Is this method needed? Is it possible to change other parts of the code so we use the withTimezone(String timezone) method instead?

shld add new line before this to standardize

Too many new lines here

Can add one more assert for just "client" without the space? Just in case.

Same for client note test below

extra new line here

Can rename this to clientCommandType? and the country one to countryCommandType?

rename this to clientNoteCommandType?

Small issue, but the number of equals on both sides aren't balanced

what is this supposed to log? I can't really tell from the code itself, maybe make it explicit with a comment?

why got copyright one lmao

also, should add a todo to change this

Each note should display on a separate line, if not long/many notes will be hard to read

If this path is not supposed to be reached, should just throw an exception here, logging it as info doesn't really make sense. You could probably log the stacktrace though

I like the variables at the top, makes it easy to see, should probably standardize for the whole CSS (can do in a separate issue)

For the scrollbar I think we shouldn't hide it actually, and I feel that the border-radius are a bit too much, maybe can reduce, plus one of the boxes (the one that shows the command messages) isn't rounded, while the rest are

For all the changes in this file, should probably standardize to no space before />, since thats the format of all the fxml files

Also, this help icon should be added to the top context menu (can do in a later issue)

??? why is there this assertNotEquals here lolol

are hamcrest and assertj used? Also, do we need to define JUnit as testCompile? (since we already defined it in our testImplementation/testRuntimeOnly)If we need to, should probably use the jUnitVersion variable instead of a string

fx:id here is empty?

The indentation here is a bit confusing, I think this and StackPane above should be indented 2 more spaces?

I think the indentation and line breaks in this file are off. Can consider taking out the <children\ cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> tag and leaving it as


&gt;StackPane>

    <Label...>

&gt;StackPane>

so that clutter is reduced. </children>

this comment seems to be half-written lol

This variable doesn't seemed to be used

I think a clearer and cleaner implementation of this would be .collect(Collectors.joining()).replace("[", "").replace("]", ""); instead of the reduce

"standardise" should be "standardised"

Where is this view variable used ah

Cuz right now its just being set to WidgetModelManager but on the next line you return a new WidgetModelManager?

Can change this to offset or offsetValue?

why was this newline added lmao

extra newline

Should requireNonNull for country

Actually, do we need this ? extends Note? Would using List>Note> be better?

probably can remove this newline


 * A high-level class responsible for mapping ISO3166 countries to their respective country notes.

Actually I would suggest we move isValidCountryCode method to Country class, then this class will be solely in charge of the relationship between Country and CountryNote (SRP), and the classname can be changed to CountryNoteManager I guess

should we put an assert false here?

Should requireNonNull countryNote

Should add simple javadoc for getTags()

Small issue, this should be changed to getCountryNotes

Random "The" here

this sentence is half-complete, I think can just remove the "between"

This png file doesn't seem to have been generated, not too sure why, can you try editing this a bit and pushing again?

extra newline

should have a [else]

Need to update javadoc for this method to match the method behavior

This variable isn't being used

When will this be null? Should it just throw an exception when null if its not supposed to be null?

Should the equals and hashCode methods be updated for this class?

extra newline

extra new line

Can probably add one more test for the empty constructor then check if Instant.now() is > 1s away from the constructed LastModifiedInstant.

ok shld add a comment then, just to explain why its different from the rest

Suggestion: have a public static NULL_COUNTRY object = new Country();, and just use Country.NULL_COUNTRY to access it.

This is what I did for my ContractExpiryDate, so you're not creating new objects all the time, and imo it makes it clearer to the reader.

When will this be the case? Should it be country == Country.getNullCountry()?

This needs more tests, but can be done in a separate PR

Maybe put the comment as a message


        assert !(isClient && isCountryNote) : "isClient and isCountryNote cannot be both true";

should require non null for country

extra newlines

Should probably change these tests to use the assertParseSuccess and assertParseFail static methods

same comment as deletecommandparsertest


     * Gets the list of country notes in TBM as an unmodifiable observable list.


     * @return The unmodifiable observable list of country notes in TBM.

Should this be country.equals(Country.getNullCountry())?

These 2 functions don't seem to be used anymore

these functions dont seem to be used

Should this be paused for longer? I don't really notice it when I'm running the tests

Should add a TODO to remove this test at the end if we find that it's useless

Should probably remove this comment lol


        assertEquals(expectedId + ". " + expectedCard.getNoteContents() + " [" + expectedCard.getCountry() + "]",


**Add country note** | `country note add c/COUNTRY_CODE nt/NOTE_STRING` <br> e.g., `country note add c/SG nt/has one of the lowest coporate taxes in the world`

Think this can be changed to assertParseSuccess


    public void parseCountryCommands_addCountryNote_success() throws Exception {

ah right my bad

missing semicolon here


    -BACKGROUND: #393939; /*DARK GREY*/

    -PANE_BACKGROUND: #000000; /*BLACK*/

    -PRIMARY_COLOUR: #FF3333; /*RED*/

    -PRIMARY_TEXT: white; /*WHITE*/

    -ACCENT: transparent; /*NO ACCENT*/

    -TERTIARY: #010012; /*DARK NAVY*/

probably no need for this, since we're mutating the client directly

spacing here should be 8 spaces i think

Not too sure why these were reformatted, should probably set ur auto-formatter to reformat only when chars > 120 in a line, same for everything below. Also, I think the second line should be 8 spaces instead of 4, when doing a linebreak

probably should name this modelClient instead of freshClient

Should probably change this javadoc to match those of other toModelType() functions like JsonAdaptedClient etc.

Not sure why the formatting in this file changed so much also, would suggest to change ur autoformatter settings to match the project's code style, or not use the autoformatter, if not unrelated lines will keep changing in your commits

formatting issues with this file, and for the testing of the JsonCreator, you can refer to JsonAdaptedClientTest.java, also it only appears to be not used because a third party library (jackson), and not our own code, is calling it, just like how the FXML notation variables don't seemed to be used

these should be on the same line

no space between [ and {

actually for client notes, is it possible to not store the countryCode in the first place? Seems a bit wasteful and unneeded. JsonCreator and toModelType() can probably handle the lack of the countryCode programatically. @raysonkoh any comments about this?

@raysonkoh I think if we change it, we should change before the end of v1.3, since we have our bug-finding practice coming up and people can help catch the bugs if any. If we change after v1.3, we might introduce some bugs that no one finds until the final bug-finding test.

the formatting is still abit off, it should be [ { instead of [>br>{ and }, { instead of },>br>{

extra new lines, also some formatting issues with this file, where lines >120 chars are being broken up for no reason, leading to changes in random lines.

These 2 lines are >120 chars, they can be on the same line. Also, breaking it up at the first . makes it inconsistent with the rest of the code base, and harder to read.

formatting, breaking a line up after = makes it inconsistent with the rest of the code base

can this be put on the same line

same line?

probably can reformat here abit

reformat

change back the indentation pls, supposed to be 8 spaces after the primary line, not 16

lmao good catch

wrong naming/enum? (available vs contract)

small nitpick but can add the comments + the different class -> returns false thing

extra newline


        assertThrows(ParseException.class, () -&gt; parser.parse(" c/MY nt/ t/a"));

        assertThrows(ParseException.class, () -&gt; parser.parse(" nt/ c/MY t/a"));

Better isolation for testing no notes


        assertThrows(ParseException.class, () -&gt; parser.parse(" c/RUS t/a nt/random string"));

        assertThrows(ParseException.class, () -&gt; parser.parse(" c/R t/a nt/random string"));

Same reason as below, also, should have a noCountryHasNote test method

Should this be in a separate test function?

tagNoteMap not being updated after setting the tags?

@raysonkoh I think we can probably remove the model.updateTagNoteMapWithNote() and instead place it inside the function model.addCountryNote, since addClientNote is doing that as well. Then we can remove model.updateTagNoteMapWithNote() from the execute() function of both client note add and country note add, and make the method private in model

there's 2 updateTagNoteMapWithNote here

Can follow the format of the rest of the file and remove the parsesSuccessfully

same as above, remove parseSuccessfully

missing whitespace

missing public

should change to the behavior that the original client edit commands had

missing newline

extra newline

an empty parseException would work, since this whole block is already inside a try catch, can add a comment to clarify

No need to use this arePrefixesPresent function if we only have one prefix to check. Also should be either note string or tag prefix present

what does pe here do?

should "nope" be removed?

extra newline

extra space added

extra newline

need newline here

need newline above

I think we should change it to -> lack of t/ results in the tags staying the same, but doing t/ replaces the tags, instead of adding a new tag. Similar to how client edit worked last time when we had tags.

Also, should there be an option to edit the country using c/?

should add notes about how the INDEX is obtained from the last view country notes list panel

need more tests for this, but can be done in a separate PR

Should this be deleted?

Need some comments here, quite hard to understand what this code is doing.

Imo I think the constructor CountryNote(CountryNote note) and the method setCountry is not needed, instead we can just have a CountryNote constructor with content, country and tags, and then port the countryNoteToEdit fields over as needed.

Feels like that'll make the code much clearer.

Also, I think .remove for sets won't throw any exception even if that item isn't inside the set, so its safe to remove the contains check

Can use the constructor i mentioned in CountryNoteEditCommand for simplification of this line

I think indexOf can throw unchecked exception, so it would be better to do an assert contains before this line, and remove the assert after this line.

Can probably use assertParseSuccess here

Can probably use assertParseFailure here

refer to comment in CountryNoteEditCommand

extra ;


        assert hasCountryNote(oldCountryNote) : "old country note must exist in internal list";

would be better / more in line with other tests to change all these Strings to static final and their names to all caps+underscore


* `country note edit 1 nt/new government policy to support local development in cloud security t/contract` Edits the first country note in the last-viewed country notes panel to have the content "new government policy to support local development in cloud security" and a new tag "contract" in addition to the previous tags.

should move final variables to below static final ones

extra newline

Can we change this to widgetViewBox.init()?


    private void assertViewBoxDisplay(WidgetViewBox widgetViewBox , Client expectedClient) {

should add public in front of these two methods


    private class InteractionTerminal {

I think this + CountryNoteCard class is not being used, safe to delete?

I think this class + the fxml is not being used, safe to delete?

extra newline


     * Returns the client to be displayed in the widget view box.


     * Sets the client to be displayed in the widget view box.

probably can remove the @param since there's no description, and adding a description would be redundant

probably can remove this @param

probably can just remove this @return


     * Static factory for use in GUI testing.

Actually, not sure if there's a need for this static factory since we can replace this with new WidgetViewBox(FXCollections.emptyObservableList()) in our test functions


     * Updates the current client of the widget view box to the given client.


     * @param client The new client to display.

should this be here?

don't think the stream() here is needed

extra newline

no need for contains, since set.remove won't throw any errors/exception even if the tag is not inside

Can remove TypicalClients.

Also, no need for new ArrayList since Arrays.asList already returns a list

should only have one newline

can't we already remove it? Since its not being used anywhere in the whole codebase

what does the pe do?


    private Model model;

Already done in setUp

If this is needed to be called everytime we create a modelManager, shouldn't we just put it inside the constructor?

same comment as above

shouldn't setClient method in modelManager also update the tagNoteMap? Not sure where its being done currently.


        return Arrays.asList(alice, benson, carl, daniel, elle, fiona, george);

No need for extra brackets

is there anything we can do in tagnotemap that would allow us to replace a client instead of doing re-init?


Given below are instructions to test the app manually. Additionally, testers can look through our [Testing Guide](Testing.md) to get started on automated testing.

the file Ui_old seems to have been renamed to Ui in this PR

I think the standardization for the md files is to not have line breaks unless the actual line is 2 lines, since word wrap can already do this kind of line wrapping for you

same for these lines, and many other lines in the file

there's a lot of random new lines in this file, would be better to remove them

I think the ./ should be removed, so that it matches other urls

Theres an extra space between first and time, and also between you're and trying

Should this be Country Notes instead of country?

Not sure if the triple * is intentional? But it seems to give the same result as **_, (italics + bold) which I think is clearer, since triple * and double * look too similar

extra space

about a particular client*


* **Client List Panel** will always allow you to view your clients' information at a go. It's scrollable so that you

I don't think spawn is the right word to use here. Also, we shouldn't put generic widget view box in our user guide. Something like display panel would be more appropriate


 relevant commands are sent. Initially it will show you your local time to the precise second, as well as your current location.

extra spaces at 3 locations

I think we're standardizing using ** for strong and _ for italics. Btw, don't break the html tags


        assert !clientNotes.contains(clientNote);

For standardization

Would suggest changing this method name to getClientNotesAsUnmodifiableList()

Needs a new line before this comment. Also, I'm not too sure what this comment means?

Can just change this to an assertThrows

same as prev comment


                    assertEquals("1", commandHistory.getPrevious()));

should probably do another UP and check if getInput == viewCommand1 then DOWN again and check if getInput == viewCommand2

Should add more tests that do invalid commands then check if the history is correct, and also test the behavior with no history, and the behavior when there's no previous history, and lastly the behavior when there's no next history.

Empty else block shouldn't be used

Can we get the command box to clear the very first time there's no next element? (So like it shouldn't clear if I'm just typing and accidentally press down, but if i'm going through history and press down after the most recently used command it should clear) I think that's more consistent with CLI behavior.

is the null check needed? When will it be commandTextField.getText() be null?

my suggested change was only 4 spaces, my bad. It was my intention to align all the assertEquals rather than just add 4 spaces lmao.

This isn't being used?

is there a need for 2 x clearTemp()? Or is one enough

would be clearer as a else if (hasRudimentary()) + throwing outside of the if/elseif block

I'm not sure what the rudimentary is for? If its to store an incomplete command maybe can the naming to incompleteCommand instead of rudimentary

incomplete sentence + unneeded line break here

is there a need to use a static init? I think currently can just call constructor without args and create the empty arraylist inside the constructor

related to comment in commandbox.java, I think can just this.history = new ArrayList>String>() inside the constructor, instead of having the args

renamed to jsonAdaptedCountryNote

my bad, added it back

Should probably change this to return Arrays.asList and the return type to List>CountryNote>

Is it possible to change OS-X to macOS for both UG and DG? I think it'll be better


Views the list of country notes that are associated with the country corresponding to the country code supplied.


Adds a note that will be associated with the country corresponding to the country code supplied.

Should we make this bold? Just in case. Also i realised we can delete country notes even when we haven't viewed the list panel displaying country notes lol, like directly from startup

bold this?


Due to ambiguity, editing of a country note when the country notes panel is not being displayed is not allowed, and an error message will be shown if this is attempted.


Due to ambiguity, deleting of a country note when the country notes panel is not being displayed is not allowed, and an error message will be shown if this is attempted.


* **Display Panel** shall render *Client Cards* or *Country Cards* when relevant commands are sent. The default view shows you your local time to the precise second, as well as your current location.

Should this be left inside? Since it's supposed to be a snippet. Or maybe change the desc to "Here's a sample showing what this editable text file will look like:"

Should all the figures be wrapped in >p align="center"> ? Also, maybe make them italicised

This else block should belong to the other if statement (if (clientObservableList.size() == clientListSize && !c.wasPermutated())), and not the inner one. If not when you remove the client you're currently viewing it won't go back to default view

I think this should be 'content' instead of Note.class.getSimpleName(), if not the message will read: Note's Note field is missing

Should lowercase the getSimpleName so the displayed message will look less weird

extra newlines


            "Phone numbers should have at least 3 digits and at most 15 digits, please refer to our UserGuide for"

>i> tag broken

extra space before br


**PHONE_NUMBER** | `p/` | Phone numbers should have at least 3 digits and at most 15 digits. <br> Please refer to [Appendix B](#appendix-b-international-standards-followed) for a comprehensive description. <br> e.g. `p/81867752` or `p/+65 81867752`

extra newline

grammatical error: "may follow this international"


   <strong><i>{End of Appendix A, please return to the <a href="#table-of-contents">Table of Contents</a>}</i></strong>

Think we should change this back to the wikipedia one, since the official search tool is an alternative

random line here that is out of place

Comments not updated

Should this be 12 digits instead, since it is without country code

Maybe add some examples like so: "Note that parameter prefixes such as t/ or n/ are special keywords..."

Better to use an assertDoesNotThrow() here


     * @param filePath {@code Path} where the {@code UserPrefs} shall be stored as JSON.

Block comments should follow this format:

I think can leave out the "within the Logic component", since the diagram also involves the model component. Also, not sure why the model part was cut to become less detailed?

Does Country actually have a dependency on CountryCodeVerifier? It seems like its only referencing it in an assert.

Is it possible to have an else after this if so that the diagram looks better? Like the right arrow coming from the first diamond should have an [else]

I think using a merge node to merge all arrows before pointing to end will be good, not sure if it's a limitation of PlantUML that there are double arrows.

Not sure actually, but on second thought to be safe it's better to leave it in bah

Ok sure


     * Gets the list of client notes associated with this client as an unmodifiable list.


     * @return An unmodifiable list of client notes associated with this client.


     * Gets the observable list of client notes associated with this client.


     * @return The observable list of client notes associated with this client.


     * Replaces the contents of this list with the contents from the given {@code replacement}.


 * A representation of a Country that is identified by a 2-letter ISO3166 country-code.

Not sure why this message was broken up into two lines

If its not too much work, I think it would be better to revert to the previous format of multiple test functions actually, since most of our test files use the multiple function method, and that's what the coding standards seem to recommend also.

see prev comment


     * @param note The particular {@code Note} to get associated tags for.


     * @param tag The particular {@code Tag} to get associated notes for.

the link leads to a table with UTC timezones instead

I think we should standardize (forgot which other file was it) and just remove the static, and add a comment above saying this is some special static init block

Is there a need to convert to arraylist? Cannot just iterate through the set?

Should probably add a comment stating what this does.

same comment as in UG about the link. Is there any better links?

Is this some special case? Should add a comment if that's the case


            long currentHour = (totalHours + hoursOffset) % 24;

Should add a few more negative test cases like "GMT" and "GMT+" and "GMT-", and maybe "gmt+08:00", and "GMT+8" and "GMT+08", and "GMT+8:00", and "GMT+08:0"

extra newline

Yeah its cuz the parsing of a date string always needs to have exception thrown

I'm not sure if and how the LocalDate parser does its parsing though, so I would prefer to be safer by mandating the regex check. For example, it might parse 20/19/020 as a correct date and not throw any errors. Apparently using the ResolverStyle.STRICT is supposed to prevent this kind of mis-parsing, but I think the regex would be more defensive coding-like

Done

My bad, fixed it

technically it only updates the filteredclientlist, but the change is "propagated" to the sortedfilteredclientlist, so I'm not sure which would be clearer. I'm thinking since it operates on the filteredclientlist only, the name should be left as is.

Done, abstracted into a private static method in the same class

Updated

done

imo I don't think there's a point in extracting it out as an empty string is kinda like a null value, and we don't extract out null values.

This one is being used to display country notes if we're looking at one country only, so I just left it as countryNoteListView

done

removed

have forced to it order based on note contetns

I think the tags are hard to compare (the overhead/extra code will be quite bad and messy), and its unlikely that all country code and note content will be equal but tags different, so I'll just leave it as this for now.

All the other command classes don't have the hashcode function, so I deleted this one to standardize

Yup, this check is needed since the very first time the WidgetViewBox is initialized, the textClock is null, and we call this function

done

ok sure changed

done

Bugfix for when country note view is called followed by client list, which doesn't reset the widget display viewbox back to default, even though it should.

done

I think the reason its called isExit is because the commandresult itself is an exit command. Aka there is only one such command that causes the app to exit. Also, the "Returns true if CommandResult will cause the application to exit" would be less accurate because the commandresult doesn't cause the application to exit, it just carries the message that the application should exit to the mainwindow class, which then implements the exit

It should be in the plural because we can have multiple suggestion types being passed in in the form of an ordered set

good catch, ill change the rest of the parsers as well

LGTM

Fixed by #121 #142 #144

Fixed by #120

Duplicate of #92

Duplicate of #90

Removed from plans

Quite a few TODOs and stray comments. I think a follow-up issue can be created to cleanup the todos and stray comments.

Just wondering, what is the main purpose of having TagNoteMap class? Is it so that it would be easier to query for notes based on a given set of Tags? Because it seems like additional work to "sync" tags with notes and it might be quite error-prone if the syncing is not done right. Any thoughts @qwoprocks ?

@raysonkoh actually the implementation @rtshkmr did was a bit off from what I had in mind, the tagnotemap is actually supposed to be the one being passed down from logic manager to the parser to create the tags, so there would no need to do the syncing stuff. @rtshkmr isit alright if i just push to this PR and implement that?

1. Cannot uniquely identify `clients` by their name at the moment.

Possible fix: store the client as a string containing ">client name> >client email>", as we can use isSameClient method of Client to match the clients and notes.

Is the testing for ContractExpiryField class supposed to be done in another PR?

Ah right I forgot lmao I'll add it in now

Duplicate of #162

Looks good. There's still a slight aesthetic issue where the list cell is not contained within the list view rounded container, but this is pretty trivial.

good catch, I'll add it as an issue

Realized that it probably wouldn't make a difference, and might flood the javafx thread with pending runnables.

Manually tested country note add and country note delete, seems to be working as expected. So just to check, a country note will first be sorted by country code, then insertion order right?

@raysonkoh yup correct

Not going to do this for v1.4, may consider as further extension.

Fixed by #317

Moved to v1.5 because this might introduce bugs and our current implementation is good enough for now

Redo-ing the implementation

I think we can remove this test case.


        // Keywords match phone and email, but does not match name

Should remove INVALID_ADDRESS and VALID_ADDRESS from constant declarations above as well.

Is there a particular reason as to why this test case was removed? Perhaps we can use a different invalid value instead of removing the entire test case.

Should probably remove the above


@FXML 

private Label address;

as well.


platform for tutors to handle all of their administrative matters.


- Tutor's Pet displays your upcoming lessons so that you will never forget about them again.

Not sure if this would sound more in line with the other points since the word 'your' was used in both the other.


- Tutor's Pet allows you to mark your students' attendance and participation for each lesson.

Nice catch!


    public static final String MESSAGE_SUCCESS = "Listed all students.";

Perhaps we can update the Tag examples to something that's more student-tutor relationship like. Maybe something like how the student is performing in class.

This line shouldn't change.

Similar here, would be good to update the example tags.

Would be good to update this test constant as well.

Command word should be in kebab case.

Command word should be in kebab case. Perhaps can change the title to "Listing all students within a class".

We should retain the generated table of contents instead of using simple bullet points.

I think the second add is redundant.

Ellipsis should remain outside of the square brackets since users need to repeat the prefix as well.

I don't think we are supporting the separation of CLASS_NAME from MODULE_CODE?

Need to remove the address field in this section as well and update the tag prefix.

Need to update tag prefix here as well.

I don't think name, telegram handle and email are optional fields.

We need to rethink the command syntax for this operation. The parsing of arguments will be troublesome in this format.

For now maybe we can leave this feature out of the UG.

Kind of weird I'm a Project Advisor in the project I'm working on. Maybe Lead Developer would make more sense, but I'll change that in my own AboutUs update later.


   * **`add`**`n/John Doe t/@johndoe e/johnd@example.com tag/student` : Adds a student named `John Doe` to the application.

The second example should include more than one tag to show the possible multiplicities.


  e.g. `[tag/TAG]…` can be used as ` ` (i.e. 0 times), `tag/student`, `tag/Average tag/TA Candidate` etc.


Format: `add n/NAME t/TELEGRAM_HANDLE e/EMAIL [tag/TAG]…`


Format: `edit INDEX [n/NAME] [t/TELEGRAM_HANDLE] [e/EMAIL] [tag/TAG]…`

Not sure if this is the best implementation since the /by prefix will have no values associated with it when parsed by the ArgumentTokenizer


* `list-students c/CS2103T Tutorial T10`


**Add Student** | `add n/NAME t/TELEGRAM_HANDLE e/EMAIL [tag/TAG]…` <br> e.g., `add n/John Doe t/@johndoe e/johnd@example.com tag/student`


**Edit Student** | `edit INDEX [n/NAME] [t/TELEGRAM_HANDLE] [e/EMAIL] [tag/TAG]…`<br> e.g.,`edit 2 n/James Lee e/jameslee@example.com`


**List Students in a Class** | `list-students c/CLASS_NAME`<br> e.g., `list-students c/CS2103T Tutorial T10`


| `* * *` | Tutor with many students | Store my students' contact info/emails | Contact them easily |


Links an existing student to an existing class in the application.


* `list` followed by `link s/1 c/2` links the 1st student in the application to the 2nd class in the application.

* `find Betsy` followed by `link s/1 c/2` links the 1st student in the results of the `find` command to the 2nd class in the application.


#### Linking a student to a class: `link`

Should we update the rest of the use cases to use full stops as well?

Hmm, I think summary should remain after the detailed explanation, since it serves so summarise the above mentioned information.

In and A shouldn't be capitalised in the title.

I think we should retain the present participle form of the verb? The CS2101 set of slides for "Writing User Guide" also seems to favour retaining the present participle form of verbs, although it does not seem explicitly mentioned.


* 3a. No students found.

Would be good to mention that it is a message, otherwise might be confusing how to show an absence of something.

Should we keep it consistent and use delete instead of clear?

Technically Tutor's Pet can return more than one student found, so maybe it would be good to mention that it shows all matching students.

Applies to finding classes as well.


## Command overview


#### Clearing all students : `clear-student`


#### Clearing all classes : `clear-class`


| UC13        | Link a student to a class        |

| UC14        | Unlink a student from a class    |


**Use case: UC14 - Unlink a student from a class**


**Use case: UC13 - Link a student to a class**


| UC12        | Clear all classes                |

| UC13        | Link a student to a class.       |

| UC14        | Unlink a student from a class    |


        assertParseFailure(parser, NAME_DESC_BOB + VALID_PHONE_BOB + EMAIL_DESC_BOB,


        assertParseFailure(parser, VALID_NAME_BOB + PHONE_DESC_BOB + EMAIL_DESC_BOB,


        assertParseFailure(parser, NAME_DESC_BOB + PHONE_DESC_BOB + VALID_EMAIL_BOB,


    public static final String MESSAGE_SUCCESS = "All students in Tutor's Pet have been cleared!";

Perhaps we can rename this to getAddStudentCommand(Student student)


    public void parseCommand_editStudent() throws Exception {


    public void parseCommand_deleteStudent() throws Exception {


    public void parseCommand_addStudent() throws Exception {


    public void parseCommand_clearStudent() throws Exception {


    public void parseCommand_findStudent() throws Exception {


    public void parse_validArgs_returnsFindStudentCommand() {


    public void parse_validArgs_returnsDeleteStudentCommand() {

I don't think we should allow the explicit setting or getting of UUID in EditStudentDescriptor since it would then no longer be editing the same student.

The editedUuid should always be that of the studentToEdit.

I think it would be good to set a default UUID for each student in the tests and not rely on randomly generated data. This way it would be more predictable and testable.

I don't think there is a need for EditStudentDescriptor to have a uuid field.


        requireAllNonNull(uuid, name, phone, email, tags);

It would be good to edit the constructors in the TypicalStudents file as well to ensure the test constants are truly identical.


    private static ModuleClass createEditedModuleClass(ModuleClass moduleClassToEdit,

            EditModuleClassDescriptor editModuleClassDescriptor) {


 * Parses input arguments and create a new EditModuleClassCommand object.


     * Parses {@code userInput} into a {@code StudentNameContainsKeywordsPredicate}.

There's quite a bit of overlap here, would be good to deduplicate into:


    public static final Index INDEX_FIRST_ITEM= Index.fromOneBased(1);

    public static final Index INDEX_SECOND_ITEM = Index.fromOneBased(2);

    public static final Index INDEX_THIRD_ITEM = Index.fromOneBased(3);


 * A utility class for ModuleClass.

Seeing this template always makes me feel like they have already foreshadowed that we should do undo/redo features.


 * Contains integration tests (interaction with the Model) and unit tests for


 * A UI component that displays information of a {@code ModuleClass}.

Since we seem to be standardising to capitalise UI.


    // Independent UI parts residing in this UI container

It should be A UI because in both user interface and UI the word/abbreviation is pronounced as though it starts with the consonant y.


 * A UI component that displays information of a {@code Student}.


    -fx-background-color: transparent, #274156, transparent, #274156;

I think it would be best to define the return type as Label since we do in fact return a Label.


     * Converts this Jackson-friendly adapted class object into the model's {@code ModuleClass} object.


     * Converts a given {@code UUID} into this class for Jackson use.


     * Converts this Jackson-friendly adapted UUID object into the model's {@code UUID} object.


     * @throws IllegalValueException if adapted UUID is null.

I think it would be a good idea to introduce some checks for invalid UUIDs since the user can go into the json file to edit entries manually.

I would agree with @junlong4321 on this, it would be good to isolate any possible failure to just students.

While in invalidClassTutorsPet.json, students would be useful in the future when we implement validation for students who are registered in classes.

I agree with @ruixuantan. It would be safer since users can head into the json save file and modify its contents manually.

I think if we are fine with breaking the abstraction barrier, in some sense we already have since we are dealing with UUID objects instead of strings, then it is okay to change all references to studentUuids instead, including in the model.

Naming here might be a bit confusing since uuid is a object type itself.


    private final String uuidString;


     * Constructs a {@code JsonAdaptedModuleClass} with the given class details.


     * Converts a given {@code ModuleClass} into a {@code JsonAdaptedModuleClass} for Jackson use.


     * @throws IllegalValueException if there were any data constraints violated in the adapted class.


     * Creates a {@code ModuleClassBuilder} with the default {@code Name} and empty {@code studentUuids} list.


    public static final UUID ALICE_UUID = ALICE.getUuid();

    public static final UUID BENSON_UUID = BENSON.getUuid();

Can these two methods be made private?

I would advise against adding the class names as Tags since it might confuse our first time users into thinking that linking students to classes would automatically add the classes as Tags.

Perhaps it would be a better idea to declare the students and classes as static members and then have the two methods return a list of the static members.

Also, I think the two getter methods can be made private.


        // different keyword -&gt; returns false


     *

     * @throws ParseException if the user input does not conform the expected format.

NIT: It might be a good idea to leave a class or two for manual adding when testing.

nit


        FindModuleClassCommand expectedFindModuleClassCommand =

                new FindModuleClassCommand(new NameContainsKeywordsPredicate<>(Arrays.asList("CS1101S", "Tutorial")));



        // no leading and trailing whitespaces

        assertParseSuccess(parser, "CS1101S Tutorial", expectedFindModuleClassCommand);


     * Additionally, removes all {@code Student UUID}s in each {@code ModuleClass}.


    /**

     * Removes all {@code Student}s from the student manager.

     * Also removes all {@code Student UUID}s from each {@code ModuleClass}.

     */

Perhaps it might be a good idea to have the same name for both methods (in Model and in TutorsPet)?

Perhaps {@code Student UUID}s would be more accurate since {@code studentUuids} refers to the list itself rather than its contents.


    /**

     * Removes all {@code Student UUID}s from every {@code ModuleClass} in the class list.

     */

Is there any particular reason why we choose ClearModuleClassCommand as the different type as opposed to some other primitive type like an integer?




        model.deleteAllModuleClasses();


    private static final int NUMBER_OF_COLOURS = COLOURS.length;

Should we be using the American spelling of Colour instead?

I think we should retain the name listOfTags or tagList instead? Although the field was declared as static final, it is not exactly a constant in essence since the contents of the list can change.

I think it would be wise to follow the following categorisation of constants as given by the excerpt below from the Google Style Guide.


        requireNonNull(toCheck);



        return internalList.stream().anyMatch(toCheck::hasSameUuid);


        requireNonNull(student);



        return students.containsUuid(student);

Instead of reading students once again, perhaps we may want to use the existing information stored within tutorsPet instead?

We can also document this precondition in the JavaDoc to state that the tutorsPet passed in should have its students loaded prior.

Just wondering, is this "feature" extended to the native UUID stored in each JsonAdaptedStudent as well?


     * If Tutor's Pet encounters duplicate {@code Student UUID}s in a class, it will not load

     * duplicate {@code UUID}s into the model. Hence, Tutor's Pet should still boot up successfully.


     * Ensures that Tutor's Pet will not be able to boot up given an incomplete {@code UUID}.


     * Ensures that Tutor's Pet will not be able to boot up although Java tries

     * to pad missing {@code UUID} digits in broken {@code UUID}s with zeros.


     * Prevents Tutor's Pet from booting up if two or more {@code Student}s are found with the same {@code UUID}.

            "Invalid student(s) found in class(es).";

In view of the change, I would recommend changing the test case to remove a student that was not previously part of any class. This way, we would only be changing the student list and would be a better representation of the test case.

I'm slightly intrigued as to why 50?

Will we be supporting hyperlinks as venues given the current situation?

Perhaps it might better for these methods to take in LocalTime objects instead to remove any chances that a parse error is thrown.

Perhaps it would be good to test the equals method as well?

Same for the NumberOfOccurrences class.

Perhaps something along the lines of Add an attendance record of a student would be better? Similarly for the rest below?


Tutor’s Pet is a desktop application that helps Computer Science teaching assistants reduce the amount of time they spend on administrative tasks.

Or alternatively, perhaps this sentence can be written in a more user centric manner?

Perhaps it would be easier to support 24 hour time format (0800, 1000 etc.) first before thinking if we want to support other time formats?

command may not be the best word to use here since they do not see all commands executed, i.e. they only see commands that can be undone/redone. I suggest an alternative here, although I think it definitely can be further improved.


### View action history : `view-history`



View a list of actions that can be undone or redone.

The week seems to be missing from the description, same for the subsequent attendance record commands.

Agreed

The phrasing of this sentence is rather weird, especially the add students into those classes part. I have an alternative below, but open to better phrasing as well.

'''suggestion

It allows teaching assistants to keep track of the students in their classes, and record their attendance and participation scores.'''

*  `edit-attendance c/1 l/1 s/1 w/1 p/10` Edits the 1st week's participation score of the 1st student of the 1st lesson of the 1st class to 10 points.

| **View Action History**           | `view-history`                                                                                                                                                            |

I don't think week 0 is officially supported.


* The `WEEK` **must be a positive whole number** 1, 2, 3, …


* The `WEEK` **must be a positive whole number** 1, 2, 3, …


* The `WEEK` must be a positive whole number** 1, 2, 3, …

* The participation score **must be a non-negative whole number** 0, 1, 2, …


* User has to specify at least 1 field (DAY/START_TIME/END_TIME/VENUE) to be changed.

Just noticed this, but perhaps this should be use case ends since it has been deemed that the lesson already exists?


      Use case ends.

Seems like this was inherited from previous versions.


1.  User requests to delete a specific attendance record.

Since the command expects multiple correct indexes, would it be more appropriate to phrase it as One or more of the given indexes are invalid.?

That's true, I think we can keep the current version.

I think it would be best for these to be left to be handled by the logic part of the house for consistency with the rest of the model components. It would be sufficient to provide getter methods and a suitable constructor.

Similarly, these methods should be reserved for the commands in logic to handle to better decouple the model from the controller/logic.

Instead of introducing this method within the model, perhaps it would be better for the methods that require a zero based number to use the currently available Index object and retrieve a getOneBased() value instead?

That is, the method that does the comparison should be the one performing the conversion from a zero based index to a one based index for comparison with the Week value.

Perhaps we should take in Index instead of int for week associated values (at least for this class since it sort of acts like an index to a list) so that there is less room for mistakes of getting the base wrong in the future?

Or since the Week class seems to be unused, perhaps the Week class can be used to store a valid (i.e. within 1 and 52 when counted from base 1)Index object. And the Week object can be used as the definitive way to check for validity and retrieve AttendanceRecord objects from the appropriate week/index.


     * Inserts a new {@code UUID} and {@code Attendance} into the {@code AttendanceRecord} we are building.

This class seems unused, but perhaps we can convert it to store an Index while performing validation on the Index value.

This way, we can ensure that there will be no ambiguity when parsing, transferring or retrieving values based on weeks.


     * Returns true if the given week is an integer between {@link NumberOfOccurrences.LOWER_BOUND}

     * and {@link NumberOfOccurrences.UPPER_BOUND}.


 * Guarantees: immutable.


     * Returns the {@code Attendance} of the given {@code Student UUID}.


 * Guarantees: immutable.

This shouldn't be necessary anymore right?


     * Returns the {@code Attendance} of a {@code Student} in a particular {@code Week}.


     * Returns the {@code AttendanceRecord} of a particular {@code Week}.

The changes might cascade into the other tests as well.


    public static final int VALID_WEEK_VALUE_5 = 5;

    public static final int VALID_PARTICIPATION_SCORE_33 = 33;

    public static final int VALID_PARTICIPATION_SCORE_51 = 51;

    public static final int VALID_PARTICIPATION_SCORE_80 = 80;


        // invalid score

        assertFalse(Attendance.isValidParticipationScore(Attendance.LOWER_BOUND - 1));

        assertFalse(Attendance.isValidParticipationScore(Attendance.UPPER_BOUND + 1));

        assertFalse(Attendance.isValidParticipationScore(-1));



        // valid score

        assertTrue(Attendance.isValidParticipationScore(Attendance.LOWER_BOUND));

        assertTrue(Attendance.isValidParticipationScore(Attendance.UPPER_BOUND));

        assertTrue(Attendance.isValidParticipationScore(10));


        Index invalidWeek = Index.fromOneBased(Week.UPPER_BOUND + 1);


            if (!lesson.equals(lessonToDelete)) {


    public static final Prefix PREFIX_START_TIME = new Prefix("st/");

Perhaps this might allow more versatility for this method? Or alternatively it could be mentioned in the method description that it will always assume a class index of one.


    public static String getAddLessonCommand(Index moduleClassIndex, Lesson lesson) {

        return AddLessonCommand.COMMAND_WORD + " "

                + PREFIX_CLASS_INDEX + moduleClassIndex.getOneBased() + " "

                + getLessonDetails(lesson);

    }

Not too sure about this, but "Days" sound slightly better? Or perhaps can consider using "The day...", but it might not sit too well with the other constraint messages.


    public static final String MESSAGE_CONSTRAINTS = "Days must be typed out fully in capital letters.\n"


     * The {@code String} must be capitalized and be spelt exactly as each enum value.

     *

     * @throws InvalidDayException if the {@code String} does not match any of the enum values.

Perhaps we can simplify this method to:


    private boolean hasDuplicateLessons(List<Lesson> lessons, Lesson lessonToCheck) {

        return lessons.stream().anyMatch(lessonToCheck::isSameLesson);

    }


     * Converts the contained {@code List<JsonAdaptedUuid> studentUuids} to a {@code List<UUID>}.


     * Converts the contained {@code List<JsonAdaptedLesson> lessons} to a {@code List<Lesson>}.


        List<UUID> studentUuids = getUuidList();

        final Set<UUID> studentUuidSet = new HashSet<>(studentUuids);


        return new ModuleClass(modelName, studentUuidSet, lessonList);

Could we split this into a separate test case since we are testing for a failure here?

Would be good to update the JavaDocs with the appropriate details.

Could we test for a null lesson as well? Perhaps in another file nullLessonTutorsPet.json and this file can be renamed nullStudentUuidsTutorsPet.json.

Could we test both versions of JsonAdaptedLesson creation? That is have another test case that creates the JsonAdaptedLesson solely using the individual details of the Lesson rather than the object itself.

Nice thanks!

We need to perform some checks to ensure that the student is a member of the moduleClass as well.

This seems to appear quite a few times around the code base, could this be placed into another class, perhaps the ParserUtil, or any other suitable class and the rest can reference this public method instead.

Could we include a test for a null Week as well?

It seems like the expected vs actual fields are swapped? It might be good to also declare the parser version as the command and the AddAttendanceCommand version as expectedCommand?

Perhaps we should have a test for the case where the student is not a member of the class?

I think typically there are spaces both before and after the : in enhanced for loops?


    public static final String MESSAGE_MISSING_STUDENT_ATTENDANCE = "Student's attendance does not exist";

Nice check

Just noticed this, but could have probably used .getOneBased() > lastShownStudentList.size() to drop the equality sign. Not important though.

For some of the tests here, it might be good to add simple assert statements to make sure that certain assumptions about the model are true. For example the studentNotInClass, execute_success, noStudentAttendance tests rely on the fact that the TypicalTutorsPet provided meet certain criteria.

Should we check if the attendance we want to delete exists in the first place?

It might be a good idea to display an error message instead of showing a success message if the attendance did not exist.

In AddAttendanceCommand, parseWeek seems to throw the Week constraint message instead of the usage message when it fails. Perhaps we should keep it consistent.

I think this appeared in AddAttendanceCommandTest previously. Instead of duplicating it, perhaps we can make it public in the other class for others to use. It can also be moved to another more suitable location, especially as it seems like these helper methods are becoming more common.


            + "Note: All indexes must be positive integers.\n"

[Redacted: non-issue]


            + PREFIX_WEEK + "WEEK_NUMBER (must be a positive integer)\n"

I think it would be good to state the main purpose of the method first before providing additional details.


     * Adds {@code attendanceToAdd} to {@code targetLesson}.

     * All existing {@code Attendance}s in {@code targetLesson} are copied to the new {@code Lesson}.


     * @throws CommandException if an {@code Attendance} already exists for the {@code targetStudent} in the {@code targetWeek}.


     * @throws CommandException if the {@code Attendance} of the {@code targetStudent} in the {@code targetWeek} does not exist.


     * Removes the {@code Attendance} of the {@code targetStudent} in the {@code targetWeek} from the {@code targetLesson}.

     * All other existing {@code Attendance}s in {@code targetLesson} are copied to the new {@code Lesson}.

Perhaps we should first check that the student is a member of this class before proceeding further?

Nice job extracting these methods to a separate class.

Since they are public methods now, perhaps we should have unit tests for them? It can come in a separate PR subsequently though.




        // delete week 1 attendance record

        Map<UUID, Attendance> record = lesson.getAttendanceRecordList()

                .getAttendanceRecord(targetWeek).getAttendanceRecord();

        Map<UUID, Attendance> updatedRecord = new HashMap<>(record);




        Lesson modifiedLesson = new LessonBuilder(lesson)




        // delete non-existent week 5 attendance record

        Map<UUID, Attendance> record = lesson.getAttendanceRecordList()

                .getAttendanceRecord(targetWeek).getAttendanceRecord();

        Map<UUID, Attendance> updatedRecord = new HashMap<>(record);




        Lesson modifiedLesson = new LessonBuilder(lesson)


     * Adds {@code lessonToAdd} to {@code moduleClassToAddTo}.

     * All existing {@code Lesson}s in {@code moduleClassToAddTo} are copied to the new {@code ModuleClass}.

Perhaps we should also change moduleClassToAddTo to targetModuleClass for consistency?


     * Replaces the {@code lessonToEdit} with {@code editedLesson} in {@code targetModuleClass}.

     * All other existing {@code Lesson}s in {@code targetModuleClass} are copied to the new {@code ModuleClass}.


     * Removes the {@code lessonToDelete} from the {@code targetModuleClass}.

     * All other existing {@code Lesson}s in the {@code targetModuleClass} are copied to the new {@code ModuleClass}.

Can I check how does this defer in purpose from createModifiedModuleClassWithEditedLesson?

Perhaps we can follow the existing statements and use a single statement that all indexes must be positive integers.

        boolean isStudentIndexPresent = argMultimap.getValue(PREFIX_STUDENT_INDEX).isPresent();
        boolean isWeekPresent = argMultimap.getValue(PREFIX_WEEK).isPresent();
        if (!isModuleClassIndexPresent || !isLessonIndexPresent || !isStudentIndexPresent || !isWeekPresent) {


        boolean isModuleClassIndexPresent = argMultimap.getValue(PREFIX_CLASS_INDEX).isPresent();

        boolean isLessonIndexPresent = argMultimap.getValue(PREFIX_LESSON_INDEX).isPresent();

        boolean isStudentIndexPresent = argMultimap.getValue(PREFIX_STUDENT_INDEX).isPresent();

        boolean isWeekPresent = argMultimap.getValue(PREFIX_WEEK).isPresent();



        if (!isModuleClassIndexPresent || !isLessonIndexPresent || !isStudentIndexPresent || !isWeekPresent) {

@junlong4321 Actually, for such a case where the Boolean variables are only used in the guard clause, shouldn't they be part of the block for the guard clause?

There seems to be one more occurrence at line 37 in this file.

Should this and the following points be relocated to the Using Tutor's Pet section?

Should this be Classes and Students instead since the application uses those words instead?


 students in Tutor's Pet, make use of the **`list-student`** command.


Gives you an overall summary of a student's attendance and participation scores.

Perhaps a more user-centric phrasing can be used here?


    ![Delete lesson after](images/ugimages/DeleteLessonAfter.png)


A `UUID` is a unique 128-bit number to identify a unique `Student` within Tutor’s Pet.


`Student` `UUID` will help to ensure referential integrity of `Student` data across different models when

`Student` data is modified by the user.

Maybe you could mention that another con is the very low, but still present, risk of a collision when generating random UUIDs.


  * Cons: The `Email` field is editable while the unique identifier of each `Student` should not be editable to prevent the need to cascade a change in the identifier of the `Student`.

I think we should include style.puml across all our diagrams to ensure consistency?

Based on the textbook, there seems to be a colon before the class name even for calls to static methods.

participant "<<Class>>\n:ModuleClassUtil" as ModuleClassUtil LOGIC_COLOR
participant ":ModuleClass" as ModuleClass LOGIC_COLOR
participant "<<Class>>\n:LessonUtil" as LessonUtil LOGIC_COLOR
participant ":Lesson" as Lesson LOGIC_COLOR
participant "<<Class>>\n:AttendanceRecordListUtil" as AttendanceRecordListUtil LOGIC_COLOR

Perhaps this line isn't necessary since the association has been represented as a field already? I'm not too sure on how maps should be represented as well. We should probably check with Prof Damith for clarification.

It contains the `Attendance`s of all `Students` who have attended the particular lesson.

Or perhaps we can rephrase the sentence since the above does not get rendered as nicely?

Hmm I'm not sure if we should have the colon here?


If you would like to add a lesson to a class, you can make use of this command.


* You receive news that you will be teaching `CS2103T Tutorial` on `Tuesday 10:00-11:00` at `COM2 #02-02` from week 1 to 13. Hence,


* You have one less lesson to teach now.


If you would like to delete a specific student's attendance from a lesson, you can make use of this command.


* Alice's attendance for week 1 has been deleted.


* You would like to delete Alice's attendance for the Thursday 10.00am to 11.00am lesson of CS2103T Tutorial in Week 1.

Hence, you type in the command `delete-attendance c\1 l\1 s\1 w\1` and press <kbd>Enter</kbd>.

I think every command should be part of a sub category of features?


#### Display Statistics : `stats`

Would it be possible to move private methods to the bottom of the class so that it can be grouped with the rest of the private methods?


    /**

     * Returns an {@code AttendanceRecord} where the {@code Attendance} of the {@code studentToRemove} has been removed.

     * If the {@code studentToRemove} does not exist in the {@code attendanceRecord}, the {@code attendanceRecord} is returned unchanged.

     */

    private static AttendanceRecord removeStudentFromAttendanceRecord(


    /**

     * Returns an {@code AttendanceRecordList} where the {@code Attendance}s of the {@code studentToRemove} have been removed.

     */

I think this line can be simplified?


            tp.addModuleClass(moduleClass);

Same as above,


            tp.addModuleClass(moduleClass);

Perhaps we could shift the responsibility of removing the student from module class to the command instead. Since there is currently no existing dependency from model to logic, it might be best to keep it that way to remove this cyclic dependency between the packages?

One suggestion would be for the delete and clear student commands,we can retrieve the ReadOnlyTutorsPet from the model and perform the mapping function there, and then set the new TutorsPet back into the model.

@ruixuantan do you have any suggestions on how this cyclic dependency can be resolved?


    /**

     * Returns a {@code Lesson} where the {@code Attendance}s of the {@code studentToRemove} has been removed.

     */


     * Returns an {@code AttendanceRecordList} where the {@code Attendance}s of all {@code Student}s have been removed.


     * Removes the {@code studentToRemove} and all associated {@code Attendance}s from the {@code targetModuleClass}.


     * If the {@code studentToRemove} does not exist in the {@code attendanceRecord}, the {@code attendanceRecord}

     * remains unchanged.


    public void removeStudent(Student student) {


    public void removeAllStudents() {

I think I spotted a typo in the other Cards as well, could you help to change them as well?


     * Creates a {@code LessonCard} with the given {@code lesson} and index to display.

Perhaps applyStylesheet() or something along those lines would be better since we are not toggling between states?

Same for the 3 methods below, maybe apply would be a better word?

If you would like to see a list of all classes in your Tutor's Pet, make use of this command.

I think typo already suggests that its an error?

  However, you made a typo and gave him 35 instead.

Alternatively maybe we can drop the typo word?

  However, you accidentally gave him a score of 35 instead.

I don't think multiplicities are required in this diagram since it does not really add any value?

I don't think these components are in a package?

Is there an alternative that you missed out?


#### Design Considerations

Should we put the status as the last column instead?

I think Name and Tag do not reside in the Student package?

Is there a particular reason why this differs from the Student diagram?

Also, I think it is not part of the ModuleClass package?

Perhaps it would make more sense to ensure that they do not map to each other's value than that they map to a specific value?


* `DisplayStatisticsCommand#execute()`: Performs a validity check and returns a specific student's statistics if all


* `AddAttendanceCommand#execute()`: Perform a validity check and adds a student's attendance for a particular week's lesson if


### Deleting a lesson



1. Deleting a lesson

Not sure if this section should be labeled Clearing classes in Tutor's Pet? Or if we plan to have all the clear and reset features in this section then I think its fine to retain the section name.

Should this be separated into two sections?

Otherwise its a little weird why finding student is not planned to be part of the list...

If the intention is to have find student as part of this section as well, perhaps you can put it in the header and have a placeholder somewhere later in the body.

Should editing come before the display functions?

Perhaps it would be good to link with abstraction as the link may not be very obvious.

I think for sequence diagrams it might be better to leave the arguments in since the original example from AB-3 had them.

Should this be mentioned in edit lesson as well?

I don't think the (PPP) part is necessary?

It might be weird to have both bullet points and numbering together?

Is this supposed to be after?


   ![Edit class after](images/ugimages/EditClassAfter.png)


   ![Edit class before](images/ugimages/EditClassBefore.png)

This step is a little long, perhaps we can put the You type... into a separate step on its own? Maybe something like this?


1. Your module coordinator decides to allocate another class to you and you want to be able to distinguish between

   the two classes. Hence you decide to edit the `CS2103T Tutorial` class to `CS2103T Tutorial T10`. 



1. Type the command `edit-class 1 n\CS2103T Tutorial T10` and press <kbd>Enter</kbd>.

Are there any terms we plan on putting in the glossary?

Perhaps in would make it more obvious if it is inclusive or not.


    For example, if a semester has 13 weeks and your lessons begin in week 3 and end in week 13,

Nice, I like this method of resolving the check issue. @junlong4321 perhaps you can use this for the edit-student issue as well.

@ypinhsuan Would it be possible to overload the method instead of taking null for the second argument when it is an add operation?

We can't use lastShownList because it does not contain all students in Tutor's Pet. The model has to handle this check.


| **List all students and classes** | `list`                                                                                      |                                                                    |


1. You type the command `edit-lesson c\1 l\1 d\Tuesday` and press <kbd>Enter</kbd>.


1. You type `find-student roy` and press <kbd>Enter</kbd>.


1. You type `edit-student 3 e\charlotteolive@example.com` and press <kbd>Enter</kbd>.

I think most of existing instructions do not include a fullstop here?


1. Finding a student


1. Editing a student


1. Deleting a student while all students are being shown


1. Adding a student


      (where `x` is larger than the size of class list)<br>

Agree with the annotations, but I think it is okay to dedicate a separate PR for that also.

Not sure if we should be including the reference to LumiNUS, perhaps it should be included in the glossary then?


1. It is the end of the semester and you wish to key in your students' attendance into LumiNUS. You enter the


1. The change resulting from the command's execution is saved using the `commit(...)` method for the `undo`/`redo` feature.


1. A new instance of an `AddAttendanceCommand` object would be created by the `AddAttendanceCommandParser` and returned

It's better to play safe and include it since we did also include Telegram in the glossary.

TIL, didn't know that.

Quite interesting explanation here also: English StackExchange

The JavaDoc was adapted from an equivalent JavaDoc in UniqueStudentList.

I would be more inclined to retain both in their current expressions.

This JavaDoc was directly adapted from a corresponding JavaDoc in the existing UniqueStudentList class as well. As such, I would be more inclined to retain the current expression since it is consistent with existing code.

The backing list refers to the internalList while unmodifiable means that any attempted modifications on the list would result in an UnsupportedOperationException being thrown.


        // workaround as storage functionality for ModuleClasses has not been implemented


        // workaround as storage functionality for ModuleClasses has not been implemented

Agree with @junlong4321 for consistency.

This JavaDoc was directly adapted from a corresponding JavaDoc in the existing UniqueStudentList class, so I would be more inclined to retain the current expression since it is consistent with existing code.

As these informal list points are not complete sentences and are fragments, I would be more inclined to leave the full stop out?

Oops, that slipped through my manual search and replace.

I think for this case, it would be okay to not include an empty line above the comment since it is the first line in the method body. It will also be more in line with existing code.

Good idea, added in!

Resolved instead by changing to lowercase throughout, more in line with comments found above.

Because of the need to include the CURRENT_INDICATOR for a particular entry, which is rather specific to ViewHistoryCommand, the method in StringUtil would be oddly specialised for a method in the commons package.

Instead, I think I would abstract out the creation of the message to a helper function that resides within the ViewHistoryCommand class.

I've included this spacing to separate code used to set up the environment (above) from the code that is being tested (below).

The cache is used in the following scenario:

The user has some previous commands already saved in the history.
The user partially types a command string, but decides to refer to a previous command.
The user recalls the previous command for reference but wants to return to the partially typed command.
The user can retrieve his partially typed command string from the cache.

I've also included some logging functionality at the info and fine levels.

Hmm I wanted to differentiate this constructor from the previous as this constructor is typically not meant to be used to create new lessons, but rather act as a "copy" constructor with modifications. Would it be better to leave it as is, add the word "new", or "Creates a copy of a lesson with the specified parameters."?

I did consider the direct de/serialisation of key-value pairs using the Jackson, however I was rather hesitant to use it as I was unsure how it would play with the current implementation of JsonUtil. Similarly, the StudentAttendance implementation was used to avoid the need to complicate the deserialisation of key-value pairs.

I do agree with you that the direct serialisation would be more intuitive and provide a one to one mapping with the actual classes in the model.

I'll be inserting another diagram over there (around line 280) to explain the case when the current value is cached in a subsequent PR. So I think I'll leave the summary at the end for now.

I've linked it to the implementation section instead.

@ruixuantan Would it be possible for you to invert the direction of the diagram of the Attendance model? It's kinda weird since its the only class diagram where the hierarchy is going from bottom up.

I did consider changing the bullet points to numbered steps, however I decided against it since its the mock PE tomorrow and its unlikely that everyone will be able to standardise it by then.

I took a look at some of the examples that Diana gave, and it seems that Title Case is used for all headings except those that are related to commands. As such for our user guide, I've standardised it to use Title Case for all heading levels 3 and above, while Sentence case is used for all heading levels 4 and below.

Can you rebase and then should be good to go.

Not sure if we need to get approval before we merge this in since we are trying to use a new module?

This seems to be missing the saving of UUIDs to local storage, is that planned for a separate PR?

Closed with #61.

Closed with #62.

Resolved in #68.

Closed with #55.

@ruixuantan could I also get your opinion on the test cases written for the new features?

Closed in #131

@ruixuantan This PR only adds unit tests for LessonUtil since they were updated. I'll leave #158 open until unit tests have been added for ModuleClassUtil.

Non-issue since users can use stats to see if a week has an attendance record and use find attendance to view the specifics.

Probably won't fix due to time constraint.

For future reference, LumiNUS uses the term Class Groups.

Issue remains unresolved.

Example: Add and edit commands tend to be similar and can be condensed further.

Not a bug, intended behaviour. Student David Li is not part of CS2103T Tutorial in sample data while Alex Yeoh is.

Error message clearly states so.

Not a bug, intended behaviour. Lessons should not be overnight anyways.

Might want to include this constraint in the documentation?

Bug inherited from AB-3.

Perhaps will not fix or put in place regex limitation?

Duplicate of #232

Duplicate of #233

Not a bug, intended behaviour.

Perhaps list-student with class parameter should filter the class list as well.

Duplicate of #238

Inherited from AB-3.

Duplicate of #226

Somewhat a duplicate of #226.

Will be fixed with that.

Bug inherited from AB-3.

Likely won't fix since we cannot throw multiple exceptions.

Will be fixed with #226.

This likely won't be fixed on its own since there will no longer be any ambiguity.

Duplicate of #232

Not a bug, intended behaviour.

Perhaps we can change week to occurrence for less confusion?

Not a bug... It's sample data for a reason...

Unable to reproduce.

Will not include Student and Utility as no description/alternative explanation that adds value could be found.

Do change the USERGUIDE_URL in HelpWindow.java as well!

Switch to use logger

Switch to use logger, same for other 2 instances below

Switch to use logger

Remove

"Clears the item list"?

Would it be better to default quantity to 0 and description/location to none if user doesn't key them in? Currently they act as compulsory fields.

Javadocs

Extra lines

change address-book

Javadocs

change comment title

person -> item

Should these be locationIds and recipeIds?

Should these method names be getLocationIds and getRecipeIds?

use this format instead, replace with the fields we have

plural forms

extra lines

address book -> item list?

Javadocs

Make this comment appropriate pls 😃

Javadocs

the right side has less equal signs 😦

change address book to item list or something similar

same for this segment

change logger message

itemToAdd might be better

extra lines

item -> item and location

person -> item

extra lines

ItemList->RecipeList

item list file path

of recipes

recipe list file path

will fail checkstyle

item -> recipe

checkstyle

can consider shorter prefix

for clarity can change to "Recipe ID is out of range"

should this be {@code Item}?

catch specific exception

add comment above this line specifying that this is for the delr command

conform -> conform to

extra lines

this constructor might be misleading, would it be better to modify the existing one?

for instance


if (!isDeleted) {

    idCounter++;

}

in the existing constructor might make it usable as an equivalent to this one

remove or change to logger statement

Name typo (?), img not updated

[stephentan]

change names in [ ]s to be consistent styling

img not updated

address book -> item/recipe

these steps as well

persons -> items/recipes

actual pictures pls 😃

should this be 3a and 4a?

recipe

standardise with README, use InvInator.jar or change README to inventoryinator.jar

add line back

via the issue tracker of this repository, with link to it

keep names consistent - full name or given name

rephrase to "what is going on under the hood"

should this be "deli stone" for the moment?

delr -n >name> -i >index>?

should locations be included as well?

del -> deli

same for this line

delete -> deli/delr

mark as TODO for easier search

optionally provide a short intro on how we structured our personas (explain that our app will help transition the before scenario to the after scenario, etc.)

include option to use


java -jar InvInator.java

contacts -> items

mark as TODO

should we change to deli and delr for now?

should we split del -> deli + delr?

should we split del -> deli + delr here?

i think we should specify that they need to overwrite multiple files, since our storage for each class is in separate files

change titles for each of these files

Should this use the NOT_FOUND message instead? User does not need to know our implementation


itemList.removeIf(x -&gt; !x.getName().equals(productName) || x.isDeleted());

in line 43 looks like it already ensures the item won't be deleted

Suggest to change phrasing to something like

"soft deletes recipes that contain deleted item as product or ingredient"

DeleteRecipeCommand -> DeleteItemCommand

use proper punctuation please

and all recipes associated with the item

please space the methods in this file

spacing

remove this line

@code item

spacing

proper punctuation please

spacing

use block comment

fix spacing in this file

spacing

space out these tests

re-add spaces in this file

fix spacing

spacing

more clear explanation needed

spacing

should these be containsMultipleWordsIgnoreCase?

remove line

is it possible to test results of command? eg. if no such item exists, or check that the item being shown is indeed the right item

import from the file with existing modelstub

deceptive naming

try to remove if not too necessary, is an unusual class to have

use isEmpty

Might be better to not have "will you like to add some?" if there's no direct button to do so

use isEmpty

should this file be added?

Just "No items match the search string." should suffice here

One or more... will suffice

perhaps just "None" is better?

change these tests to using wrong prefix

can remove the old tests once replaced

remove, same for the rest of the printlns in this file

change other list as well

should this be unhidden? same for recipe variant as well

should recipes be reset as well? or is it automatically reset since all items are removed

is now supported as addq, should update this?

will this ever be supported?

same for this

space equally as the above lines

spacing after ,

remove extra line

add test to edit tags

add test for this

standardise to without the "inator", same for rest of instances

change to more informative error message, at least the itemId of the item that caused the error (even if it never hits) - but keep documentation

might want to use stringbuilder here and the subsuquent +=s

don't do this, it creates coupling btwn the variables - use a method that returns Integer.parseInt(...)

document why it is ignored, or add logger (same for other similar instances)

why this change?

standardise to all words inside ** ** to have 1st letter in caps, eg. Add tag to item -> Add Tag to Item

either -> any

add ... after string2 like in findt

add {digit} like in findt

remove space after /

quantity -> tag

change this to something relevant

might be better to put commas? same for find

this message doesn't look right, also don't see it being used

is -> was

wrong class

add line spacing before this line

why including overlaps? add documentation

space this out with lines before & after

change javadocs

but don't duplicate tags also get handled? some documentation contradiction here

change javadocs

wrong type of command...

add more spaces

from below code it looks like this will only show iff the user input is exactly the current tags. should it also show if it's a subset?

add message

concerning, any reason why?

try reverting this particular chunk and see if you can still run?

modes, which are: display...

this needs a clearer explanation

a, b

Replaced by the ItemParserUtil and RecipeParserUtil

Will be added when future tests require it, currently the item list is needed to reset the item's recipelist so some tests don't contaminate it and affect future tests.

The constructor takes Set in at the moment, might look into this in future

Done in https://github.com/AY2021S1-CS2103T-F13-1/tp/pull/17

Done in https://github.com/AY2021S1-CS2103T-F13-1/tp/pull/16

Issue #30 opened as per review.

resolved by #31

Pushed to future PRs:

LocationList current defaults to Optional.empty, to be fixed and tested.
RecipeParserUtilTest incomplete, does not test for ingredient-related parsing.

Can now be closed, so closing the tutorial PRs.

Opened #73 regarding above comment

needs update of developerguide.md as well

seems too difficult to implement reliably in reasonable time complexity

Intended behaviour due to regex behaviour.

Agree with the suggestion, but complexity is too high for our scope and timeframe 😦

Cannot replicate, will KIV

Has been resolved.

Moved to issues #148, #149, #150, #151, #152

UG section done, DG section remains

closed as per recommendation by prof

No more functional code for v1.4.

New feature added does not correspond to the feature you were assigned. Possible typo?

Examples provided not changed to match the changed feature.

User command should be just "list" instead of "list 2" to fit the explanation fo the command. Possible typo?

Maybe changing it to "displays all your assignments and lessons for the next 2 weeks" would be more succinct?

How about "displays all your lessons and assignments for the next 2 weeks (including the current week)"?

Looks good!

@printinghelloworld sounds good 😃

Looks good 😃 A minor nitpick is that you may want to consider removing point number 3 ("ASM retrieves lesson data from NUSMods API") as according to the textbook, use cases only describe the externally visible behavior, not internal details, of a system.

Similar to the above comment, maybe it would be better to change the phrasing to describe how the ASM displays the lessons from the newly imported timetable

Maybe including the time the assignment is due in the deadline would be better?

E.g: n/Lab report 3 d/23/04/2020 1230 mod/CS2100

Since we have some optional fields as well, maybe it would be clearer to the user if we changed the description given in AB3 to match our project?

I was suggesting to keep the Tip section and change the description to "You can use the remind tag to set reminders for the assignment you want to add instead of using the remind command after adding the assignment" or something along those lines.

Currently, module code can accept the same string format address in AB3. Perhaps consider changing it the VALIDATION_REGEX to match the format of module codes as well?

Testing of new ModuleCode field may be more accurate if the input was changed to match the module code format.

INVALID_ADDRESS_DESC should be INVALID_MODULE_CODE_DESC for consistency 😃

Similar to the above comment, VALID_ADDRESS_AMY should be VALID_MODULE_CODE_AMY.

Similar to VALID_ADDRESS_AMY comment.

Name of method still refers to address instead of moduleCode. Possible typo?

Could consider changing the test cases to test for valid module codes 😃

According to the 2103T textbook, the suggested guideline for code quality is to break-line after the bracket instead of in the middle of an instantiation.

E.g:

JsonAdaptedPerson person = new JsonAdaptedPerson(

VALID_NAME, VALID_PHONE, VALID_EMAIL, null, VALID_TAGS);

The comment describing the test still refers to address field instead of module code field.

Similar to other comments, the comment describing the test still contains address.

Comments still refer to address. But it is just a minor nitpick 😃

Similar to other comments 😃

This line can be removed 😃

Comment still refers to address instead of module code

Maybe could do more testing to ensure that the regex works as it's supposed to? You can consider testing for modules codes with no alphabets at the start ("1010S"), modules with no numbers ("GER"), modules that begin with more than 3 alphabets ("ABCD1000") etc

Comment still refers to address field.

Similar to other comments relating to address comments 😃

The comment describing the email test is not deleted.

The comment for this test still contains 'email'

yup

This test case seems to still have references to email.

Comment still references email.

Comments for this field use 'persons' instead of 'assignments'. Be sure to check the comments as well 😃

Similar to the other comment, the comments for the field use 'persons' instead of 'assignments'

Similar to the other comment, the comments for the method use 'persons' instead of 'assignments'. Same for the equals method below this method 😃

Similar to the other comments, the comments use 'persons' instead of 'assignments'

Similar to the other comment, the comments for the method and the string parameter at line 9 use 'persons' instead of 'assignments'.

Similar to the other comments, the comments use 'persons' instead of 'assignments'.

Similar to the other comments, the comments use 'persons' instead of 'assignments'

Nice test cases 😃 You may want to consider leaving a space between some parts of the code to make it more readable (e.g leaving a space between lines 79 and 80 and leaving another space between lines 81 and 82)

Similar to the previous comment on improving readability 😃

Similar to the other comments, the comments use 'persons' instead of 'assignments'

According to the CS2103T textbook, the convention for the indentation for wrapped lines should be 8 spaces.

Following the CS2103T convention, you may want to consider changing the indentation to match the one in red 😃

You may want to consider leaving a blank line between some lines to improve readability and code quality (E.g leaving a space between lines 82-83 and lines 84-84). You can refer to the screenshot of the CS2103T coding conventions below 😃

Similar to the comment above on readability 😃 You may want to consider applying the same thing to the other test cases in this class

JavaDocs should be @moduleCode instead of @address 😃

JavaDocs should be @ModuleCode instead of @Address

Since assignment starts with a vowel, it should be "an assignment" instead of "a assignment" 😃 The same typo can be found throughout the project. You can consider using the "find in path" feature in IntelliJ to help you find them (Edit -> Find -> Find in Path)

This test case should be removed 😃

May want to consider adding a link back to the main point which is that ProductiveNUS is supposed to help NUS Computing students resolve the problem so that it is clear what the aim is 😃

I also think it may be better to use more passive language? So instead of 'You often...' it may be better to use 'You may often...'. What do you think?

Looks good! A suggestion could be to bold/box certain words to make the aim more obvious.

The test cases look good! Minor nitpick, the comments next to the valid test cases do not match what is being tested. Also, if the lesson names do not accept numerals in the name, you may want to consider changing the validation regex to only accept alphabets 😃

Nice test case 😃

okie

Naming the deadline field time may be more appropriate for the Lesson class as it doesn't really make sense for a Lesson to have a deadline.

Personally, I feel that using 'schedule' is a little vague. Maybe you could consider changing it to 'schedule manager' or 'schedule book'? What do you think?

Message for duplicate assignment still refers to address book.

According to the CS2103T code convention, boolean variables should be named to sound like booleans (e.g isRemindTypo/containsTypo instead of remindTypo).

I think can just use the hashcode method you created in Lesson.java as given the way you implemented it seems similar to how AB3 implemented it for Person, I think lessons.hashCode() should be fine.

According to the CS2103T coding standards/conventions, we should try to avoid deeply nested methods. Maybe you could consider removing the else block and extracting the "happy path" to prevent the method from becoming too deeply nested. Another suggestion is adding an empty line in between lines of code to improve readability. You could consider applying the SLAP framework as well 😃

I'm not very sure what "Lists the tasks within the next index number of weeks" means. Maybe consider changing the explanation to what is stated in the User Guide?

Nice! You could consider abstracting out the implementation as a private method as the execute(Model model) method is a little long now and according to the CS2103T conventions on code quality, we should try to avoid too long methods 😃

According to the CS2103T textbook, under code quality, we should strive to extract the "happy path" out. You could consider changing the code to extract the "happy path" 😄

e.g:

if (!isNotListAll) {

return new ListCommand(Index,fromZeroBased(0));

}

try {

....

}

According to the CS2103T coding conventions, we should delete code that we do not need 😃 Are you planning to use the commented out code at a later date?

JavaDocs still refer to assignments instead of lessons

Similar to the comment above regarding the JavaDocs 😃

Similar to the comment above regarding the JavaDocs

String still refers to Assignment instead of task 😃

JavaDocs still refer to assignment instead of Task

Similar to the above comment regarding the JavaDocs.

JavaDocs still refer to assignments instead of tasks

JavaDocs still refer to Assignment instead of Lesson

Similar to the comment above regarding JavaDocs

JavaDocs still refer to Assignment instead of Task

Similar to the above comment regarding JavaDocs

Good job 😃 You may want to consider abstracting lines 125 to 135 into another method as this method is quite deeply nested. Remember to SLAP hard 😄

👍

Good job 😃 You may want to consider extracting this part into another method as the CS2103T textbook suggests that we should SLAP our code to improve code quality.

JavaDocs for ScheduleCommand refers to RemindCommand instead of ScheduleCommand.

Good job 😃 A suggestion you may want to consider is to name the boolean variable "can" to something more descriptive and meaningful, as currently "can" doesn't really describe what the boolean is checking for. If you do change the name of the variable, remember to adhere to the CS2103T conventions and ensure that it sounds like a boolean value (i.e isPossibleTime, canSchedule etc)

According to CS2103T conventions, boolean methods and variablels should be named to sound like a boolean (i.e haveOverlap, isOverlappingTime etc)

JavaDocs refer to AddCommand instead of ScheduleCommand.

Is this constructor used for testing?

If this constructor is used for testing, it may be better to create a ScheduleStub class in the test package for testing 😃 But this is a minor issue that can be done when you do UnitTesting.

The JavaDocs for the constructor should be phrased as "Constructs a ...". But this is a minor detail that can be fixed in v1.4 so don't worry about it for now bah 😃

oh okie okie

What's this System.out.println used for? Just curious 😄

JavaDocs conventions for CS2103T is for JavaDocs to phrase JavaDocs in such a way: "Constructs...", "Retrieves....", as opposed to "Construct..." or "Retrieve..."

Since the undo command currently only works with every command except for find and list, you may want to consider adding that information into the message usage and message undo fail so that the user will know exactly why it fails 😃

According to the CS2103T code quality conventions, it recommends that we extract the "happy path".

Maybe stating the priorities would be clearer for the user to understand?

For example, "Sets, HIGH, MEDIUM or LOW priority for the assignment identified by the index number...."

JavaDocs still refers to the remind command for @param

Assignment variable still refers to remind command instead of priority command

False priority is a little misleading as it makes it sound as if the user used the wrong input format for the Priority command instead of setting no priority to the assignment. You may want to consider changing the phrasing of the JavaDocs for the constructor such that it better reflects what the constructor does 😃

Slight nitpick but since you gave the date format before the time format, you could consider using "... finding of assignments by date and time separately", instead of "... finding of assignments by time and date separately". But it is fine if you leave it as it is too 😃

You could consider changing the word prefixes, as it may not be very clear to the user exactly what we are referring to when we say prefixes. Maybe something like "Multiple assignment fields detected. Finding is done one field at a time." then provide examples of what a field is?

The fetching of keywords for each field appears to have some overlaps. You could consider abstracting the implementation and creating a method called getKeywords(String prefix) to improve the code quality 😃

Should be "Tests that an Assignment..." instead of "Tests that a Assignment...". Possible typo?

Similar to the above comment on the grammatical error.

Likewise 😃

According to the CS2103T coding conventions, boolean methods and boolean variables should be named to sound like a boolean. However, it appears that this method is overriding a method from Predicate, so it should be fine 😃

Nice test cases 😃 A suggestion is inserting white spaces between each test case to improve readability. You may want to consider testing for incorrect date and time as well (i.e 31-02-2020 or 2500) to ensure that the parser works as intended 😃

Similar comment regarding the insertion of white spaces 😃

You may want to consider testing for the other fields as well to ensure that they are working as they are supposed to but this is a minor nitpick 😃

Similar comment regarding the insertion of white spaces 😃

You may consider adding in comments to tell the reader exactly what you are testing for (e.g invalid deadline, invalid date, valid time or invalid module code). Though this is just a minor nitpick 😃

Nice use of white spaces 😃

Though you may want to consider using the white spaces to not just improve readability but to group code with similar logic together (i.e grouping all the nameKeywords, deadlineKeywords... List>String> variables together and only inserting the white spaces in between priorityKeywords and findByNames. Likewise for the FindCommand variables and the assertEquals methods).

The description and format does not fit the unprioritize command 😃

The phrasing sounds a little weird to me, though it could just be me XD The "to import" at the end of the sentence appears a bit redundant as well since at the start of the sentence, you already mentioned that the information will be imported.

Maybe "The user can import information about their lessons into ProductiveNUS using their NUSMods timetable URL" would be more concise?

Looks good 😃

Maybe using "Unmarks the 3rd assignment as done" would be more appropriate since undone is not exactly proper English XD But I think the way it is now is fine too.

Likewise for here 😃

Oh when I googled it, Google said unmark is proper English but okie XD

I agree with Andrea 😃

JavaDocs refer to reminders instead of the suggested schedule 😃

JavaDocs still refer to prioritize command

Should be "Creates and returns an Assignment..." instead of "Creates and returns a Assignment.."

JavaDocs still refer to RemindCommand

JavaDocs refer to Remind instead of Done

Commends refer to reminders instead of marking assignments as done

Likewise for this comment 😃

Oops must have forgotten to delete the empty return tag when I created this method. You can just delete the @return tag since the other methods don't seem to have the @return tag 😃

Is there a reason these methods are static methods? They seem to only be used in the DeleteCommand class, so I don't think they have to be static.

Does this currently only test for a single index?

Maybe adding comments to explain what these are would be good as I am currently a bit lost as to why INDEX_FIRST_ASSIGNMENT was added twice 😃

The phrasing for line 142 sounds a little strange. Maybe "... quickly view assignments that are due soon." would be better?

Hmm, then maybe removing the (with deadlines nearing) would be better in terms of phrasing 😃

For this table, I don't think the "type of keyword" column is very meaningful as the syntax column already mentions the type of keyword in all caps. Also, personally, I feel that the "syntax with example" column is a little cluttered. Maybe separating that column into 2 columns would be better? (one syntax column and one examples column)

Format line should be placed right after the "Finding assignments" subheader to preserve consistency 😃

Currently, the parameters section and the table appear to have some slight overlap. You may consider either incorporating the parameters section into the "Remarks" column in the table, or edit the parameters section such that it is distinct from the table.

What if the user inputs remind without a priority?

Is it because Priority is an optional field? Does remind have the same problem as well or is it just Priority?

In our User Guide, MORE INDEXES has an underscore (e.g MORE_INDEXES) so you may want to consider changing the description to match the User Guide 😃

Good catch! I shall go amend it later 😃

Likewise for here 😃

I think the previous subheader "Importing your timetable" would be more user-centric 😃

You may want to consider telling the reader exactly where the task list is by providing a diagram of the GUI and highlighting Upcoming tasks or you can just mention that the task list is displayed under Upcoming tasks in the description 😃

It may be good to phrase it as "your task list" instead of "the task list" to make it sound more user-centric, though this is just a minor nitpick.

The diagram looks good! There seems to be a problem with the formatting of the Figure caption though (Refer to screenshot below)

It may be good to mention where the user can find their added assignments 😃

Looks good 😃 However, as the rest of us put the descriptions of the examples outside of the Example: section, it may be good to write the examples as their own paragraphs (and add some diagrams if needed) for consistency. Then under Examples: section, you may either write some examples commands (without the description) or just remove the section if you believe it is not necessary.

Also, another note is that @hyngkng has changed the priority prefix from priority/ to p/

Maybe phrasing it as You can keep track of your uncompleted assignments... would be better since undone isn't really grammatically correct in this scenario XD

Maybe phrasing it as "You can mark your assignments you have marked as done as undone...." would be better? Since currently it sounds like undone assignments can be marked with a specialised undone tag instead of allowing the user to mark done assignments as undone.

Should be "You can unmark done assignments..." instead of "You can delete...." 😃

It may be good to include how to open the command interpreter for Mac and Linux OS as well 😃

Yup. Umm not sure tbh.

You can either ask @andreatanky or next to "assignment list" just put "(highlighted in red)" or whatever colour you want to highlight it then add the diagram below 😃

There are 2 done 2 3 the markup 😃

You may want to consider mentioning the user benefit of this command (e.g "if you are new to ProductiveNUS and would like to view a summary of the command" or "if you want to see a quick overview of all available commands")

Minor nitpick but maybe phrasing it as "You can use this command to exit the program" would be more consistent with the rest of the UG in terms of the style of writing 😃

Do we not? XD

You can just rephrase the sentence then bah. The ones I provided are just suggestions 😃

I agree with @printinghelloworld . Perhaps mentioning how the user will not be required to manually plan a time to do the assignment would be good 😃

Noicee

Remember to change the prefix from dobefore/ to before/ 😃

Is there a reason isSameAssignment causes the add command to be buggy but the equals method doesn't? Just curious XD

May be good to include test cases where the index lies outside of the stated range (e.g 51)

Noicee. You may want to consider adding comments for the boolean argumentRange to tell the reader what the valid range is 😃

Looks good! However, the other commands implemented the error message by using Messages.MESSAGE_INVALID_COMMAND_FORMAT ("Invalid command format!") and MESSAGE_USAGE ("Format: clear").

But this is just a minor nitpick so you can ignore this for now XD

I can go edit it to match the other classes once this PR has been merged 😃

According to the CS2103T coding conventions, all constants must be in UpperCase and use underscore to separate words.

Since nusModsProtocolAndHost is a final variable, it is a constant and should hence be named NUSMODS_PROTOCOL_AND_HOST.

Maybe instead of using the standard invalid command format message, telling the user that the URL is invalid may be a more meaningful error message 😃

You may want to consider mentioning the user benefit of the edit command as well 😃

There seems to be something wrong with the formatting of the table 😦

Nice addition 😃 You may want to further expand on the user benefit as well as Dr Wee mentioned that we should answer the "so that" question.

A suggestion would be "...so that you can easily amend any mistakes you made when adding assignments".

The description looks good! However, there seems to be something wrong with the formatting 😦 I have attached a screenshot of the FAQ is displayed in the UG on GitHub.

The formatting here appears to have a minor error as well.

Looks good! You may want to consider adding white spaces between the figure caption and the steps to improve readibility 👍

Has @minhhhnguyen2000 been informed of the change in prefixes for the schedule command?

Maybe it would be good to rename the final static variable to TIME_DATE_TIME_FORMAT as well as I believe the Lesson class also makes use of the same variable to format the start and end times

The JavaDocs of the Time class should be changed to match the new name.

Maybe something like:

"Represents the time found in a task in ProductiveNUS

Guarantees: immutable; is valid as decalred in

It would be ideal if isValidDeadline is changed to isValidTime as well, though if only the assignment class uses isValidDeadline, then it may be fine to leave the name as it is.

If I am not mistaken, the time constructor is used for both assignments and lessons. Hence, it may be more apt to rename the parameter of the constructor as well 😃

Likewise for here

JavaDocs should be changed to match the new class name 😃

Follow up to my previous comment on the naming of isValidDeadline, since isValidDeadline is used in to check the format for Lesson as well, it would be good to rename the method to isValidTime

Not really related to your part, but it may be good to use the final static variable TIME_DATE_AND_TIME_FORMAT here as well 😄

Likewise for here

Likewise for here. You can redirect this issue to @minhhhnguyen2000 if you wish XD

address name should change to module code after merging the PR that changed the address field to module code

Sounds good!

Amended 😃

Since we are probably going to be adding an edit feature in the future we can just leave it in first or add it to v1.2 since the implementation is all done for us already 😄

What do you mean?

At first, I made it a non-abstract class, but then IntelliJ made noise because it extends abstract class Command so i either had to override the execute method in NegataCommand or make NegateCommand abstract. Since I personally felt that overriding the execute method in NegateCommand was a little redundant since the UnremindCommand, UnscheduleCommand and UndoneCommand will override the execute method again, I decided to make the NegateCommand class abstract.

I can change it back to a normal class if you want to though, I shall just override the abstract execute method in NegateCommand if you want to change it to a normal class 😃

Oh yup. Must have missed it out. I shall go change it now

Amended!

it's supposed to be 📋 Notes about the command format, I forgot to change the icon back to the clipboard. Shall go amend it later 😃

amended!

LGTM.

Will description 'Tags your assignment with a reminder which adds it to 'Your reminders' section' be clearer?

Noted! I have edited the phrasing. Is the edited version clearer?

I have changed some of these user stories to make it more specific. eg. 'work'

Perhaps refer to DG to see which is better?

Updated accordingly 😄

Looks good! Just a small suggestion, maybe we can standardise the use of capital letters under 'I can' and 'so that I can'. we can either capitalise the first word or not capitalise the first word for both scenarios 😃

Sounds good! Which do you suggest is better? I'm fine with either way 😃

Looks good! Just a small suggestion, maybe we can standardise the use of capital letters under 'I can' and 'so that I can'. we can either capitalise the first word or not capitalise the first word for both scenarios 😃

Sounds good! Which do you suggest is better? I'm fine with either way 😃

I think for now we can not capitalise for both scenarios !

Amended 😃

LGTM! I was at first worried about nested loops but figured there isn't a much better way anyways

I refactored the code so that the nesting isn't that bad and made the code neater 😃

Actually does the user need to list all modules first before adding a new one ah?

Maybe an empty list shouldn't affect the addition of a new module? If not a user can never add his first mod since the list will be empty then LOL


 * Duplicates are not allowed (by .isSameModule comparison)

Should we update the default pathname to gradpad.json or something along those lines?

I think we can update the javadocs for these changed methods 😁


     * Adds a new {@code Module} to the {@code GradPad} that we are building.

This test fails cos 2 Modules shouldn't be equal if they have different module codes. Perhaps we can remove the module code change


        Module editedAlice = new ModuleBuilder(ALICE).withTags(VALID_TAG_CORE)

I think we need to update TypicalModules.ALICE cos the tests can't build since ALICE is an invalid module. It'll probably be good to rename it too LOL cos alice is still a person's name

Maybe we can rename the dummy path since we're no longer building addressbook 😁 Same goes for the change on line 46 below


        userPrefs.setGradPadFilePath(Paths.get("gradpad/file/path"));

Same as prev comment

Maybe we can remove the regex split? It doesn't do anything since module codes never have spaces in them. Maybe we can just create an array with the module code in it as a single string:


        String[] keywords = { CS2103T.getModuleCode().moduleCode };

This is exactly the same as the CS2103T in the prev line HAHAHA so it'll always return true LOL

In this test, we are seeing if modules with the same module code and MCs, but different tags, will be considered the "same" by GradPad, so maybe we can just change the tag:


        Module editedModule = new ModuleBuilder(CS2103T).withTags(VALID_TAG_NON_CORE)

Nit: I think we need to update the javadocs for this method

Let's change these example tags HAHA altho I wish modules could give me friends and money...


    public static final String MESSAGE_DUPLICATE_MODULE = "This module already exists in the grad pad";

Perhaps we can rename the variable editModuleDescriptor here and also the references in the few lines below it.


        EditModuleDescriptor editModuleDescriptor = new EditModuleDescriptor();


    public static final String MESSAGE_DUPLICATE_MODULE = "This module already exists in the grad pad.";


    /**

     * Stores the details to edit the module with. Each non-empty field value will replace the

     * corresponding field value of the module.

     */


    /**

     * Creates and returns a {@code Module} with the details of {@code moduleToEdit}

     * edited with {@code editModuleDescriptor}.

     */

I think we need to update the javadocs here 😁


 * Deletes a Module identified using its displayed index from the grad pad.

Perhaps we can use camelCase for the property names? JSON properties are basically hashmap keys; so just like how we wouldn't use multiple words (with spaces) in a key or variable name (altho JS/JSON allows), maybe we can use moduleCode or module_code instead?


     * Constructs a {@code JsonSerializablegradPad} with the given modules.

Not a suggestion/request for change, but I was just wondering why the original code does this redundant check here when it could just call gradPad's setModules fxn, which already uses UniqueModuleList to ensure all modules are unique.

I just put this comment here first in case we want to improve code quality next time.


List<Modules> gradPadModules = modules.stream().map(JsonAdaptedModule::toModelType).collect(Collectors.toList());

try {

    gradpad.setModules(gradPadModules);

} catch (DuplicateModuleException ex) {

    throw new IllegalValueException(MESSAGE_DUPLICATE_MODULE);

}

I think we need to rename the file also 😁

I think this test assertion is the same as the one a few lines above 😁

Since it's supposed to include other valid values, perhaps we can do:


        userInput = targetIndex.getOneBased() + CODE_DESC_CS2103T +  INVALID_CREDITS_DESC + CREDITS_DESC_CS3216;

        descriptor = new EditModuleDescriptorBuilder().withModuleCode(VALID_CODE_CS2103T).withModularCredits(VALID_CREDITS_CS3216).build();

Nit: the test is perfectly fine but maybe we can replace the dummy keywords with module names

The lastModule is already CS3216 right HAHA so we don't need to "edit" it with the same code and credits again


        Module editedModule = moduleInList

                .withTags(VALID_TAG_CORE).build();

😁 I think the re-naming of the variable was missed out


 * A utility class to help with building EditModuleDescriptor objects.


     * Parses the {@code tags} into a {@code Set<Tag>} and set it to the {@code EditModuleDescriptor}

nit: typo

This module is valid HAHA

It's why the test for invalid module in JsonSerializableGradPadTest isn't passing

Nit: grammar 😆


ease your module planning process. A module searching platform is also included in GradPad, providing easy


class to create a corresponding `AddCommand`.

I think the method call wasn't specified; is it supposed to be AddCommandParser.parse()?

We need to change deletePerson(1) in line 51 😁


deactivate GradPadParser

typo? hehe

Maybe we can rename the return variable as a or smth? I only named it e in my diagram cos it stands for EditCommand 😁


Format: `add c/ {module code} cr/ {modular credits}`

What does the timestamp in the status bar refer to ah?

Grammar nit: Not really sure how to tweak it but "successful find" sounds a bit weeeird? 😁

Maybe one way could be "...in GradPad to successfully show the found module."?

Yeah okay that sounds good 👍

Let's update the javadocs too 😁

Should we add "matches part of any word in ModuleCode" too? Since now we support it

Do you think we should remove "multiple words" ah? I feel like it might be an irrelevant equivalence class now that we use a .contains() check

Removing it will also match the new test cases below since we're removing the old tests involving multiple words

Is there a typo for help modules? LOL actually can't tell cos this is still a correct invalid command HAHA


3.  GradPad displays the deleted module onto the `Command Line Display`


**Use case: UC05 Edit a Module in `Current Modules`**

I think we also need an extension to cover the case when invalid fields are given e.g. credit/5 instead of cr/5

Actually it's not just the required module list righttt cos that's only like ~10 mods out of all 150 CS mods that they can search for


1. User requests to search for a module in the CS curriculum.

Same comment as previous 😁

Perhaps it might be better to list this out separately? Maybe below this sentence we can put:

The following module details will be displayed:

module code
title
etc

I think square brackets are only for optional arguments? Actually are we following the original UG syntax format ahhh? I'm not too sure

Minor minor code nit: perhaps this could be joined into one if statement instead of nesting so readers can easily tell what this block does (i.e. check if user is disconfirming)


        boolean isDisconfirmation = stalledCommand instanceof Command && !commandText.equalsIgnoreCase("yes");

        if (isDisconfirmation) {

You mentioned that you were concerned about messiness earlier but I think this implementation is fine actually! 😀

But if we want to, we can abstract this out into a stallComponent fxn that handles the stalling. It might take in a Command, do the necessary stalling/operations, then return the CommandResult. This will make things more future-proof cos we don't know how many future commands need confirmation, and we don't wanna keep stuffing everything into execute


        if (command instanceof ClearCommand || command instanceof DeleteCommand) {

                return stallCommand(command); // returns the CommandResult

        }

These two lines need to be swapped 😁 cos we don't want to stall the command before checking that it's valid, which only happens when we call getModuleToDelete.

Right now if we type in an invalid delete e.g. "delete 100000", the command is still stalled and GradPad will wait for a confirmation. When a user then corrects himself and types "delete 1", GradPad will say "command aborted" instead of executing the corrected command

Really really small nit: I think this method can remain as private since only handleStall should use it HAHA Actually how come it's changed from private -> public since the last review ah?

Since we have so many messages here, perhaps we can shift this into a class on its own e.g. RequiredCommandMessages to avoid bloating the RequiredCommand class. We can then do static imports as needed

This code seems to be repeated in a few compareX fxn so it might be good to abstract it out into a getModulesToAdd(>requiredModuleList>) fxn or something along those lines that takes in a List and returns the string modulesToAdd

Maybe we can name this isFoundationCleared to make it more boolean-like? Same applies for the other compareX functions

Perhaps we can use a java StringBuilder here since we're iteratively doing string concatenations (line 91). Otherwise we'll be doing O(n) operations per iteration and this fxn will run in O(n^2) 😁

Maybe it'll be better if we handle the exceptions in this command instead of propagating it cos that would mean we need to change the execute contract (as has been done). But in doing so, we are breaking the interface segregation principle since ALL other commands are also now bound to a contract that isn't applicable to them.

(cont. from prev comment)

So maybe what we can is to wrap these error-throwing calls in a try-catch block and handle exceptions here instead. After all, clients expect this execute method to give them a result (success or failure message), and not an exception.


try {

        setFoundationStorage(FOUNDATION_PATH);

        setITprofStorage(ITPROF_PATH);

        setMathAndScienceStorage(MATHANDSCI_PATH);

        setScienceStorage(SCIENCE_PATH);

        setInternshipStorage(INTERNSHIP_PATH);

} catch (IOException | DataConversionException e) {

        // from the error msg you wrote in MainWindow hehe

        return new CommandResult("File not found :(");

}

Maybe we can declare the pathstring as a class-level constant instead to make it obvious where the filepath is stored when we need to change it next time 😄

Same as RequiredCommand, perhaps we can wrap this in a try-catch and handle the exception here rather than propagating it and binding all other commands to a new contract

Same as previous comment in RequiredCommand, we can use a StringBuilder instead so that this fxn can run in O(n) instead of O(n^2)

Maybe we can initialize this to an empty Optional instead of leaving it as null? I think it's a bit weird that the field can either be null, empty Optional, or filled Optional when the purpose of Optionals is to abstract away nulls anyway HAHA

But this one is really a minor suggestion 😁

Perhaps we can consider using this instead:


        assertTrue(actual.isEmpty());

As mentioned in the java API, it's generally not recommended to do equality checks for Optionals cos they produce unpredictable results 😁 Same applies for the other tests below and also ScienceCommandTest

Shouldn't areModulesCleared become true when we find out that the user has taken a science module?

Likewise if areModulesCleared is true then shouldn't we be showing MESSAGE_SUCCESS_SCIENCE instead since the user has cleared this basket HAHA

How come taking a single internship module means that areModulesCleared is false ahh? I tot it should only be false if total MCs > 12 since we need >= 12 in order to clear the internship basket >>

I FEEL LIKE IM MISSING SOMETHING OBVIOUS LOL SO PLS FORGIVE ME IF I AM HAHA IM DAMN CONFUSED

Actually how come we need the areModulesClearedflag instead of using an if-else statement ahhh?

Just to clarify, is this code saying: if a module is taken, then add its MCs to modularScore. If it's not, add the module title/mc to the result to display instead.

PAISEH I'm very confused here ><


            if (doesModuleAlreadyExist(module, currentModules)) {

                int modularCredits = Integer.parseInt(module.getModularCredits().toString());

                modularScore += modularCredits;

            } else { 

                String moduleToAdd = module.getModuleCode() + " (" + module.getModularCredits() + " MCs)";

                leftOverInternship.append("\n").append(moduleToAdd);

            }

I think we might not need to catch, reconstruct, and re-throw the same exception? HAHA We can just remove the try-catch block 😁

I think there's no IllegalArgumentException to catch here LOL StringUtil.ignoreCase and SearchCommand's constructor both don't throw ittt

Just interesting side note (no need to change anything!):

JUnit tests automatically fail if any exception is thrown so we don't need to be concerned with catching exceptions and failing the test ourselves 😄

Oooh okay! My bad hehe I didn't realised that checkArgument in StringUtil.ignoreCase() throws an undeclared IllegalArgumentException (since its a runtime error)

No need to change, this is great 😄

Suggestion: Should we explain that we allow users to edit multiple fields in the same command?

Should we use the term Completed Modules list since we're using it throughout the UG to keep things consistent?

Should we put a note or something letting users know that if their internet is down, then they can only search CS-curriculum modules?

Shall we make this private? This fxn should be uniquely called by this class only since it calls the inherited Object.getClass() method that depends on this class's runtime Class

And actually this fxn gets the file content from a resource and returns it as a string right HAHA not the file name, as mentioned in the fxn name

This method is reading in a JSON string, like "{ module: { title: "abc", mc: "2" } }", not a file path 😁

Should we list out what the constraints are? I think most people won't know, including me HAHA

As mentioned above, this is actually the entire content of the file stored as a string, not the file name 😁

Should we store these constants in the test package instead? I think it might not be so nice to mix production code and test code 😁 None of the production classes need to reference these anyway hehe

Should we add a state check for module title equality too?

Instead of changing this test to a negative test with duplicate modules in a filtered list, could we still keep it as a positive test for successful execution on a filtered list? Cos there's already a number of negative tests below for the same equivalence class 😁 We could edit the tags here instead and assert a successful execution

Actually why do we need to look up the info for the module to be edited ah? I thought we only need to know if that module has been previously added to GradPad, which is already checked by EditCommand. Just asking cos these http requests are expensiveee $$$ 😢

Should we include negative tests for invalid module codes instead? i.e when a user tries to edit a module that doesn't exist in Completed Modules

Smol nit: Since this test and the one before it both only specify one field, should we name them "onlyModuleCodeSpecified" and "onlyTagsSpecified" or something like that instead?

Does this effectively remove the size constraints for this row so that it can be dynamically sized according to its children?

This might just be me but I find the font size a bit too small >>

I don't think so? HAHA I think there are only 2 equivalence classes for the inputs to DeleteCommand:

Module code exists in the list
Module code doesn't exist in the list

Since you've covered both I think we're good 😄

Woah why is this test deleted

Should we put this in the note too? We also need to remove the numbering


Refer to the [Feature Summary List](#feature-summary-list) below for a summary of all commands.

Since this fxn is duplicated from RequiredCommandStorage, should we just put this in JsonUtil instead and make it static?

Maybe we can rename this class? 😁 Since it actually stores storage paths and no messages HAHA

We're still guaranteeing that it's immutable so maybe we can keep the first part of this sentence?

Same comment as the one in ModuleTitle about immutability

Just a suggestion: maybe we can use moduleCode.startsWith instead. I have no clue about this but I'm just scared if some module ends with a "GEH" or smth LOL, then .contains will still return true


    public static final String MESSAGE_FAILURE_GEM = "There was an error loading the required GE Modules :(";

Suggestion: should we add a getAllModules method to GemCommandStorage and calling that instead of doing all of this manually here in the client code?


            return new CommandResult(MESSAGE_FAILURE_GEM);

Since these 4 fxns have the same duplicate code, could the first 3 just make use of the 4th one? Then we can make the 4th fxn just a utility like setUpModules(Path path)


    public void setUpTestModules1() throws IOException, DataConversionException {

        setUpModules(TEST_GEH_SEM1_PATH));

    }

    public void setUpTestModules2() throws IOException, DataConversionException {

        setUpModules(Paths.get(TEST_GEH_SEM2_PATH));

    }

    public void setUpSingleModule() throws IOException, DataConversionException {

        setUpModules(SINGLE_MODULE_PATH);

    }

    public void setUpModules(Path path) throws IOException, DataConversionException {

        JsonGradPadStorage storage = new JsonGradPadStorage(path);

        ReadOnlyGradPad gradPad = storage.readGradPad().get();

        testModules = gradPad.getModuleList();

    }

Nit: Maybe we can make these Path objects just like the two paths above it? It's a bit funny when the 4 variable names here say "path" but actually it's 2 paths and 2 strings HAHA

Coding convention suggestion: perhaps we can include the method under test 😁


    public void execute_nullModel_throwsNullPointerException() {

I think you mixed up actual and expected HAHA 🤣 in the other tests below too

Actually we don't do prefix search 😁 e.g. searching "103" will return "CS2103T" also


    public static final String FIND_COMMAND = "find CS1 : Displays all modules that contain the keyword 'CS1'. \n"

Should we boast and say "from NUSMods" ah LOL

Grammar nit:


ease and improve your **module planning process**.

I think Serene mentioned that we can list examples of the "NUS resources" we are talking about. Maybe we can say NUSMods and/or faculty websites?

Hmm, I didn't think of that but since you've suggested it, why not? Haha I think there's no harm and it might be good 😄

Agreed - I think this could be in the testing guide in our DG instead since it's like "confirming" that the delete works. But I'm not too concerned abt this for the PE-dry-run for now 😄

I'm feeling like this is starting to go into parsing territory hmmm... Should we put this in GradPadParser instead? Then below we can just call gradPradParser.isYesCommandWord or something

Minor: I'm not sure if this violates the coding quality standard of not reusing formal parameters, but I'm also not sure what's an alternative tho HAHA

O maybe it can be


    Command command;

    if (isYes(commandText)) {

        command = gradPadParser.parseCommand("yes");

    } else {

        command = gradPadParser.parseCommand(commandText);

    }

We need to tweak the logic down here too cos now stalling doesn't work correctly 😕

If you type in a valid command while the app is asking for confirmation, it will execute that command instead of aborting the current stalled command since we're only aborting it when we get a ParseException now.

E.g. delete cs2101 --> (app asks for confirmation) --> add cs1101s --> (app adds cs1101s) --> yes --> (app still deletes cs2101

Typo (different commands):

'''suggestion

For example, if the command specifies 'edit MODULE_CODE c/NEW_MODULE_CODE t/core', 'edit MODULE_CODE t/core c/NEW_MODULE_CODE

'''

Actually should we include the optional tags in this summary since the bug report raised the issue abt inconsistency?

I agree with your first comment; I was thinking along the lines of this:


**Add** | `add {module code} [t/tags]` | `add CS2100 t/core`

This will throw an error if there are no semesters, which makes semesterResult empty, cos then we'll be calling .substring(0, -2). Even though the API will never return an empty semesterData field, we can be defensive just in case something goes wrong while fetching and parsing the data.

We can avoid dealing with extra commas and spaces by not adding them until they're needed:


    public String getSemesters() {

        return semesters.stream().map(Object::toString).collect(Collectors.joining(", "));

    }

Nit:


 * Parses input arguments and creates a new ForceDeleteCommand object

Nit:


 * Contains integration tests (interaction with the Model) and unit tests for

 * {@code ForceDeleteCommand}.

 */

Coding standard nit: there should be a blank line after the first line

Would it work if we use the mapper that's already defined in the class?

Maybe we can move this out of the loop since it doesn't change every iteration

We don't actually need to check containsKey HAHA if the map doesn't contain the key then the modules won't be equal (the next line)

I think there are still a lot of preclusions HAHA like cs1010s, cs1010j, etc.

Actually we don't need to store it separately since we already store storage, which contains the map right HAHA

And just to add on, notice that execute and compareModules are now aware of preclusionMap, even though it is only used by isModuleAPreclusion, a much lower-level method. The parameter is being passed through 2 methods despite them never using it. This anti-pattern is also called prop drilling/threading in JS btw HAHA

Maybe we can just do Map>String, String> preclusionMap = storage.getPreclusionMap() within the isModuleAPreclusion fxn instead of in execute?

Maybe we can say "module-specific storage classes"? Cos the rest of the classes do more than extracting and parsing JSON (they also handle writing)

Wah ok tbh I really like this - it couldn't be clearer xD

Constructor calls should be the class name not the object's name. I think it can also be omitted since it's evident in this case 😄


RequiredCommand -&gt; RequiredCommandStorage : RequiredCommandStorage()

Similarly, the label should just be the class name without the new keyword 😄


RequiredCommand -&gt; CommandResult : CommandResult(leftOverModules)

Actually ScienceCommand doesn't contain a list of hard-coded modules right? HAHA if not then it wouldn't have to set and get the science modules fromRequiredCommandStorage

I was abit confused when step 6 says GemCommand already contains both storages, but step 7 says they're only created then. Maybe we don't have to mention the attributes? I think the creation of both objects is quite clear on its own

Really damn small nit but maybe the happy path could be made clearer since it's actually just a single path:


                if (!model.hasModule(module)) {

                    String moduleToAdd = module.getModuleCode() + "\t" + module.getModuleTitle()

                        + " (" + module.getModularCredits() + " MCs)";

                    modulesToAdd.append("\n").append(moduleToAdd);

                }

Since all the setupXTestModules methods have the same 2 lines for reading data, should we create a utility fxn to handle this instead?

Agreed - idk how I missed this out the first time round paiseh >> Since it's in the Storage component, it might be good if it's only concerned about storing and retrieving data without being aware of the model

Typo: missing closing quote


SearchCommand -&gt; ModuleInfoSearcher : searchModule("CS2103T")

Should we put this in? It's not required to test the launch and I'm scared if it comes across as too mandatory. We need to remember that requiring internet connection is a tP constraint

Should we put these in the Messages class?

I think it's better to make this a static method since it is a getter for a static stub class; otherwise we'll have to do new NusmodsDataManagerTest everytime we want to get the stub

Da javadoc blank line HAHAHA SOZ I know it's annoying >>

Nit: since this is a negative test (when input is null), maybe we can name it invalid test?

Should this be .equals(null) since the test is about empty objects/inputs?

Instead of opening up Logic and checking if its stalledCommand is null, could we just do logic.execute(YES_COMMAND_WORD) a second time instead? If stalledCommand was correctly cleared the first time round, then this second execution should return the nothing-to-confirm msg

This way, we don't need the new contracts in the interface xD

Coding standard nit: maybe we can import the DEFAULT_WIDTH constant from GuiSettings instead of using magic numbers? Same goes for height in the next test

Updated these 2 badges so that when you click on them, they take you to our repo's CI and codecov pages respectively:

Let me know if this regex is fine cos I'm not too sure what kind of module codes we support

I left the contents unchanged for now as I only needed the tags as defaults

I added module field templates here and left the rest of the templates alone. We can remove at the end if nobody else needs them

I only added CS2103T and CS3216 as new modules in this class and left everything else alone first. Likewise, if nobody else needs them, we can remove them at the end

Oh yeah you're right. In that case, I'll let filterModuleSummaries take in a bunch of keywords to filter against. We can then define the keywords in a hardcoded constant depending on the list of required modules.

We still need this normal file path cos it tells GradPad where to save data to

Updated this and added IS1103 cos its now part of the list of new required modules

Very very good catch! Thanks and resolved 😄

This is now moved into the new isValidTagName test method below

Ui looks great but I think the website says it has to be the ard the same size as the original. Right now it's too big:

Feel free to resize, update the PR, and merge in your own time! 💯

I think this issue is too big and general? Maybe each person can create an issue specific to their work e.g. my issue should be "Add feature list and command summary to user guide" since I'm doing first page of our google docs

@yan-soon typos have been fixed; thanks so much for catching them!

Update: As per @shaokiat suggestion, tweaked filterModuleSummaries method in DataFetcherManager class to accept multiple keywords to filter against. For now, I put some sample keywords in a constant MODULE_FILTER_KEYWORDS in the same class. We can change it when we work on required modules?

"c/ new module code"

"t/ new tag"

Shift note abt command formats to Command Summary section

Linked to #164

Approved by 2101 tutor already.

Add support for "y" and "ye"

KIV

Add semester data to ModuleInfo + edit search command to print it out

KIV hanming

Explain more in UG maybe?

Add a check for equivalent modules to Module class, i.e. isEquivalent method or something

Take a look at isCancel in LogicManager.execute and YesCommand

Use isSameModule to check and display diff error msg

Duplicate of #153

Add case-insensitive check to UniqueTagMap's checkAndReplaceTags method

Create JSON file of equivalent modules (hashmap ds)

Change to parseDouble

Update: Change the Module --> Tag association from composition to navigability as discussed. Yes I made a typo in the commit LOL so I hope this clears confusion

I think you should keep "Developer".

I checked again, and I think you missed out the find sales history feature under sales tracking.

I agree.

I think that this should be specified as a sub feature under list, so as to distinguish between all ingredients and a single ingredient.

Perhaps this archive employees contact details section should be grouped with the other employee contact details features?

I think this page will be continually updated, so we should include what we have done to the project so far - which would be the documentation section.

For the ingredient levels, it would be good and clearer to state the unit of measurement. You could add this to the description or edit the examples to show this is the case.

We are missing Feature 4.3 Find the sales history data based on date documentation.

Remove the bullet points in this section to standardise the description field for the features. Instead of starting with a noun, start with a verb (once again to standardise across the UG). Eg. Set the level ...

Since it's just one argument, requireNonNull(targetIndex) will do.

I think we should keep both. They will both be Phone objects, but with different prefixes.

Perhaps you can use requireAllNonNull(...) instead.

Should this be using .equals method instead to do the check?

You are missing empty lines in between the methods.

IngredientList should not be under AddressBook, as AddressBook should only be in charge of contact details.

Mismatched javadoc?

As mentioned earlier, functions and features relating to ingredients tracking should be abstracted out to its own classes (instead of being in AddressBook).

I assume this has yet to be implemented?

Incorrect test case? Should these be all throwing assertion errors instead? They should not be called as it is a default model stub that have all of the methods failing.

Should target be non null too?

Requires change to fit ArchiveList

Missing public attribute? Applies for all the other tests.

Unnecessary white space?

Is this an extra space?

Command is an abstract class, no super constructor is needed.

I think that perhaps naming the boolean isReset is better, so that there isn't a double negative. This is just a grammar comment.

No need to use String.format if there is nothing to format.

I think that they should be on the same line.

I see,, then it makes sense to use isNotAlreadyReset.

I think it is better to be placed on the same line to standardise with the other case statements.

Should be Unarchives as the command is singular

Is this an extra line?

Grammar: It is equivalent to *the person being archived) OR (having archived the person).

Could be better phrased as: "A Person whose archive status is true"

Similar to the above comment

Perhaps it should be views because a command is singular.

Can be combined by using requireAllNonNull, however, this is also fine.

Extra line

This can be placed in one line

spelling: should be archive

The command is s-update. Additional there should not be a colon after the command word.

extra fullstop

Oh, I am referring to the description. It should be "views a single ingredient ... ", since the command word is singular

I think it is better to keep it in one line, so that it is standardised with the other case statements.

Perhaps it is better to say View single ingredient?

Is this perhaps a wrong import line?

So you are suggesting that we keep the archived and not archived employees in the same contact list? OR will this list show only archived when passed in a archived list of employees?

Understood!

Should add underscore between the words. I believe this is part of the naming conventions

Instead of saying short form name, abbreviation would be better.

Saying OR search may not be that user-friendly?

Since you only stated one implementation, calling it Alternative 1 may not be that good? Since there was no other alternatives considered.

There are a lot of empty lines in this java file. Are they all necessary and can it be cleaned up?

Remember to delete this test if unused.

Incorrect javadoc? I'm reviewing based on the assumption that this command will find an employee by the tag.

I think FindTagCommandor FindByTagCommand would be more apt/ sounds better.

Same problem as the javadoc

So this is a different feature from the one listed in this PR?

Remove extra line.

I think it is better to add a blank line above this if-else block

Same comments as TodayCommand

Missing javadoc description

It's also missing a javadoc description

If the input was "9999999999999999999", it will cause a NumberFormatException as Integer.parseInt() is not able to parse such a number. So, perhaps you should catch if limit has been exceeded first? You can test this to check if it's true for your case, because it was for mine.

I think it is okay to leave out the parameters, but this is just a note.

Extra blank line?

Instead of using double negatives, this could be better phrased as " .., tags of length below 50 characters"

Should be phrased as "There are a total of ... "

Change to version 11

Could you restore this line? to indicate the start of the util methods.

hmm, I have also added this file, but differently... Will it affect your tests greatly, if mine could be used instead?

There is a spelling error in "ingredient"

Difference between these two functions?

Change the subheader to just "Implementation"

It should be restored below the setSalesRecordEntry method.

Did you mean "who is available to work"?

I think it is better to keep the order consistent. i.e Monday or Friday, instead of Friday or Monday. Applies to step 2 too

Suggestion: I think it is more intuitive to follow the ordering of the days of the week. i.e. Tuesday should come before Wednesday

I think that "computer's current date" is a better phrasing.

Consecutive words with "-ing" should not be placed together. Suggestion: remove "using"

There's only one example

Should this be placed in between the div line to show the blue box? Since this is additional information about the tags

Should this be placed in between the div line to show the blue box?

Should this be placed in between the div line to show the blue box? Perhaps you could also add something to say "notes" about what? Applies to all similar sections

I think the older version is better and less technical.

Add in a brief explanation. eg. "tCheck currently does not support the use of human-modifiable save files" etc.

The sentence doesn't sound fluent. Perhaps this could be better phrased? The last half of the sentence is grammatically incorrect.

"can only show"

I don't think you need the bullet point here, as there is only one point.

Similar to above comment on bullet point.

Remove bullet point here.

Similar for this, and other similar parts.

Should be "... changes to all ..."

Could be better phrased as such:

"Q: Why does tCheck ignore additional/ extra input that I add after single-word commands, like help"?

Additionally,

I think it should just be "input" instead of "inputs" since the entire line entered is the input?
it should be "a" instead of "the" in "after the single-word command"
if "input" is used, then "extra input does not affect ..." OR if "inputs" is used, then "extra inputs do not affect ..."

Should not be a question. A better phrasing is "How the command is processed"

Note: For all the examples, I think there is a need to first explain the user input in an earlier section - which I believe should be covered under wang qian's updates. If that is done, then this section should be ok

The sentences that contains "the situation is ... " is not fluent. Perhaps a better way to structure the sentence is: "there is an .... (describe the situation)". e.g change could be: "there is a duplication of valid prefixes." Alternatively, eg. "the situation faced is the duplication of valid prefixes". I prefer the first suggestion.

Oh, okay I understand. I also think I figured out why it didn't sound fluent to me. I believe the sentence should be structured as this instead: "the situation of duplicate valid prefixes is detected". It was to do with the ending, rather than pertaining to "situation".

Remove "Completed" in the sub-header. This was a recommendation from the peer review we did.

I think it should be "brand" not "branch". Additionally, I don't think we need to be so polite by using "please".

I think "all the six ingredients are pre-defined in tCheck's ingredient book." can be a sentence on its own.

Should be "display" instead of "displays", because "will ... display"

I'm not sure why, but I couldn't view the image when I was looking at this document in your branch. Did you remember to upload the image?

It should be "store" not "stall". Applies to the rest of this section

Should be "Manpower Management"

Typo for "first"

Perhaps using "User Guide" is better?

"an executable command". as "executable" starts with a vowel and thus uses "an"

Note: Not sure if a warning sign was used in the UG, perhaps we can discuss this.

I think that you are missing the "italics" format for the terms related to tCheck's GUI

Instead of "gives you...", "explains the ..." is a better choice of words.

I think you should describe it in more layman terms first. eg. "It is the input that follows behind a prefix". Then, give the explanation, that you have written here.

Missing fullstop at the end of the line

Instead of "gives you...", "explains the ..." is a better choice of words

Instead of "gives you...", "explains the ..." is a better choice of words.

Perhaps use "Employee Directory" instead of "employee directory", since it is referring to a particular section inside tCheck.

This can remain as "[Completed]". I was referring to the completed implementation subheader. Or do you think we can remove all the [completed] if our DG will only record completed implementation details?

No need to edit here as I have added it in my update. Alternatively, I guess it can be resolved during merge conflicts

Did you mean "re-enter the data in the correct format"?

I feel that this is too specific to the implementation.

Incorrect preposition. Should be "corresponds to"

I think that this is a better phrasing: "until the index entered is valid"

As mentioned earlier, this may be too specific to the implementation.

Should be "display" instead of "displays" because "will .... display"

Perhaps this should be "re-enter in the correct format"?

Should it still be "persons"?

This should be "from one computer to another"

I don't think we need to say this? It sounds like a feature to me. This can be discussed further.

Should be "... experience in ..."

Indeed, I will make that change. Thanks for the catch!

I have placed a blank line to separate the expected result and test case. In my opinion, there is a need for the blank line, but we could discuss this in the meeting to decide.

I think I was unclear because I put test cases for updating one drink and more than one drinks under the first one. I will separate them.

It may not be that direct. I will remove this section as I cannot explain it that accurately.

Yes, I will update that.

I don't think there is a need to do that, as it should be clear that this is a list of instructions, following line 130

Thanks for the reminder.

I think it should be clear as I mentioned Sales Tracker inside the Main View at the introduction of the sales-related features.

True, I have mentioned the list earlier in the sentence.

Sure, I will take this suggestion.

LGTM

Thank you for the feedback! We will create a better error message for the input regarding the number of drinks sold. This will help to differentiate the error between wrong prefix and wrong type of input for number of drinks sold.

Thank you for pointing this out! It was not that s-list did not work, but rather s-list will not reorder the list back to the previous order after s-rank has sorted the list. It would not affect how users can use the sales tracker. We will merge the two types of list into one list function to reduce redundancy.

Thank you for pointing this out! We will update the s-update function to refresh and show the newest list.

Thank you for pointing this out! However, this is a behaviour that has been inherited from AB3's implementation. We will not be changing this behaviour. However, we will update the UG to make this clear to the user.

Thank you for the feedback! We have decided to merge the s-list and s-rank function, so as to reduce the redundancy in the list function. s-update will still refresh the list but in no order while s-list will show the list in a descending order.

Thank you for pointing this out! We will add a limit to the maximum number that the s-update feature can use, and also check for integer overflow.

Thank you for pointing this out! We will add an upper limit to the number that the s-update feature can update, and also check for integer overflow.

Thank you for pointing this out! We will add a limit to the maximum number that the s-update feature can update, and also check for integer overflow.

Thank you for the suggestions!

We would like the user to be able to update multiple drink items at once. Using INDEX would not be able to meet that requirement of ours due to the implementation of AB3 that we have inherited from.
The GUI window has a minimum size, such that the GUI components can still be fully seen. We thought that this would be better than having a GUI where going beyond the minimum size would result in a weird view. Nonetheless, thanks for the suggestions and feedback!

i agree with jun da, i think changes to different parts of the project should be done in different branches. this is for clarity and ease of finding. might be a bit strange to see a branch merge for both ug and actual code.

for consistency across the entire codebase, i think it'll be better if you have your documentation written like this:


/**

 * Returns a trimmed predicateField. If...

 */

this documentation should be changed too!

there are 2 grammatical errors here - should be "an" instead of "a" and "its" instead of "it's".

also, can you change this reference from address book to Athena?

should be "an" instead of "a" event.

could be wrapped in an Optional instead (since you're doing so below anyway)

consider adding the NoSuchElementException thrown to the method signature

this should be spaced out to three lines

nope, just a personal preference.

do you have an example?

noted. i mentioned this because Parser.parse (and all its implementations) contain an unchecked exception in it's method signature.

this should be changed to match the new parsing structure, and a COMMAND_TYPE field should be added.

this is not implemented yet. perhaps it should be made a bit clearer (with a comment in the code maybe)?

this currently leads to bugs; if i put an index of 3, it'll still return the DESCRIPTION_COMPARATOR. i think you should have individual cases for each comparator, and then throw a ParseException in the default line.

although i think it would be better to have the detection of invalid inputs handled in SortEventCommandParser.parse.

yeah so i think the default branch in here should throw something like an IllegalArgumentException (for us to see, since this branch should never be reached), and the one in SortEventCommandParser.parse should throw a ParseException (for the user to see, if they input an invalid number).

"combines the" repeated twice

i think another punctuation mark would be better - maybe:

"Returns true if the tag is valid - that is, it has at least..."

i think our documentation is done in present tense, so using "cannot be found" would be more consistent than "could not be found". also, since "tags that could not be found" is repeated twice, maybe just rephrasing the entire sentence would be preferable, so something like:

"For tags that cannot be found, the string will reflect that by prepending the appropriate message."

slightly awkward; maybe use firstly/secondly/lastly?

new tagging sounds a bit weird, but this could be me. could you elaborate on what you mean?

tagTree should be enclosed in {@code } for consistency.

did you mean set of persons?

slight inconsistency; first line of documentation says the set returned falls under the given tag and all its sub-tags, but this line says or.

perhaps both these sentences could be combined into one.

i think "given" instead of "if" sounds better.

lacking capitalisation; also i think it should be personToCopy rather than persontocopy.

i think you meant "When relationships...".

i think using "which" instead of "whose" is more appropriate.

perhaps "cyclic dependencies"?

i think you should either connect both sentences with a comma (i would prefer this) or write "Returns false otherwise." in the second.

HashMaps?

Copies*

should these have documentation?

i don't think union is a verb.

who's jackson

should this be capitalised? actually should there be standardisation in how json is referred to? some documentation refer to it as JSON and some as Json.

gotcha.

makes sense.

hmm okay, i'll keep this in mind.

can you add whitespace similar to the one current Commands adopt?

slightly awkward because "add..." is usually followed by "to...". maybe use "create" instead of "add" or mention that you're adding it to Athena?

from what i've seen from the other classes, i believe this line should not end with a full stop

i think this sentence should end with "and returns an AddTagCommand object for execution."

does this imply that some tags (i assume highest parent level ones) are in addressBook but not tagTree?

arguments*

i think you're missing the word "use".

BooleanInputs*?

this information is outright incorrect. the fact that you've said something like this shows that you do not understand how the method works.

If it can't throw, the method should not have a throws keyword.

correct.

Which is not the same as "this method cannot throw a CommandException or a ParseException, handling can be ignored".

incorrect. because line 229 uses Logic.execute(), your method has to either implement a way to catch these exceptions by embedding it in a try-catch block, or simply put it in the signature. the problem with the former is that your catch block then cannot be empty, as if the exception is thrown by Logic.execute(), neither is a CommandResult returned nor an exception thrown. the reason you can put it in the signature is because, as the back-end programmer, you know that it will never throw this exception.

basically, the method can throw it but won't.

In the case where command word for show reminder is changed in the enum but not changed here, this method will throw a exception.

yes, but CommandException and ParseException are both for users. as the programmer, you are expected to make consistent changes across the codebase when one reference changes. to use either of those exceptions as a way to ascertain that is wrong.

Import enum CommandWord to avoid such incident. Implement catching and processing in case of an error, perhaps displaying an error message saying something like "reminders failed to show" in the resultPanel.

this is literally what line 231 does.

Do not follow executeIntroCommand() method above, its not a good implementation.

would you like to explain why? if you want to say this, at least have the courtesy to @ me. if you want to discuss the implementation i'm all ears, but i'd prefer that to you straight up, condescendingly and accusatively stating that "its [sic] not a good implementation".

fyi markdown's lists can accept 1's as indices and this helps you not have to keep track of how long the list is prior. could you undo it?

the lower case is intended as it's an emoji.

multiple is inclusive of zero.

sentences' connotations are the same.

i think this may not be correct as it implies that an INDEX is tied to a specific contact.

i think this may not be correct as it implies that an INDEX is tied to a specific contact.

this adds inconsistency as all the other sentences do not mention Athena before the verb.

i think this may not be correct as it implies that an INDEX is tied to a specific contact.

hmm, perhaps we should mention the DATE_TIME format at the start of the events instead of in the add command?

some inconsistency between this and the rest as they end with full stops.

if we split this into two separate points 'also' is unnecessary in the second sentence.

sentences' connotations are the same.

i think you missed this!

maybe add that it's your computer's CLI to differentiate it from the app? phrasing now makes it sound like there's one general CLI every computer uses.

hmm true... maybe you could write "multiple times (including zero)".

which*

think "Additionally" sounds better than of "Besides this".

think "However" is unnecessary as sentences before and after are not contrasting.

perhaps rephrase the second sentence to:

"Using Person class' isSamePerson(Person) method ensures that there are no duplicate contacts in Athena."

perhaps either of these would be better for the second sentence:

"It uses a hash map with Tags as keys that each store a set of Persons as its value."

"It uses a hash map, with Tags as keys and sets of Persons as values.

no ellipsis please

is it necessary to mention when the support was added?

also i think the last sentence sounds nicer as:

"Certain commands that affect a Tag may also affect its child-tags." (also maybe use a different word besides affect)

missing full stop

same as above

"provides a few defined methods" sounds weird. drop either "provides" or "defined"?

same as above

"The methods listed above illustrate the difficulty of preserving consistency within the system."

"In particular, the method deleteTag is..."

"The sequence diagram below illustrates..."

maybe remove "also"? something's weird with this one but i can't quite put my finger on it.

remove "if possible" to sound more confident in our implementation

add a comma between AddressBook and so

"To ensure that the right commands are called at the right time, Model only implements a limited set of methods that can change the internal mapping."

variety*, also, "... correct methods from either AddressBook, TagTree or ContactTagIntegrationManager are chosen."

is this necessary

nothing to correct here i just wanted to say that this is really well-written

no ellipsis please, just use etc

"Suppose we delete a single Tag, the parent-tags..."

to a set?

okay!

should this just be SHOW? none of the other commands are attached to the type of functionality they target.

"an" instead of "the"?

i think this should end with a full stop.

i think this should also end with a full stop.

this documentation should be updated

missing full stop

this documentation should be updated

this documentation style seems inconsistent with the rest of the UG.

i meant the use of "=" is inconsistent.

should be "Changes... to..."

if the*? also should this be in present tense since the first sentence is also in present tense?

i think this straight up breaks the parser as it relies on this field to check if the input format is correct. i think this branch should only be merged when we actually change isValidTime and parse below.

sorry, this is a misinterpretation on my part.

i think this is inconsistent with the actual pattern below.

you might want to write your full name here i think it's what everyone else is doing

fyi markdown lists can have all indices be 1

naming is a bit weird... one is before-behaviour and the other behaviour-after

your pr says 247 but links to 242

i... do not think it's grammatically correct for there to be a space before the colon

within 4 days of*

[field] adds, so i think these changes should be reverted.

good catch!

not {@code}?

ah i see. i do think that using a colon here still looks weird. perhaps we could change them to hyphens instead? that way, it would also be consistent with the table of contents.

ah okay. thanks for clarifying.

agreed, or maybe deleteByTag (although that also sounds like a mouthful). the ideal is for us to be able to group it under delete.

this documentation should be updated

hmm, interestingly this is also something that i had issues with. i avoided using AddressBookParser.COMMAND_TYPE as i did not want to create further cyclic dependencies (AddContactCommandParser -> AddContactCommand -> AddressBookParser -> AddContactCommandParser).

a plausible solution would to be to create an enumeration to only store command words/types and for all command classes to reference that instead, so the test cases can remain untouched.

agreed. i will change these when the above conversation has been resolved.

the implementation would be to create two enumerations - CommandWord and CommandType - and have AddressBookParser and the Command classes refer to the enumeration instead. this accomplishes two things:

resolves the aforementioned cyclic dependencies.
test cases can remain as is, since they currently refer to each individual Command class' word/type.

i think there is merit in having the test cases remain in their current classes as they are intended to test certain classes.

My suggestion was actually to not have this at all.

hmm, what would you propose then?

fixed

good call.

yep, this is handled in the BooleanInput class.

good catch! i will do so.

haha, i ran the tests again to ensure nothing else was affected.

Use cases to be compartmentalised by individual member.

Introduction not added, reopened

Resolves #82 and #83.

We have elected to update the UG for two reasons:

Consistency - some of the event methods end with an s while others do not. While this was intended to represent the plurality of some of the returns, this can be confusing for users unfamiliar with Athena. Additionally, to standardise methods between contacts and events, we should use the similarly worded commands for both. Since list is already implemented as a contact feature, we'll stick to listEvent.
Convenience - the documentation of listEvent in the UG is incorrect to begin with. Instead of having to correct both the method and the UG (to listEvents), we instead change only the UG.

I will update the UG by tomorrow to fix these inconsistencies.

I suspect it is possible to store this information in a file that already exists in the codebase, as changes to the GUI are saved through different sessions. It is likely that the same file can be used to store this information.

For clarity, this is unlikely to require large-scale changes across the codebase, as existing classes can be used. Instead, the parser will be changed to support the new command structure.

Turns out it's just a macOS quirk. Perhaps this will be implemented in the future, when there are other forms of state saving required.

Looks good to me. I'm just wondering how the TagManager class helps to keep track of the participants (persons) of a particular event without implementing necessary changes in Calendar class or respective events class?

i don't think it's supposed to. this class is just a means to implement better Tag management-related features. the intermediary between contact- and event-functionalities have yet to be implemented.

i think we can give the user the option to capitalise their Tags and use regex to ignore case sensitivity in our searches.

i see your point, but i think the best solution is just to include a way for them to edit their tags after they've been created. as a user, i would not like having to be forced into using a certain case (be it upper or lower), as different cases can add nuance to the tags.

Enumerations added (see conversation with @chan-j-d above for more details).

fixes for this will be rolled out when the new GUI is done.

lgtm - good job!

i will implement this alongside #118.

closed and split into #129 and #130.

in adding these test cases I had to add a few other classes - EventBuilder, EventUtil and EditEventDescriptorBuilder. you may find these classes helpful in constructing your own test cases.

i think you need to comment directly on that person's ped repo or they can't see it.

although i can see where you are coming from, i do not think we should restrict users from being able to create extremely similar contacts. i also don't think it's a bug - a user should have the flexibility to be able to add whatever they desire to the address book. it may seem counter intuitive but i think this decision should be left to the user rather than an seemingly arbitrary restriction by the designers. unless anyone else has strong objections this is closed.

closed; an issue very similar to this was addressed in #211

this should be a relatively quick fix.

this is a good catch, but wouldn't your changes exclude an entry like 31-1-20?

i realise that many test cases actually test for this and use the last input, meaning that this is an intended feature. it'd be more appropriate to explicitly state this in the user guide rather than changing the code.

Should we standardize comments? One possible style:

Separate-line comment with whitespace, singular verb, and uppercase 1st character.


// Parses user input...

Command command = addressBookParser.parseCommand(commandText);

Same-line comment with whitespace, singular verb, and lowercase 1st character.


Command command = addressBookParser.parseCommand(commandText); // parses user input...

We could follow any other style too. Just thought it might be better for everyone to stick to 1 for consistency.

Sure, we can restore this when we complete EditCommand.

Really like the regex here. It is simple and effective.

I know this is a bit late, but do you think we should change AddPersonCommand to AddPatientCommand?

I think our Person refers specifically to Patient since we have the periodOfStay field. If we are adding a Staff class in the future, it may be a little misleading since Staff is a Person too.

What do you think?

Since we are using Patient now, maybe we can rename some of these variables?

Perhaps from MESSAGE_INVALID_PERSON_DISPLAYED_INDEX to MESSAGE_INVALID_PATIENT_DISPLAYED_NAME.

Also, do you think we should change our usage of "person" to "patient"? 🤔

i.e. "The patient name..." instead.

I like the use of guard clauses in this method. Makes the code much cleaner 😀

Great work on writing the unit tests! For v1.1, we might not need it but getting it done earlier is a nice bonus.

Maybe it could be invalidPatientName instead? I know it might be a little troublesome to change all references to Person to Patient. I can help with that if you would like.

For separate-line comments, do you think we should keep the first character in uppercase?

The Java coding standard we are using does not explicitly mention it but seems to follow that. I think comments that start with keywords may not need to be capitalized though (e.g. null).

I think "list of patient/all patients that match the specified criteria" may be clearer?

Great use of Optional here!

Do you think an Enum may be preferable here since there are a limited number of possible values?

Using int is not very scalable. If we have 10 different search conditions, we would need 10 int, and it can be hard to keep track of these variables.

Perhaps we can declare a nested Enum:


private enum SearchCondition {

    SEARCH_BY_NAME.

    SEARCH_BY_TEMPERATURE,

    SEARCH_CONDITION_INVALID; // no condition or multiple conditions given

}

If you would like to use int, maybe it would be better to make them static and change the variable names to indicate they are constants. E.g.


private static final int SEARCH_BY_NAME = 1;

Personally, I think Enum might be neater. 😄

Maybe we can add a space here? "TEMPERATURE RANGE " instead of "TEMPERATURRANGE".

This text will be displayed to the user, and the former may be easier to read?

Maybe one private method for each search condition? That would be great.

I'm not too sure but I think the execution will not reach this return statement? If that is the case, I think we can throw a CommandException instead of returning null? Returning null here may cause a NullPointerException somewhere else.

Perhaps we can rename this method to confirmSearchConditions or determineSearchCriteria? area may not be very clear that we are referring to the search conditions.

JavaDoc comments here are really useful to understand the purpose of the nested class. Great work 👍

@itssodium Could you check whether these changes are correct?

If I am not wrong, the Covigent part is the latest edit. It might have been overwritten by accident.

Would you be able to undo the deletion of this file? DateTimeUtil.java was recently added to manage dates and times.

Perhaps we could name this AddRoomCommand instead?

AddNumberOfRoomsCommand seems a little verbose since the number of rooms is implied, though this is a matter of preference.

If you like AddNumberOfRoomsCommand better, let's keep that.

Similarly, perhaps we could rename the command to addroom.

I think it's great that you refactored the code used for I/O. I/O should be abstracted if possible (SRP) since this class mainly handles the adding of the room.

Maybe we can follow the convention here? For messages, Address Book Level 3 follows this convention: MESSAGE_ERROR or MESSAGE_SUCCESS. We could use MESSAGE_NUMBER_OF_ROOMS_UNDEFINED or something along those lines here for consistency.

Would be good to add a comment here if the -1 means something.

Similarly, we can follow the conventions for messages here.

It is less about whether the user will enter a negative number, and more about how we should secure our application.

Personally, I feel that it is good if we can handle as many exceptional cases (sometimes called edge cases) as possible. Without proper handling, anyone can crash the app simply by entering a negative number. It can be annoying for the user if they accidentally type in a negative number and the app just stops working.

Besides, near the end of the semester, our application will be manually tested for bugs. I am fairly sure the testers will try to use negative numbers as inputs. If they can cause the application to crash, they will flag the problem as a bug and deduct our marks for it. Let's do our best to stop that from happening! 😄

May I ask what is the reason for naming the class RoomBook instead of RoomList or RoomQueue? I feel that Book does not explain what the class does.

Would it not be possible to use an ArrayList>Room>?

I think it is easier to understand if you iterate through all the Room objects in a loop and call an isEmpty() method to determine which Room is empty.

Performance-wise, I understand PriorityQueue may be better but we are sacrificing code clarity for performance.

Shouldn't Room contain an ArrayList>Task>?

@itssodium Would you be able to check this?

Do you mean it will be used for allocating the Patient to the Room?

Okay, leave this part to me. I will add in the TaskList.

Would it be possible to use Optional>Patient> here? While it is true that the Room can have no Patient, it is best to avoid null.

Great that you have a separate class for storage!

I think that is probably the temporary files used for testing? 🤣 Shall we rename the test files?

Yup, Address Book Level 3 has a convention for the names of test cases. Maybe we can follow that next time?

Ohh okay I follow your train of thoughts now. For adding Patient to Room, I think we should be more explicit? Maybe something like AddPatientToRoom.

I think you can use AddRoom for this.

May I check if URI is used here? I think path is a String and URI may not be needed here?

I think it would be good if you could leave a comment to explain the use of the nr and ro options!

Would it be possible to split this test into smaller units? It is currently longer than 30 lines.

Perhaps this part


        rooms = new PriorityQueue<>();

        for (int i = 0; i < 10; i++) {

            Room room = new Room(i + 1);

            if (i % 2 == 0) {

                room.setOccupied(true);

            }

            rooms.add(room);

            roomsInArray[i] = room;

        }

        roomList = new RoomList(rooms, roomsInArray, 10);

        numberOfRooms = Paths.get("numberOfRooms");

        roomsOccupied = Paths.get("roomsOccupied");

        roomOccupancyStorage = new RoomOccupancyStorage(numberOfRooms, roomsOccupied);

        roomOccupancyStorage.saveNumberOfRooms(roomList, numberOfRooms);

        roomOccupancyStorage.saveOccupiedRooms(roomList, roomsOccupied);

        roomList1 = roomOccupancyStorage.readOnlyRoomOccupancy();

        assertEquals(roomList, roomList1);

can be in a separate test?

I think addRooms here refer to allocating a Patient to a Room? Most likely, this test would be in a separate class so maybe we can remove it first?

Don't worry, I can handle this part. 😄 I will have to integrate the TaskList into Room to get my part working anyway.

I think it would be good to leave an explanation of why numberOfRooms is initialized to -1.

Perhaps the messages here can be moved to another class? Ideally, we can avoid adding constants to this class since the messages are stored in seedu.address.commons.core.Messages instead. Maybe look into putting your messages there too?

I think IntelliJ might have changed this to wildcard imports? Maybe we can revert this?

Do you think we should keep the indentation consistent? For *.fxml files, maybe we can use 2 or 4 spaces (not sure what the original is).

I think it would be patients here. Very minor grammatical issue though 😄

I like how there is an order for the different types of entities (patients followed by rooms followed by miscellaneous). Maybe in the future, we can a header to each entity to further organize the content of our user guide? E.g.


3.1 [Command Format](#31-command-format)<br>

3.2 [Patients](<Section explaining what Patients are>)<br>

     3.2.1 [Add a patient: `addpatient`](#32-add-a-patient-addpatient)<br>

// ...

Do you think we should standardize this? Not sure if it is as important in the JavaDocs because it is understandable, but what about the user guide?

Should we refer to the application as the app, the application, or Covigent?

Thank you for noticing and changing this! 😄

Because isSamePatient(...) uses name, age, and phone number as criteria to detect duplicate Patient in a list, will this not pose a problem when deleting? It is possible to have more than 1 Patient with the same name after all. In that case, only the first matching Patient is deleted.

I think it may be a little strange that the user cannot select which Patient to delete if they share the same name. I am not sure about the optimal way to solve this problem. Would deleting by index be better?

Good job noticing the bug here! 😄

Maybe this can be renamed to indicate that an invalid search criterion has been provided. searchPatient does not really explain which aspect is being tested.

Something like execute_searchPatientInvalidSearchCriteria_throwsCommandException() may be good?

I think it would be good to mention something along the lines of how the command replaces the current number of rooms with the newly specified value. Also, whether the data in the current rooms will be migrated or reset.

We can always improve on the user guide in the future though, so maybe we can KIV? 😄

Since there are multiple files being checked, maybe we can include which data file is not in the correct format in the warning.

The same goes for the other warnings.

Maybe we can keep this statement in a single line such that it looks even neater? It has fewer than 110 characters and can fit in one line!

Perhaps we can remove code that is commented out. If we merge this, we may forget to remove it in the future. Also, commented out code seems like regular comments and may be difficult to locate in a large codebase.

Great work with the hashing!

May I ask why the 31 is needed here?

I think maybe we can make this more general and apply it all the other *List classes (UniquePatientList, RoomList, TaskList). Otherwise, I think the interface may not be needed?

Possibly ReadOnlyList>T>? We can do either:

Include all methods such as add, delete, etc. (much more work because we have to rename all methods to share a common name).
Include just the method to obtain a read-only list (easier).

Maybe we can add a TODO here to indicate that in the future, we should set the application default to having a few rooms with patients and tasks?

Although ObservableList and PriorityQueue maintain the same rooms, for safety would it be better to include a comparison for the ObservableList too?

The condition for this is rooms != null && roomList.rooms != null but I think neither the PriorityQueue nor ObservableList can be null because of the default value, right?

In that case, can you not just return false if any of the 2 PriorityQueue and 2 ObservableList are null?

Instead of tracking numOfRooms in a variable, would it be possible to just make use of the size of the ObservableList? Maybe include a method to get size (similar to the other *List classes).

This would reduce the complexity of the class, especially when writing the equals(...) or hashCode() method since there is one fewer variable to manage.

@JsonProperty tells the Jackson ObjectMapper to map the JSON property name to the annotated Java field's name so we end up with this:


"room": {

    "roomNumber": value

    "isOccupied": value

     //...

For consistency with JsonAdaptedPerson, perhaps we can keep it the same as the variable name (i.e. roomNumber and isOccupied)? We would have


public JsonAdaptedRoom(@JsonProperty("roomNumber") int roomNumber,

        @JsonProperty("isOccupied") boolean isOccupied) {

//...

We can add a TODO here since we are not using the Patient and Task in this class yet.

Consistent @JsonProperty here! Variable name should be rooms.

Good job with switching to temp folders! 😊

Maybe we can import java.util.Optional directly?

I think if we are not using this class currently, we can remove it 1st?

I will add this when I pull your changes 👍

Might be good to declare a constant for "-" to indicate what it is doing more clearly!

Might be difficult to switch here since there are multiple conditions.

I think the current structure is not too bad. Maybe we can rename clearRoom to isNewEmptyRoom for clarity? clearRoom sounds like the name of a method hahaha.

Also, I think isCurrentlyOccupied sounds more like a boolean. How about we use that instead of alreadyOccupied?

Instead of ...orElse(null) != null, maybe we can use editRoomDescriptor.getIsOccupied().isPresent()?

Would it be possible to combine case 1 and case 3 since both return Room(updatedRoomNumber)? 🤔

!hasNewPatient could be the condition.

Actually, I'm curious about why clearRoom is needed as a condition.

While not entirely linked to this PR, I think we should modify Room to store an Optional>Patient>. Then, we can remove the isOccupied boolean and use Optional>Patient>.isPresent() to find out whether a room is occupied.

I understand it may be easier to return an Integer but this method is similar to the parseIndex. We can use the Index class provided in the original codebase and use parseIndex instead.

That was what I did in AddTaskCommandParser 😆

Hmm if we modify RoomList directly from EditRoomCommand, we may be breaking a few abstraction barriers since Command will be interacting with RoomList.

To avoid this problem, we can add a setRoom(Room target, Room editedRoom) method to RoomList. Then, add another setRoom(Room target, Room editedRoom) method to Model (the interface). Finally, In ModelManager, call roomList.setRoom(...).

We can then use the setRoom(...) method by calling model.setRoom(...). So we are restricting the interactions between classes such that Command only interacts with RoomList via Model.

Does DuplicateRoom apply only to identical RoomNumber?

Thanks for adding this TODO! 👍

Wait, I see that setRoom has been done. Good job! In that case, why is the modifiable room list still needed?

Also, perhaps we can rename these methods to hasRoom(...) and setRoom(...) for consistency with Patient?

Okay, I see what you mean. For now, we are treating RoomNumber as an index but in the future we may allow the user to set their own room numbers.

Would it be convenient for you to move the room-related methods to RoomParserUtil?

If not, I could do that later because I intend to make ParserUtil an abstract class.

getRoomList() returns the ObservableList though. Wouldn't it be possible to check if the room is present from there?

I think one reason we would not want to return the RoomList is because it is mutable. That means that if we return RoomList from ModelManager, any other class can modify the content through RoomList (e.g. call roomList.addRooms(...)) instead of through the Model (i.e. call model.addRooms(...)).

getRoomList() returns a read-only list so we can prevent the contents of RoomList from being changed directly. In fact, I think that was the original intention behind the asUnmodifiableObservableList() method.

I think editroom command does not allow task to be edited right?

In that case, maybe we don't need to use editRoomDescriptor.getTaskList()?

Maybe it would be good to remove codes that we commented out? Otherwise, we may completely forget about it.

Perhaps the predicate could take on a more meaningful name. What about filterByRoomNumber or something along those lines?

Good job on reducing the number of ObservableList we need!

If we are changing that, I think we can make the method name clearer too. Maybe getFilterByRoomNumberPredicate()?

Let's look into resolving the TODOs in v1.3?

Just wanna check if stylesheets need to be set to each of the element? If I am not wrong, as long as you set stylesheets to ScrollPane, the rest of the elements should inherit the CSS accordingly?

For multiple non-null args, we can use requireAllNonNull(...) instead to shorten the code!

Maybe can explain why this statement is necessary here?

Great work using a listener to update the UI for Room!

Would it not be possible to use getPatientWithName instead? I feel like that may significantly reduce the amount of code that we need.

Might be good to add a comment there to indicate that it refreshes UI.

I think the patient name is the identifier for a patient right? In that case, wouldn't it better to avoid using the Index class?

Would you like to switch to getRoomList() here? We will eventually remove getModifiableRoomList.

If I am not wrong, the two methods getPatientIndex() and getPatientFromIndex() are used in the EditPatientCommand class, right?

Instead of this


        Index index = model.getPatientIndex(patientToBeEdited);



        if (index.getZeroBased() == 0) {

            throw new CommandException(Messages.MESSAGE_INVALID_PATIENT_NAME_INPUT);

        }



        Patient patientToEdit = model.getPatientFromIndex(Index.fromZeroBased(index.getZeroBased() - 1));

Would it not be cleaner to do this in EditPatientCommand?


        Optional<Patient> optionalPatient  = model.getPatientWithName(patientToBeEdited);



        // Better still, use Patient patientToEdit = optionalPatient.orElseThrow(...). I forgot the syntax hahaha.

        if (!optionalPatient.isPresent()) {

            throw new CommandException(Messages.MESSAGE_INVALID_PATIENT_NAME_INPUT);

        }



        Patient patientToEdit = optionalPatient.get();

That way, we avoid using Index altogether.

Oh yeah, this wouldn't work if you use the unmodifiable version. Feels like using the modifiable version is a hack though hahaha.

Actually, we probably should have another class similar to PatientRecord to interact with RoomList. Add, delete, set are done through PatientRecord right now. I think it's fine for now though. Maybe add a note to move this method to the new class once it is set up.

Maybe we can standardize the casing for file names (i.e. logo.png).

I would like to check if we are changing the colour scheme of the UI. I think #2b5c7b is the one we are using in our mock-up.

Since we are removing the menu, I think you can remove the corresponding CSS too!

Maybe keep the format for the comments consistent.

// Set images ...

Do you think setAccelerator() can be removed too?

If we are removing the menu, I think the exit button will disppear too, right?

Similarly, this might not be needed anymore.

Is it necessary to cast to (int) here. count() should return an int I think.

Hmm I think maybe model.canFit() can be renamed? It is difficult to understand what that method does. Perhaps hasSpaceForRooms()? Same for the other canFit() methods.

Do you think setRoom() would be clearer here?

Would you like to rename this to RoomRecords to keep it consistent with PatientRecords?

Noticed the defensive programming here 👍

An alternative is to check using regex. [\\p{Alnum}]{1, 150} should do the trick.

Yup, this should be removed.

It will throw an AssertionError when RoomList does not contain room. The method actually stills work without the assertion. That said, when we are calling from logic, the room passed to this method should be in the RoomList.

The assertion warns the developers when room is not in RoomList.

Added the line separator!

Do you think it would be cleaner if we kept this error message in InitRoomCommandParser since it is specific to the command?

I think the method name can be the same here? setPreferredNumOfRooms seems okay to me.

Maybe it would be possible to use the Index class here. Create an Index object from roomNumber and use it for the list operations.

This avoids "magic numbers", i.e. the -1 does not keep appearing.

Would be good to define 5000 as a constant MAX_NUM_OF_ROOM!

Good negative test case!

We may want to use verbs for the name of methods to make it clearer? getNumOfOccupiedRooms()?

May also want to make the Javadocs for this method clearer.

I think you can use rename roomList1 to expectedRoomList to highlight the difference between the 2 RoomList. Same for the other test cases!

Really glad we finally got it to work!

Let's try not to expose RoomTasks to other classes? Adding a getter here would allow other classes to get RoomTasks from Room and add any tasks to it. We can make the tasks read-only by exposing only getReadOnlyTasks. Do see my comment below too.

It is possible to use new RoomTasks(roomToClear.getReadOnlyTasks()) instead to avoid adding a getter!

This is a smart way to listen to changes in the list of tasks in room! 👍

Okay, noted on this. I will make the change. Thanks!

Agreed! Let's remove the additional fields.

Yes, right you are! I will change this.

Interestingly, yyyyMd does not work.

Consider the date "12 Jan 2020", for instance. With yyyyMd, it would be "2020112". But this string is ambiguous. Are we referring to "2 Nov 2020" or "12 Jan 2020"?

If we want to use yyyyMd, we would need a delimiter (e.g. yyyy-M-d). I decided against using the hyphen because it doesn't read as well when it is a date range.

Actually, yeah. It is probably not needed for an MVP.

The rationale behind adding DateTimeCreated is to allow the user to filter tasks with creation date as a criterion. For example, in Slack, users can see when the task is created. It is helpful when the user wants to query what tasks were created yesterday or within the last few days.

Right now, the plan is for the user to click on a Room in order to view all tasks assigned to it. There is no separate tab for the users to manage tasks (we should probably have this to show user which tasks from which rooms are due?). In the future, when we implement reminders or a search for tasks, DateTimeCreated might be more useful.

I think I will remove this from the MVP. Unit testing for this class also requires more work because we would need another layer of abstraction to handle and control the date-time instead of using LocalDateTime.now().

Thoughts on this?

Okay!

Nope, it is in an entirely different file. That said, I wonder if it will be confusing for the user?

No problem!

I think p/ is good 😄 We can try to keep it as short and sweet as possible since that's easier to remember.

Good point. Will use that instead 👍

It is missing the success case actually. Will need to set up a stub to perform the test. Will KIV 1st.

Hmm could you clarify on this? I think most of the other Command classes handle add, delete, and update through Model. The Model is the abstraction.

Good point. We should change the names of the tests here!

Yes, @LeeMingDe mentioned this too!

Hmm... Should it be in alphabetical order? I was thinking maybe it should be sorted by the type. We can have Patient, followed by Room, then Task.


3.2 Patient

    3.2.1 Add Patient

    3.2.2 Delete Patient

      ...

3.3 Room

    3.3.1 Initialize Rooms

      ...

3.4 Task

    3.4.1 Add Task

    3.4.2 Delete Task

The current arrangement is like this: the methods that are common to Patient, Room, and Task are placed into ParserUtil. Task-specific methods such as parseDescription are in TaskParserUtil.

Good observation!

Oh I decided to group the success cases together. Might indeed be neater to space them out.

roomNumber cannot actually be null though, because it is a primitive (i.e. int).

Yup that's true. Good observation here 😄

That said, assertions may not necessarily be enabled, especially when an application goes into production.

The roomNumber > 0 check is to prevent the application from crashing if this method somehow gets called when assertions are off.

Yup, I think the app is meant to crash in that case. model.getTaskFromRoomWithTaskIndex(taskIndex, room) should return either an empty Optional or an Optional-wrapped task. It should never be null here.

The app will crash with a NullPointerException if taskToDelete is null either way.

Yup, it will crash the app provided assertions are enabled. If getRoomWithRoomNumber(...) is called with a roomNumber greater than 0, it would be a programming error. Crashing in that case is helpful for debugging.

@itssodium would you like to close this PR? I think we could keep the other one instead?

Good work! We will have to correct the CheckStyle problems in order to merge. Would you be able to change the order of imports?

We have decided to close this issue. Don't worry about creating the pull request from master.

For future pull requests, remember that every new feature should be done in a separate branch!

Task models are added 1st. Will be integrated with Room in v1.2.

While not ideal, I decided to force push to my own repo in order to squash the commits that contained only minor changes for CheckStyle compliance.

I will be more careful when pushing to my repo in the future.

Overall, clean and neat code! Believe you haven't integrated the command into the code yet but seems like good support for your command for now. One thing though, I am not sure why you want to have a DateTimeCreated for task? Anyway, LGTM!

Haha, yeah I set up the PR to update everyone with my progress. The integration is not complete yet. I will request for more reviews when the integration is done.

To fix your addressbook and let it show its contacts, follow these steps:

Go to your data folder

Open up addressbook.json

In the second line, change "persons" to "patients"

I recommend deleting data/addressbook.json if you have not added any custom data. Upon restarting the app, the file should be regenerated.

Additionally, the logic in readAndSaveRoomList unit tests may be difficult to follow without comments. Do you think it would be possible to add


// Save in new file and read back

RoomOccupancyStorage roomOccupancyStorage = new RoomOccupancyStorage(numberOfRooms, roomsOccupied);

// ...

to indicate that you are saving and loading the file for testing?

There is also some code duplication in the readAndSaveRoomList tests, which we can consider refactoring into private methods.

I removed the link to #58 because we haven't actually displayed the Patient and Task details for each room. We can definitely merge 1st though.

Rebased to avoid additional merge commit.

lgtm, good job! However, the pr is super long, would it be better to like split it up in the future? eg. do the tasklist/task class and merge it first. then the addTask command and then merge it?

Totally agree with this. Ideally, I think a PR should not exceed 500 lines. It is difficult to review the PR when it is that long. I originally wanted to split this as well. Will definitely do so in the future! 👍

getRoomWithRoomNumber has been implemented in #115. Can use that for EditRoom too.

Duplicate tasks are allowed!


* Tertiary student


| `* * *`  | user              | set a monthly spending limit    | track how much I have left to spend for the month                      |

Don't commit .iml files.


* **Tools**:

Newline at EOF.

parseEmail should be renamed to parseDate with the corresponding parameter renamed. Same for all other instances.

parseTag should be renamed to parseCategory with the corresponding parameter renamed. Same for all other instances.

parsePhone should be renamed to parseAmount with the corresponding parameter renamed. Same for all other instances.


     * Parses an {@code String amount} into a {@code Amount}.


     * @throws ParseException if the given {@code amount} is invalid.


     * @throws ParseException if the given {@code date} is invalid.


     * Parses a {@code String category} into a {@code Category}.


     * @throws ParseException if the given {@code category} is invalid.


     * Parses {@code Collection<String> categories} into a {@code Set<Category>}.

parseTags should be renamed to parseCategories with the corresponding parameter renamed. Same for all other instances.


The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `TransactionListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class.


<div markdown="span" class="alert alert-info">:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Category` list in the `AddressBook`, which `Transaction` references. This allows `AddressBook` to only require one `Category` object per unique `Category`, instead of each `Transaction` needing their own `Category` object.<br>


ecp -&gt; ec ++: index, editPersonDescriptor

Let's update the diagrams at a later stage.


Simply add the following to [`seedu.address.ui.PersonCard`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-0c6b6abcfac8c205e075294f25e851fe).

Let's revert this change since we will most likely be deleting tutorials eventually.


       Person editedPerson = createEditedPerson(personToEdit, editPersonDescriptor);

Could you import EditCommand.EditTransactionDescriptor instead?


 * Adds an income to the finance tracker.

The command result display is not big enough to display everything, nor can it be scrolled. Instead, the words are just cut off.

Should something else be used instead of menu? Having to click the Menu, then the MenuItem for tabs is very clunky. An alternative is JavaFX TabPane.

I don't think the help menu should be grouped with the other options as the other options are tab headers while the help menu is a menu.

This extra line break can be removed.


     * Opens the analytics window.

Missing full stop.

panelLabel does not seem to correctly reflect the chosen tab.

Note how Income is selected, yet the label displays Expense.

If the JavaFX TabPane were used, I don't think you need to write such hacky code.


     * Creates an {@code ExpensePanel} with the given {@code ObservableList}.

Should this class be dealing with Expense objects instead of Transaction objects?


     * Creates an {@code IncomePanel} with the given {@code ObservableList}.

Should this class be dealing with Income objects instead of Transaction objects?

Any reason why these imports aren't grouped with the others?

Move this import up with the other imports, and leave a line after the last import.

This might be due to the bug found by @zhaojj2209 whereby switching tabs works only for the first time since the application was started.

Unable to reliably replicate this. I'll close this comment for now and keep and eye for this bug occurring in the future.

@siddarth2824 will be addressing this in a separate PR.

See https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/75#discussion_r501141034.

This will be changed in a future PR once the Expense model is more fleshed out.

This will be changed in a future PR once the Income model is more fleshed out.

Add full stops? Same for the other comments.

Possible to add backticks to parts which reference code? i.e. AddCommand


            + ": Deletes the expense identified by the index number used in the displayed expense list.\n"


            + ": Deletes the income identified by the index number used in the displayed income list.\n"


 * Deletes an income identified using its displayed index from the finance tracker.


 * Deletes an expense identified using its displayed index from the finance tracker.

Currently, these specific success messages are being shown. Should these be removed?

This value depends on the number of entries in our test data though. How do you propose we get around this without hard-coding?


    public void execute_showsAllExpenses() {

Sounds weird otherwise. 😕


    public void execute_showAllIncomes() {

Is this line break intended?


    - Edit find commands to be similar to edit commands e.g `find INDEX KEYWORD`

Should the date be set in the CNY period?

Perhaps bullet points detailing the behaviour of the command on each tab could be moved from the format section to the description section? @yongping827 what do you think?

Can getFilteredExpenseList return an ObservableList>Expense> instead?

Similarly, can getFilteredIncomeList return an ObservableList>Income> instead?

Can we enforce the subtypes within the list itself?

Use a more descriptive variable name.

Remove extra newline.

This is quite bad design. Perhaps we should just throw an error when executing any of the base commands which should never be executed?

Refer to issue #125.

Is this assertion necessary?

Similarly, is this necessary?


`JsonAdaptedExpense` and `JsonAdaptedIncome` are JSON-friendly adaptations of `Expense` and `Income` respectively.

Remove this extra newline?


     * Creates a {@code MonthlyBudget} with an expense limit and savings goal of $0.

Comment is not descriptive.


     * This guarantees that the elements of the FilteredList can successfully be cast to the target type.

     *

     * @param list The FilteredList to be cast.

Add an empty line between the description and parameter sections.

Add line breaks after every full stop. This will help us version control the document better. Same for the rest of the document.


Edits an expense in the finance tracker.


Edits an expense in the finance tracker.

Don't leave gaps in between for consistency with the other classes.

Since these are mostly the same, can they be generalised into a method? Or will these diverse significantly in the future?

Reorder the imports to be alphabetical.


box BookmarkExpense UI_COLOR_T1


[->LogicManager: execute("convert-bookmark-expense 1 d/20/10/2020")


![Sequence Diagram of the Convert Bookmark Expense To Expense Feature](images/ConvertBookmarkExpenseSequenceDiagram.png)


adds a bookmark expense titled `Phone Bill` with amount `$60.00` and two categories `Utilities` and `Personal`.

Should we standardise Food & Drink to Food & Beverage?


        // multiple dates


            + "Inputting the date is optional. If no input is given for d/DATE, the current date will be used.\n"

Same for the other instances of this sentence.

Group this import with the others in alphabetical order.


     * Returns true if the {@code Amount} has a non-negative value.

Missing description of param.

Useless comment.

Try to make it more descriptive, I don't need a comment to tell me this is a constructor.

Should these statements be reordered to fit the subsections?

Add a space before this line so that the image isn't so cramped?


* `edit 2 t/Shopee Internship d/24/10/2020`


add-income t/Shopee Internship a/560 d/03/10/2020 c/Work


New income added: Shopee Internship Amount: $560.00 Date: 03/10/2020 Categories: [Internship]


Adds a new income titled `Shopee Internship`, with amount `$560.00`, date `03/10/2020`, and a single category `Internship`.

This line isn't very clear as to what it's for. 😕

If it is meant to be captions to the image, perhaps we could work out some styling to use that makes its purpose more obvious?

Same for the other captions.

To be resolved in a separate PR. Issue #256 opened.

Perhaps it would be better for this method to simple do the replaceAll, then pass removedExtraWhiteSpacesTitle into parseTitle? That way, we get less repetition of code.

Also, I believe whitespace is a single word.


        String removedExtraWhitespaceTitle = title.replaceAll("\\s{2,}", " ");

Can you add non-breaking spaces to all example code snippets for both the warnings? I'm afraid this might give rise to ambiguity.

Should this be made specific to either dates and/or months only? The given example doesn't quite apply to year.


    public static final String MESSAGE_CONSTRAINTS = "Dates should be a valid calendar date of the format dd/mm/yyyy, "

Just in case someone enters 30/02/2020 and files a bug report stating that the error message is not informative?

That would be good I think. We can properly define what a valid calendar date is in the user guide.

Sounds good! 👍

Possible to link to the various issues?

Would be good to use :jack_o_lantern: and :ghost: instead.

Minutes does not appear in the list because the front matter is missing.


date: 2020-10-31

Wrong date.


- Got a time traveller on our hands [#246](https://github.com/AY2021S1-CS2103T-W16-3/tp/issues/246)

Broken link.

Should there be a reference made to the clear command under quick start? Seems weird to have this all the way at the bottom.

This was originally broken up into 2 lines as the final submission has to be a PDF file. When written in a single line, the code block is displayed with a horizontal scrollbar that results in the line being cut off in PDF format.

As a side note, there are multiple other instances in the user guide where code blocks are too long and get truncated after converting to PDF.


  Any leading/trailing whitespaces will be ignored. e.g. `add t/   Bubble Tea` and `add t/Bubble Tea   ` will be treated as `add t/Bubble Tea`.

Searches for all expenses with titles containing the specified TITLE_KEYPHRASE keyphrase exactly.

Partial matches are accepted. e.g. t/Snack will match Snacks

Do these two statements contradict each other?

Inconsistent use of full stops.

The message displayed in the application uses t/KEYWORD instead of t/TITLE_KEYPHRASE.

Same issues here as highlighted above.

No more CELC definitions?

Should we use the plural form when there are multiple pull requests?

Should there be a break statement? Otherwise, hasEmptyTitleKeyphrase merely depends on the last element in titleKeyphrases.

Similar issue here as above.

The following error is thrown when find t/ t/hello is input.


INFO: ----------------[USER COMMAND][find t/ t/hello]

Nov 06, 2020 7:38:43 PM ay2021s1_cs2103_w16_3.finesse.logic.parser.FinanceTrackerParser parseCommand

INFO: ----------------[CURRENT TAB][overview]

Exception in thread "JavaFX Application Thread" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException

        at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1787)

        at javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(FXMLLoader.java:1670)

        at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)

        at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)

        at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)

        at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)

        at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)

        at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)

        at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)

        at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)

        at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)

        at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)

        at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)

        at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)

        at javafx.event.Event.fireEvent(Event.java:198)

        at javafx.scene.Node.fireEvent(Node.java:8879)

        at com.sun.javafx.scene.control.behavior.TextFieldBehavior.fire(TextFieldBehavior.java:184)

        at com.sun.javafx.scene.control.behavior.TextInputControlBehavior.lambda$keyMapping$62(TextInputControlBehavior.java:330)

        at com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)

        at com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)

        at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)

        at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)

        at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)

        at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)

        at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)

        at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)

        at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)

        at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)

        at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)

        at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)

        at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)

        at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)

        at javafx.event.Event.fireEvent(Event.java:198)

        at javafx.scene.Scene$KeyHandler.process(Scene.java:4058)

        at javafx.scene.Scene$KeyHandler.access$1500(Scene.java:4004)

        at javafx.scene.Scene.processKeyEvent(Scene.java:2121)

        at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2595)

        at com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:217)

        at com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:149)

        at java.base/java.security.AccessController.doPrivileged(Native Method)

        at com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleKeyEvent$1(GlassViewEventHandler.java:248)

        at com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:390)

        at com.sun.javafx.tk.quantum.GlassViewEventHandler.handleKeyEvent(GlassViewEventHandler.java:247)

        at com.sun.glass.ui.View.handleKeyEvent(View.java:547)

        at com.sun.glass.ui.View.notifyKey(View.java:971)

        at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)

        at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)

        at java.base/java.lang.Thread.run(Thread.java:834)

Caused by: java.lang.reflect.InvocationTargetException

        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.base/java.lang.reflect.Method.invoke(Method.java:566)

        at com.sun.javafx.reflect.Trampoline.invoke(MethodUtil.java:76)

        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.base/java.lang.reflect.Method.invoke(Method.java:566)

        at com.sun.javafx.reflect.MethodUtil.invoke(MethodUtil.java:273)

        at com.sun.javafx.fxml.MethodHelper.invoke(MethodHelper.java:83)

        at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1784)

        ... 47 more

Caused by: java.lang.IllegalArgumentException: Keyphrase cannot be empty

        at ay2021s1_cs2103_w16_3.finesse.commons.util.AppUtil.checkArgument(AppUtil.java:39)

        at ay2021s1_cs2103_w16_3.finesse.commons.util.StringUtil.containsIgnoreCase(StringUtil.java:27)

        at ay2021s1_cs2103_w16_3.finesse.model.transaction.predicates.TitleContainsKeyphrasesPredicate.lambda$test$0(TitleContainsKeyphrasesPredicate.java:22)

        at java.base/java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90)

        at java.base/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1631)

        at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)

        at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)

        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)

        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)

        at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)

        at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)

        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)

        at java.base/java.util.stream.ReferencePipeline.anyMatch(ReferencePipeline.java:528)

        at ay2021s1_cs2103_w16_3.finesse.model.transaction.predicates.TitleContainsKeyphrasesPredicate.test(TitleContainsKeyphrasesPredicate.java:22)

        at ay2021s1_cs2103_w16_3.finesse.model.transaction.predicates.TitleContainsKeyphrasesPredicate.test(TitleContainsKeyphrasesPredicate.java:12)

        at java.base/java.util.function.Predicate.lambda$and$0(Predicate.java:69)

        at javafx.collections.transformation.FilteredList.refilter(FilteredList.java:332)

        at javafx.collections.transformation.FilteredList.access$000(FilteredList.java:50)

        at javafx.collections.transformation.FilteredList$1.invalidated(FilteredList.java:102)

        at javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:112)

        at javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:147)

        at javafx.collections.transformation.FilteredList.setPredicate(FilteredList.java:125)

        at ay2021s1_cs2103_w16_3.finesse.model.ModelManager.updateFilteredTransactionList(ModelManager.java:276)

        at ay2021s1_cs2103_w16_3.finesse.model.ModelManager.updateFilteredTransactionList(ModelManager.java:284)

        at ay2021s1_cs2103_w16_3.finesse.logic.commands.FindTransactionCommand.execute(FindTransactionCommand.java:22)

        at ay2021s1_cs2103_w16_3.finesse.logic.LogicManager.execute(LogicManager.java:52)

        at ay2021s1_cs2103_w16_3.finesse.ui.MainWindow.executeCommand(MainWindow.java:248)

        at ay2021s1_cs2103_w16_3.finesse.ui.CommandBox.handleCommandEntered(CommandBox.java:96)

        ... 59 more

Inconsistent indentation level with line 148.

Just to check, is the reason why a space is prepended so that you can chain these strings together? If so, perhaps it would be good to add a comment stating this.

Possible to add tests for partial title keyphrases too?

Any reason for prepending with a space here?

pitest can be added at a later time when we get around to achieving full coverage.

My bad, removed test.

I thought that the GITHUB_TOKEN secret was being blocked due to this PR being from a fork. Seems to also happen with branches on this repo. 😕

Apparently, GITHUB_TOKEN cannot be used; must be a GitHub user's personal access token.

Setting the baseurl to be the repo name is necessary for GitHub Pages to function.

CI job is able to run now. Tested on a branch of this repo as PRs from forks are unable to access secrets.

See https://github.com/AY2021S1-CS2103T-W16-3/tp/runs/1160121842.

@yongping827 The corresponding comment in AddIncomeCommandParser does not have a full stop, should I still add it?

This was left as such to mirror the corresponding change in #56. Can I confirm this is not intended?

Edit: Never mind, just saw https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/63#discussion_r499263026.

Full stops to be added separately. This is honestly very low priority.

Hmm, I went with ListTransactionCommand as the commands shouldn't have to care about the state of the UI; that's the job of the FinanceTrackerParser.

This comment is here because the contents of this file needs to correspond to the transactions created in TypicalTransactions. For the other test JSON files, they have no such dependency.

Believe it or not, the 3 line breaks here is for consistency with the rest of the file.

Pre-emptive logging so that any bugs reported in the future can be investigated.

Left -apple-system in so that if WebView ever gets fixed, everything starts working normally again.

If anyone can find a more CELC-friendly way of phrasing this without introducing any ambiguities, I'm all ears.

Could you point out where code is duplicated? I don't see any instances of code duplication.

Ah okay, I see now!

I was wondering why IntelliJ was throwing warnings for the pitest task in build.gradle. See https://github.com/szpak/gradle-pitest-plugin#eliminate-warning-in-idea. For documentation purposes only; I agree that this change feels less readable.

Requested for permission to use the external library at nus-cs2103-AY2021S1/forum#253.

LGTM!

While the current deployment process works with personal access tokens, @wltan brought up the point that we should have it work with the repository token GITHUB_TOKEN instead. This is a more ideal solution, especially if Prof Damith were to adopt the use of jekyll-spaceship.

Relative links are currently not working. Trying to find a fix.

PR has been picked up by the grading script.

Closed with #50.

Screenshots

Desktop:

Mobile:

Could you rebase to address merge conflicts before we start reviewing?

Issue seems to be caused by spaces in the file path.

Define the allowed inputs for Title and Category more explicitly in the user guide. The intricacies of the input validation cannot be captured within MESSAGE_CONSTRAINTS without making it unnecessarily verbose which is not user friendly.

See #130.

Pushed back to v1.4 so as to devote more time to developing and polishing features.

Related to #131.

Preview of user guide in Fine$$e:

As of this PR, all the links in the user guide are functional.

1234 is a perfectly valid input for the title parameter as stated in our user guide. It is merely an identifier of the transaction for the user and does not affect the functionality of the application in any way. As such, there is no "abuse of the application" going on.

Remove all abbreviation elements >abbr> from the user guide and write out the contents of these tags explicitly.

Not only does this confuse CELC, it also confuses our peers as seen in #243.

¥, £, and Ü are not in fact ASCII characters, let alone printable ASCII characters.

In addition, the list of printable ASCII characters was explicitly defined under section 4 of the user guide.

Add acknowledgements for all libraries used.

This is not a bug as the previous behaviour was WYSIWYG. Nevertheless, we will be replacing instances of multiple whitespace with a single whitespace to prevent issues such as this from being opened in the practical exam.

Add badge for license.

Resolved in #252.

I'm in favour of your suggestion with regards to CommandHistory. A singleton pattern makes sense here as there should only ever be one instance of CommandHistory. Very elegant! 👍

Add a note somewhere in the user guide that Fine$$e deals with transactions and not items. See https://github.com/AY2021S1-CS2103T-W16-3/tp/issues/238#issuecomment-721108856.

I think "the filename of the profile photo should be doc/images/githbub_username_in_lower_case.png" - Week 7 Point 2 in Project

Might wanna consider team/samlsm instead

Missing space before 4a.

Remove extra space

Missing "Use case ends."

Inconsistent comma, (+ EMAIL_DESC_BOB,)

'''//// student-related tests''' may work better here instead of Student, since we also have '''//// moduleClass-related tests'''

Extra space

See if its possible to trim down this part. I took a couple of tries before I understood what was going on

''' The {@code ModuleClass} must not exist in the current list '''

Don't quite understand this. Specifically, don't understand what is a backing list and what is meant by unmodifiable


    /** Returns an unmodifiable view of the filtered 

     * {@code ModuleClass} list.

     */


    // student-related constants


    // moduleClass-related constants

Need full stop for this comment

Comments start with lower letter + no full stops


        // workaround as storage functionality for ModuleClasses has not been implemented

Ok lets retain it in that case

Missing space


            + PREFIX_TELEGRAM + "johnDO3 "

Consider keeping the previous tag set? Because its more of an app to track students rather than keep address contacts.

I think the tagset got overwritten. Saw that you merged the master branch into your branch

Might be good if we remove the telegram prefix, since user has to type @ for email. So we might want to keep the design consistent by making them type @ for telegram handle

An alternative would be to update both the UG and DG to reflect the telegram handle changes.

I personally would go for the former than latter. How about the rest?

Any reasons why "student" was removed?

Extra white space

Any reasons for removing this white space?

Resolved by sticking to using TELEGRAM_PREFIX = "@"

Any reasons for removing this white space?

Resolved by adding back "student" in command


     * @param index Index of the class in the filtered class list to edit.


     * @param editModuleClassDescriptor Details to edit the class with.


        // short circuit if same object


        // instanceof handles nulls


        // state check


     * @throws ParseException If the user input does not conform the expected format.

I think the full stop got removed for some reasons.

My current updated code base has a full stop for this comment


 * Parses input arguments and creates a new FindStudentCommand object.

'''@throws ParseException If the user input does not conform the expected format.'''


            || (other instanceof ModuleNameContainsKeywordsPredicate // handles null)

start with lower case, e.g


        // one keyword


     * Returns an {@code EditModuleClassDescriptor} with fields containing {@code moduleClass}'s details.

Can you help center the fencing for the table?

Can you help organise/center the fencing "|" for the userguide table as well? I remembered centering it awhile back during v1.1 but seems like some of the fences got out of position again


Shows a list of all students and all classes in the application.

Might want to consider putting this after DeleteModuleClassCommand.COMMAND_WORD but before LinkCommand.COMMAND_WORD to maintain a fixed action sequence

"3" seems like a magic number across the test script. We might want to consider abstracting it into a variable in a separate PR

I think we should use Color since the naming before the change was Color

I agree with Dexter on this


     * Deletes the given {@code Student} and the {@code Student}'s {@code UUID} in all {@code ModuleClass}es.


     *  Deletes {@code key} from this {@code TutorsPet} and also the {@code UUID} of {@code Student} from all {@code ModuleClass}es.

Just to clarify, the reason why you create a new hashset is because the set returned by getStudentUuids() is immutable?


        // manually remove UUID

Is this change because if a student is deleted, then the associated student in ModuleClass is removed as well?

Extra space

Can we remove this space? Since line 17 and 19 are both messages

Space between line 15 and 16?

The words undone and redone are kinda awkward but I think its okay if we express it in that way, since it still gets the message across in a succinct manner


     * Creates a {@code StateRecords} with the specified {@code currentIndex} and {@code stateRecords}.

Extra space

I agree with Dexter on this. We can probably extract the CRUD operations to Logic instead of clustering everything in AttendanceRecordListTest.java

We can shift the CRUD here out to another class as well

Any reasons for this spacing?

Would recommend putting new back, since we are technically still generating a new Lesson

Nice assert


        Name moduleClassName= targetModuleClass.getName();


            + PREFIX_WEEK + "WEEK_NUMBER (must be a positive integer) "


            + "Note: All indexes must be positive integers.\n"

Swap line 91 and 92 for consistency


assert targetWeek != null;

Maybe keep the original?


            + "by the index number used in the displayed class list "


     * Adds all edited lessons in the target module class to the new module class.

We can consider adding this for AddLessonCommand and DeleteLessonCommand as well

👍🏻

Then we might have to do a full refactor for all occurrences and stick with it? Because from what i remember, many of the shorthand for loops do not have spaces


            + "Existing values will be overwritten by the input values.\n"

            "Note: All indexes must be positive integers.\n"

We can remove "must be a positive integer" from these 3 indexes to keep the formatting consistent with '''AddAttendanceCommand''' and '''DeleteAttendanceCommand'''

Can we separate the else if to another if guard clause to keep the format consistent?




        String message =

Separate guard clause




        if (!isModuleClassIndexPresent || !isLessonIndexPresent || !isStudentPresent || !isWeekPresent) {




        if (argMultimap.getValue(PREFIX_PARTICIPATION_SCORE).isPresent()) {

Thanks for the catch!

Can we abstract out these values like AddAttendanceCommandTest and DeleteAttendanceCommandTest?

E.g


Index moduleClassIndex = INDEX_FIRST_ITEM;

Index lessonIndex = INDEX_FIRST_ITEM;

Index studentIndex = INDEX_FIRST_ITEM;

Week targetWeek = VALID_WEEK_1;



assertThrows(NullPointerException.class, () -&gt; new DeleteAttendanceCommand(

       null, lessonIndex, studentIndex, targetWeek));

Nice catch!

Can i check why is there a change to getOneBased() ?

Can update the above '''/'''s to ''''''

Sry, is there a reason why this is being replaced?

I see!

Should we add in null tests for the other test cases as well?

Would it be good to keep this? Because there might be multiple aspects to a feature


Users should not have to type in attendance-related commands when the student is absent from a lesson.

I'll send in a separate PR to update my pros and cons section as well. Lets follow your style of having the pros and cons as individual pointers rather than paragraphs


            + "Note: All indexes and numbers must be positive integers.\n"

Should we show her the different themes as well? E.g using screenshots

Not very sure but I think the name of this puml should be DeleteStudentSequenceDiagram.puml?

Was thinking of the different themes (ie light, alternate, dark) and not just the buttons alone. What do you think?

Is this excess whitespace?

Logic here looks correct to me


## Other Contributions


* A list of all PRs I have reviewed can be found [here](https://github.com/AY2021S1-CS2103T-T10-4/tp/pulls?q=is%3Apr+reviewed-by%3Aruixuantan).


My team, comprising 5 NUS Computer Science undergraduates, developed the application over the course of 6 weeks.

^ See if its better


* `edit-attendance` command feature. [#157](https://github.com/AY2021S1-CS2103T-T10-4/tp/pull/157)


* Update student-related commands and parsers. [#56](https://github.com/AY2021S1-CS2103T-T10-4/tp/pull/56)


* Added a `reset` command that allow users to clear all data in Tutor's Pet. [#106](https://github.com/AY2021S1-CS2103T-T10-4/tp/pull/106)

On a side note, might want to consider standardising everything in this section


1. If `Lesson` does not exists in `targetModuleClass` and the timing does not overlap with any existing `Lesson`s, a new


   `ModuleClass` with `Lesson` will be created. Otherwise, a `CommandException` will be thrown.

Should we stick to '''>br>''' instead of ''''''? Since the existing manual tests are using '''>br>'''

Checked the ug on your branch. The steps counter will reset to 1 if there isn't an additional space at image of line 324/325.


   ![Reset before](images/ugimages/ResetBefore.png)

Resolved by removing MODULE_CODE

Resolved by removing [] for all fields within add apart from [tag/TAG]

Resolved by updating line 58 to


e.g. `[tag/TAG]…` can be used as ` ` (i.e. 0 times), `tag/student`, `tag/TA` etc.

Resolved by adding in commit suggestion


**List Students in Class** | `list-students /by n/CLASS_NAME`<br> e.g., `list-students /by n/CS2103T Tutorial T10`

Resolved by changing clear class to "clear-class"

Resolved by changing list students to "list-students", and title to "Listing all students within a class"

Resolved by retaining {:toc}

Resolved by removing redundant add

Resolved by moving ellipsis outside of square brackets

Resolved by removing address field and updating tag prefix from /t to /tag

Ok i won't be touching it in that case

Added the tags, used tag/average and tag/TA candidate to keep formatting consistent

I think it'd be better if the summary comes before the detailed explanation. As a user i wouldn't want to scroll downwards if i just want to reference the commands. What do the rest think?

I thought of that, but the issue is that the formatting will not be standardized across the table and commands. I feel that perhaps its better to caps everything so that we standardize our documentation

Issue is that the formatting will not be standardized across the table and commands. I feel that perhaps its better if we follow the actions used in the command summary?

Changed Command summary to Command list

Resolved by rewording expression to show that Tutor's Pet can return more than one user found

Will keep clear instead of changing to delete

Ok lets keep the previous

Will be keeping line 155 instead

To change to '''requireAllNonNull(uuid, name, phone, email, tags);'''

Good catch, thxs, no point editing UUID so no point adding UUID into EditStudentDescriptor.

Resolved by removing setUuid() and getUuid()

Resolved by changing line 93 to '''UUID updatedUuid = studentToEdit.getUuid();'''

To add a DEFAULT_UUID in StudentBuilder.java and convert it to a UUID for usage instead of generating a random UUID for testing

Resolved by removing UUID field

Resolved by specifically adding Uuids into TypicalStudents

RIP, forgot to remove sneaky boi

Added the following :

JsonAdaptedStudent.java


        if (uuid == null) {

            throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid"));

        }

JsonAdaptedStudentTest.java


    @Test

    public void toModelType_invalidUuid_throwsIllegalValueException() {

        JsonAdaptedStudent student =

                new JsonAdaptedStudent(null, VALID_NAME, VALID_PHONE, VALID_EMAIL, VALID_TAGS);

        String expectedMessage = String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid");

        assertThrows(IllegalValueException.class, expectedMessage, student::toModelType);

    }

Since UUID is a built-in java class, instead of doing something like throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, Name.class.getSimpleName())); , i opted for throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid"));

Possible, but the json "studentIds" in the json file will be changed to "studentUuids". Which one do you guys prefer?

I initially added a class entry, but then eventually removed them as I wanted to isolate the test cases better (Since this json file is more to test for invalidstudent rather than invalidclass.) Any thoughts?

Currently since we are using UUID.randomUUID(), the edge case that could potentially happen is a null UUID rather than that of a UUID that is not specified properly, unless the user decides to edit the uuid in the json file to a smaller uuid string. Hence i decided to only test for toModelType_nullStudentIds_throwsIllegalValueException()

Any thoughts on this?

Was thinking that a guard clause would be sufficient (Since its likely the case that a uuid is either well defined (by using Java's UUID.randomUUID(), or null))

Any thoughts on whether a try catch is needed here? Will include one if needed

Thats a good idea. I'll pull information from ALICE directly and remove the TODO comment

Resolved by keeping status quo for invalidClassTutorsPet.json (ie no changes)

Resolved by adopting suggested change

Resolved by pulling information from ALICE directly and removing TODO comment

Resolved by refactoring all occurrences of studentIds to studentUuids, including the studentIds field in model ModuleClass.java

Resolved by abstracting code inside toModelType() into two smaller methods.

Resolved by adding try catch block

Resolved by introducing checks for invalid UUIDs

Yes, it applies across all UUIDs so long they are not invalid

An example of an invalid UUID is "fffa3023-7d89-426b-ba01-" // No uuid values after dash

In contrast, a valid uuid is "fffa3023-7d89-426b-ba01-d45eaa" // Missing values after d45eaa are padded with zeros

Resolved by using existing information from ObservableList>Students> in tutorsPet

Will change it to '''One or more of the given indexes are invalid.'''

Could be a typo on the user's part. Would recommend keeping the '''Use case resumes at step 1.'''

Added '''moduleClassIndex''' parameter into '''getAddLessonCommand'''

Abstracted to '''ModuleClassUtil'''

Added guard clause to check if attendance exist in the first place, and added negative test case to check for error message throwing for this scenario

Changed to following AddAttendanceCommand format and throw MESSAGE_CONSTRAINT instead

Added assertion for both '''DeleteAttendanceCommand''' and '''AddAttendanceCommand'''

Inserted assertion

Simplified for both '''AddAttendanceCommand''' and '''DeleteAttendanceCommand'''

Created ModuleClassModificationUtil and LessonModificationUtil classes to address this

Lets do it in a separate PR.

createModifiedModuleClassWithModifiedLesson is used in AttendanceCommands. It is specifically used as a bridge to modify a targeted module class after CRUD has been done on attendance and stored inside a lesson. createModifiedModuleClassWithEditedLesson specifically performs CRUD on the lesson itself

We can use manualReplaceLessonToModuleClass from ModuleClassUtil for now since there are no test cases for those methods which you've mentioned yet

I'd like to check with you guys on how we should go about handling this block.

Problem : removeAttendance(...) throws CommandException when it is unable to find an attendance to delete. This works for individual attendances, but if we doing a cascading delete (ie removing all occurrences of the student), then we would want to return the attendanceRecord even if no student can be deleted.

Solution 1 (Currently implemented) : Do a try and catch to overwrite the CommandException

Solution 2 : Remove the removeAttendance(...) abstraction and use the underlying code in removeAttendance(...) in this method. But this will violate SRP.

Solution 3 : Propagate the CommandException upwards to LessonUtil and ModuleClassUtil and eventually UniqueModuleClassList. But downside is that you eventually have to handle it with try catch.

To go with solution 1

Completed

This seems to be missing the saving of UUIDs to local storage, is that planned for a separate PR?

To implement saving of UUIDs to local storage

Mostly looks good to me, just need some minor changes.

Could you also add a test case to ensure that EditStudentDescriptor does not change the UUID of a student?

I think this part of EditStudentDescripterTest.java factors in that UUID isn't changed? Otherwise it will return false if the UUID changes


public class EditStudentDescriptorTest {



    @Test

    public void equals() {

        // same values -&gt; returns true

        EditStudentDescriptor descriptorWithSameValues = new EditStudentCommand.EditStudentDescriptor(DESC_AMY);

        assertTrue(DESC_AMY.equals(descriptorWithSameValues))

Not sure if we need to get approval before we merge this in since we are trying to use a new module?

Module has been removed (Last checked 26/09/2020)

Looks great! But like what Dexter said, I am not sure whether we need to get permission first.

Module has been removed

@ypinhsuan can yours work? my one works fine

Decided not to implement UUID equality check as it may risk introducing a lot of bugs into the code

Not required.

Use \ , update test cases to use PREFIX variables instead of hardcoding commands (e.g "\c")

Number of occurrence is 10. There is no week 11

TODO : Change number of occurrence to number of weeks

AB3 makes phone number compulsory but not everyone has a phone number. Telegram to be kept compulsory. Won't fix

Filtering of the list provides a visual cue to the user that the student has been linked to the class. Clearly stated in the UG that the list will be filtered. Not a bug. Won't fix.

Step 1 - To remove name field from isSameStudent(...) comparator

This is the correct behaviour because the repo url should end with .git.

@TCQian

I think this will cause an error as well : http://github.com/d/a/b.git

Issue here isn't whether it ends with .git or not. Issue here is that tokeniser backslash will collide with url backslash. One workaround is to convert all of your command backslashes to frontslashes so that your addressbook can handle URLs without throwing errors.

It will be a bug of the highest severity if the tester catches it during the actual PE so you might want to look into it instead of closing the issue

Got it, thanks! Misinterpretation on my part, my apologies. Should be fine in that case 👍🏻

Is it better to change this sentence to this?

"This project is based on the AddressBook-Level3 project created by the SE-EDU initiative."

As I feel like this flows better for me.

Should this be linked to our repo's actions instead of the se-edu's one?

no i mean the link not the badges. Now you are linking it to se-edu/addressbook-level3

https://github.com/AY2021S1-CS2103-T14-3/tp/actions

this

I think this line can put?

I'm a bit not sure about this. Is it we can edit the travel plan at top directory also?

dk hahaha

@jiaweiteo @jeannetoh99 @timjkong

According to @jiaweiteo , only the name should be considered as identity fields, while passport and phone should be data fields

i think its better to put getTPOList()

same for all the other TPO

Is it better to have ScrollPane here? As we might have lots of TravelPlan and the Pane cant show everything

Same as above. Maybe we put ScrollPane here

JavaDoc errors

We just need one method from Directory only? What about AccommodationList all that?

Is there a better way of doing this? Like not typecasting but instead use the polymorphism.

Why did you use assert here btw? Cos I think assert won't be run if we didnt specify it and the user probably wont run our program with assertion on. Maybe check it using if block and throw an exception? Same for all the methods below

JavaDoc error

same for line 57

JavaDoc error

thats why before i put 2 boolean method to check is which one

nah typecasting is not considered polymorphism. We have to do directory.the method straight away i think. But it might be not worth the time to think about that. So maybe can leave it like this first ba

oh okok then Logic is the one that have to make sure the directory is the correct instance?

Why this one change back to TravelPlan? It's not used in other place meh? like Activity all that

Oh I see what you did there. Works but I feel like it is not following some OOP shit or smth. But I think we come back to this later ba.

I think the cost is just numbers? iirc

Do you think we want to make the arrangements of all these fields consistent throughout our whole repo. Cos I feel its a little bit messy right now, everybody's arrangement is different.

@jiaweiteo @jeannetoh99 @underthehai @timjkong

Same as above

Is it travel plan list?

I think it is suppose to be start date and end date?

We use -1 to indicate no changes, but here we throw an exception? Would it have any problem?

There is an extra whitespace in front of Activities?

Here also. Or is it deleted whitespace haha i not sure

Why the whitespace!!!

The Ui didn't show the index actually, do you think we wanna show it? Then, need add into Ui part

But why previous one no problem one ah? hmmm

JavaDoc issue: "address book"

I think this can rename to SHOW_ALL? I remember I changed it to SHOW_ALL don't know when get changed back haha

NameCard should be under TravelPlannerPanel

These 3 should be TravelPlanObjectListPanel

There is a space in front of -tra... ? Cos I tot just "-travelplan 2"

No, its not. You go check the implementations in Ui component

oo okok cos i think i didnt put space in front of mine

Actually, I might try to change it so that there isn't so much magic number here and there, using the ArgumentTokenizer, cos you guys didn't utilise it i think?

Hmmm is this image name correct?

This fonts can add in CSS? But its fine, just asking

Do we allow them to type this command when in wishlist? Or do we output error message?

I think you miss out the (L) / (G)?

What does this line suppose to do?

Why do you need logic here tho? Doesn't seem to be used anywhere in the changes in this class?

Now no need do typecasting already. You can add this getTotalCost() method into Directory class.

But still need to check isTravelPlan() to setText lah

Is calling the update() here suitable?

I think the travelPlanPanel.update() can be called here instead? So, no need to pass into TravelPlanObjectListPanel

I think this method is not needed? Cos in Storage i also need this so i called getName().name

Same for this. I just call getImportance().value

or do you think we should do this instead?

magic number here

Or nvm i can change it when i do defensive for sort command. or you want to help me change also can hehe

I think the error message still need to be refined abit.

OK i think that is considered my part haha

Is this used anywhere? Same for all the other tpo ones.

Should the cost and date be lowercase? maybe others will misinterpret it as uppercase and type that instead

Why do you need to sort both actually? I think sorting the internal one is sufficient. the unmodifiable observable one will update itself i think? i not sure

I think the internal list should not be accessed. So, ermm i think add a sort method in AccommodationList maybe? or both AccommodationList and UniqueAccommodationList

Same as above.

Same no need typecast alr

So this should not be able to access

This one i not sure tho. I'm thinking to sync everything to use AccommodationList XXXList instead of UniqueXXXList

oh... hmmm

Can you make the wish list "wishlist" instead? I think we use wishlist.

CopyCommand perhaps?

Do you think its better to use guard clause here instead of if else statement?

Same as above

I think its better to name it as ....START_AND_END_DATE?

Perhaps you can use the MESSAGE_INVALID_START_AND_END_DATE here?

copy and move command

"UserGuide"

"A pop-up window will provide the link to access Wanderlust UserGuide for help"

Why is there a huge whitespace here tho?

This doesn't include mobile isn't it?

Does this work? I think it cannot be null tho. "new TravelPlanner()" should work

I think the date can be abstracted out, just pass the TravelPlan to isValidActivityDate() then in Model, you get the start and end date there.

Same as above.

Can this be put in isValidStartAndEndDate()? So, everything is checked in one method?

Same as above. Or is it becos of the error message?

I think the JavaDoc for this can put like, see isValidActivityDate() something like that? I not sure tho.

Think this will be considered as duplicate?

I think it's bad "SLAP" here. Perhaps can just do startDate.isBefore(WanderlustDate)

Same for all date checking logic in this class

All these getValue() haha, kind of wanna abstract all of them out XD, but see you want or not. I think its ok? Like add a method in WanderlustDate compareTo() so can just call startDate.compareTo() instead of this, need getValue() everytime.

I'm just concern about if this will be considered duplicates code. I think it's OK ba.

The passport and mobile field needs to be changed, to reflect the new Regex.

Passport: [STFG] + 7 numbers + [A-Z]

Mobile: [89] + 7 numbers

Is it within travel plan instead?

Mobile and Passport parameters need update

Actually now it's case-sensitive XD

Same as above.

The dates need to change according to Jia Wei's new implementations.

Same as above.

Passport number need to change to [STFG] + 7 numbers + [A-Z]

Date issue

Nice! Maybe can notify others about this changes also?

@timjkong @underthehai

This one I made quite some changes. So when you resolving conflict can just use mine.

Same for this part.

I renamed this method, so update when pulled from upstream.

Nice way to work around the magic numbers! @timjkong @underthehai

Maybe consider using a stub?

I wonder why you didn't use the method in CommandTestUtil (assertCommandSuccess(), etc.)?

Or is it suppose to use original model?

This method name I changed to assertEditParseSuccess(), wait I merge then you update

Need, but i thought haishan is also doing this so I left out the edit and show features for her, or I should just do them?

Hmmm I don't know.

@jeannetoh99 @underthehai @timjkong

Maybe can add the person to be deleted is not found?

You mean the person is not found in the travel plan or you mean the person is missing in the input command?

I will add the case for target not found, but the error message one cause I wanted to make them generic so don't need to be too specific. The implementer of that feature can do whatever they want to the error message. What do you think?

@underthehai

I updated it. But I don't know if it works, can help me check?

oh cos this method is I cincai add one last time. No JavaDoc all that, need to redo

Actually I changed all to without all the Wanderlust in the front. Tsk didn't read my telegram message. YOU SHOULD CHANGED!!! NOT ME!!! HAHAHAHA

They are included in the etc XD or else too long lah, or you think I should change the commandbox all that to travelplan thing?

I make it so its like

"sort -activity " will show the error message specific to activity

"sort -accommodation" will show error message specific to accommodation etc.

do you think its ok?

huh? It's not [STFG] ?

My CI will pass after merging @jeannetoh99 TravelPlan class

Don't merge first after commiting changes.

I need to think about all the ReadOnlyXXX classes, if they are needed

I think I'm done for now? Hopes everything works.

And do you think we need to make sure that the travel plan inside travelPlanner needs to be updated too?

I closed ah, I have added them in my side

I think the commit is messed up, cos I branch this from the branch where I updated the Design section. So, this PR includes both changes. RIP

Perhaps it would be good if we insert our website here.

Perhaps we could keep keep this so we can change it individually

Perhaps we could keep keep this so we can change it in future

Perhaps we should keep the product name consistent, to Insurance4Insurance, I4I

Perhaps we can add a "Coming soon." here

Perhaps this could be "Adds a client to I4I."

Perhaps this could be Format: add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [o/NOTE] [t/TAG]…

Perhaps this could be

Examples:

add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01
add n/Betsy Crowe t/friend e/betsycrowe@example.com a/Newgate Prison p/1234567 t/criminal o/This client is new.

Perhaps this could be Lists the entire list of clients in I4I.

For now, for v1.2, I think we would try to minimise the amount of fields to delete, so we would add in NOTE and keep the rest. However, this may change in v1.3/1.4, so we can update the UG then.

We can add back the "Tip" for tag if you are okay with the above change.

Perhaps we can format INDEX to INDEX.

Perhaps we can edit to Example: list followed by delete 2 deletes the 2nd person in I4I.

Perhaps we can add a Coming soon here

If you are okay with above edits to add, perhaps we can change to this:

Add | add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [o/NOTE] [t/TAG]… >br> e.g., add n/Betsy Crowe e/betsycrowe@example.com a/Newgate Prison p/1234567 o/This client is new. t/friend t/criminal

Perhaps we can add in help as well, since we are implementing in v1.2

Help | help

Perhaps we can add this back, since we are implementing help in v1.2

But we would need to update the image to https://ay2021s1-cs2103-t16-2.github.io/tp/UserGuide.html

Perhaps we should change this to

Wraps all data at the client-list level

Would it be better if we have multiple tags and 1 note? i.e. the ... comes after tag instead

Perhaps this can be updatedNote?

Perhaps the message could be "Notes can take any values, and it should not be blank"

Perhaps this can be package seedu.address.model.person;

Perhaps seedu.address.model.note.Note can be simplified to Note

Perhaps we can return noteName

Perhaps this could be " "?

Perhaps we don't need to add an invalid tag here

Perhaps we could add back the space here String ...

Perhaps we should add back the space here?

Perhaps this should be 8 spaces relative to line 22? But not sure why the original AB3 passed checkstyle

Similar concept for the rest of the lines in this file

Alright got it

Perhaps we should remove the extra tab here

Perhaps we should change to

"Priority values should only take L, M, H, U, l, m, h, u, low, medium, high, or undefined;

Perhaps we dont need to check null here

Perhaps we dont need to use equalsNullable here

Perhaps we should require non null for priority

Perhaps we should throw error if priority is null

Perhaps we dont need to check for null

Perhaps we should add back the space here

The ^$ might not be necessary, but I might be wrong

"[ulmhULMH]|undefined|high|medium|low" might work

Perhaps we should add an assertion here

Perhaps we should add in javadoc? Same for the rest of this class.

Perhaps this should be in policy.exceptions?

Should this be only takes into account of name?

Perhaps we should rename this file/class to JsonSerializablePolicyList?

Should this be I4I instead of AB3?

What does the ? represent?

Perhaps we can update the command summary table?

Oh I mean to update the add command with [l/PRIORITY]

Perhaps this can be "You can add a new policy by using the addp command.";

Can we add a new line here?

It might be better for us to use HashMap instead of Hashtable as we do not need synchronisation

https://stackoverflow.com/questions/40471/what-are-the-differences-between-a-hashmap-and-a-hashtable-in-java

If this were to change to hashmap, we can update the javadocs (and other corresponding javadocs). Perhaps we can refer to it as the "Policy List" instead of hashtable/hashmap.

Perhaps we can have return policies.containsKey(toCheck.getPolicyName().value);

Perhaps the method name could be getSamplePolicies()

Perhaps the assertion can print "Policy should not be null"

Perhaps we should check policy.getPolicyName() != null and policy.getPolicyDescription() != null as well

and print "Policy name should not be null" and "Policy description should not be null"

Perhaps we should test for adding policy as well

Perhaps we should test for different policyList -> returns false

Perhaps we should have invalidPolicy test, with both invalid name and description

Perhaps we should have Policy here, as we are testing one field at a time. Same for rest of optional fields missing

Perhaps we should test for missing Policy name prefix

Perhaps we should have policy here

Perhaps we should test for multiple policy names - last policy name accepted

Perhaps we should have policy here, same for rest of multiple fields

Perhaps we can refer to add command parser for some tests

invalid value: failure
all fields present success => multiple policy names / policy description - last policy name / policy description accepted

Perhaps the method name should have throwsCommandException behind

Perhaps we should have .equals() test

Perhaps we should use HashMap here, as previously commented in PolicyList.java

Perhaps we should have standardised names for the tests. Same for the rest of the tests in this file

Perhaps we should test for

getPolicy(): E.g. null input, null output (key not present), key present
equals()

Perhaps we should have a positive test

Perhaps we should test for null and Duplicate

Perhaps we should test for null

Perhaps we should requireNonNull

Same for the other contains()

Is createNewPolicyList() being used? If it is, we can add it into the PolicyListTest.java

Perhaps we should use Policy to format the name, instead of Policy

Same for other objects, classes, variables in this DG e.g. Person, PolicyName

Implementing*

If we want to use String as an object, I think it would be good to format it as String

Otherwise we can leave it as string (lower case 's')

Perhaps we can say ...checking for validity of each of the individual object's input

Remember to put the multiplicity in the class diagram (0..1), otherwise it might be safer to remove the reference

AddPolicyCommandParser

Maybe we can add a cross under the AddPolicyCommand

Maybe we can add a note to say that:

>div markdown="span" class="alert alert-info">ℹ️ Note: The lifeline for XXXCommandParser and XXXCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

>/div>

I think the AddPolicyCommandParser is the one that is creating the Policy (object p) first, then AddPolicyCommand is created with the object p as its parameter. Both are created in the parser

Perhaps we can update the return 'a' to 'p'

I'm not too sure if checking hasPolicy is low level wrt this diagram, but if you decide to keep it, then I think we can remove the return false

Maybe you can remove the CommandResult if you think it clutters the diagram

I think we can either say ClearPolicyCommand or 'the command used to clear the policy list'

Hmm is should be similar in terms of parsing and Command creation, but is it similar in the Model part?

I'm not sure about the efficiency and speed, but if you checked it then it's okay

Hmm do we have this?

Perhaps we can say User clears the list of existing policies. Or we can add what is the policy list in the glossary too

Perhaps we can say User chooses to clear the policy list

Remember to add in clear policies in the user stories as well

Remember to add in the test cases as well (maybe in a separate PR)

In testing.md, perhaps we can update the package names e.g. seedu.address.commons.StringUtilTest

Perhaps we can say ...clear the entire...

Perhaps we can say "does not" instead of forgets

Perhaps we can say System adds a new client instead of "saves"

I'm also not sure if this is a valid/relevant 1d1 as in the positive use case MSS, we do not mention the System adding/saving clients. I think we can either

Include add/save client in the use case MSS (but that means changing other use cases as well)
Adjust 1d1 so it sounds consistent as the others
Not have this extension as resolving might be hard and it's on a different level than the use case

Ps then we should say "clear the active client list and archived client list."

Maybe you would want to add in this from AB3

The UI component,

Executes user commands using the Logic component.
Listens for changes to Model data so that the UI can be updated with the modified data.

Perhaps this should be a dependency (dashed line) instead of association

If I didn't understand your question wrongly, the withoutNote() is meant to add in a null for BENSON, who originally has a note

Hmm I don't think so, as long as we are consistent with the hashing

And I made isArchive come before priority in the constructor (by accident)

The predicate is meant for filtering the field in the Person, just like how we placed the Predicate for filtering Name in the same folder

It's a really minor thing, on line 6 it {@link Command} in the Javadoc, so if we dont import it, it wont display properly

I followed the PE instructions for this one; they specifically told us not to double click

Same for here, I followed the PE instructions

Done, can check now

Reopening this issue as PR was accidentally merged

Note that this PR was merged by accident, reopening issue and creating another (similar) PR

Resolves #6

Ensure that source should be >= 50 characters.

Update URL and image in UG

address
email
phone

Duplicate issue

Closed as all issues in epic are closed

Not a bug

Duplicate as #176

Duplicate with #154, #155, #156

Duplicate with #178

Duplicate with #161

In the example in https://ay2021s1-cs2103-t16-2.github.io/tp/UserGuide.html#unarchiving-an-active-client--unarchive, we did mention this already

Closing since

We allow the users (insurance agents) to also keep track of potential clients, so they may not have existing policies yet

Duplicate as #174

Not a serious feature flaw, but good to have

Our restriction is very simple; just have not more than 50 characters. We wanted to have the flexibility of a user adding something like friend of friend of teacher, or met in 123 bar, so we lifted restrictions on space/number/special characters as well. They may not "make sense" sometimes like the example given, but we leave that decision to the user.

Agree that this might be confusing, but we defined what makes a client "unique".

2 clients are unique if they have

different names
same name, different phone
same name, different address

As for policies, priorities, client sources, these may be the same across different clients, so we did not use them as uniqueness identifiers.

The archive is meant as a way to store clients which may not be currently relevant to the insurance agent. For example, clients which are no longer managed by the agent. The agent may decide not to delete the client straight away, in case they happen to start interacting again, so they can store them in the archive.

The archive has a separate view from the active list, so that the agent would not be distracted by archived clients. The agent has the option to switch to view the archive if needed. The default view upon starting up the app is the active list.

The agent can unarchive an archived client, for which case the client would become active.

From a user's point of view, this would be good for tracking the order in which the clients were added to the client list. Whenever we archive and unarchive back the same client, his relative position remains the same.

I like your specifying: STUDENT_INDEX and CLASS_INDEX

Perhaps it is clearer to define 'index' as follows?


*`STUDENT_INDEX` refers to the index number shown in the displayed student list.

*`CLASS_INDEX` refers to the index number shown in the displayed class list.

Minor grammar issue, should it be is and not are?


* 5a. At least one of the given indexes is invalid.

Same as issue above.


* 5a. At least one of the given indexes is invalid.

Should we include test cases for UUID? Such as public void toModelType_nullUuid_throwsIllegalValueException().

Apologies, mistake on my part for not typing correctly. Should be


    public void toModelType_nullUuid_throwsIllegalValueException() {

Otherwise, looks good to merge.

Should the tense follow the DeleteStudentCommand class instead?


    public static final String MESSAGE_DELETE_MODULE_CLASS_SUCCESS = "Deleted Class: %1$s";

Nice abstraction.

Should the filtered list be specified?


     * Updates {@code model}'s {@code filteredStudents} list to show only the student at the given {@code targetIndex} in the

Same as above.


     * Updates {@code model}'s {@code filteredModuleClasses} list to show only the ModuleClass at the given {@code targetIndex} in the

Same as above.


     * Updates {@code model}'s {@code filteredModuleClasses} list to show no module classes.

Perhaps naming studentIds as studentUuids would make the code clearer?

Should there be at least one class entry here? We can follow invalidClassTutorsPet.json, which has a valid student entry.

Should you insert a INVALID_STUDENT_IDS list (and test case) also? Perhaps you can use a string that has less than 4 hyphens

Nice handling of null UUIDs. However, would it be better if a try-catch block is used on UUID.fromString(uuid) instead? Then, any kinds of wrong UUIDs can be handled.

I think you missed out on this:


    public static final String MESSAGE_DUPLICATE_MODULE_CLASS = "Class list contains duplicate class(es).";

I think you missed out on the TODO comment. Perhaps instead of importing these STUDENT_UUID_X in test cases, we can call ALICE.getUuid() from TypicalStudent class instead.

Should this for loop be placed in another method for proper SRP? The for loop above that iterates through jsonAdaptedStudent can be similarly placed in another method. Then, this toModelType() method will call these two for loop methods.

To add on, according to Java's UUID API, UUID.fromString() throws IllegalArgumentException. Perhaps you can use this alongside with your null guard clause.

I notice this try-catch block appearing in other parts of the PR. I think the proper way would be to write our own interface for UUID. But, for now, I think it is not needed.

Should you indent this line?


<fx:root minHeight="600" minWidth="740" onCloseRequest="#handleExit" title="Tutor's Pet" type="javafx.stage.Stage"

         xmlns="http://javafx.com/javafx/11.0.1" xmlns:fx="http://javafx.com/fxml/1">

I noticed that these 3 lines of code are repeated in above test cases. Perhaps can consider abstracting these out into a private method?

Should this be:


        ModuleClass specifiedClass = showStudentsInModuleClassAtIndex(expectedModel, INDEX_FIRST_ITEM);

Should this be in the same 'format' as above?


        assertCommandSuccess(new ClearModuleClassCommand(),

                model, ClearModuleClassCommand.MESSAGE_SUCCESS, expectedModel);

Would it be better to test against the moduleClasses directly? Since we are adding (and removing) them along with their studentUuids.


        assertFalse(modelManager.hasModuleClass(CS2103T_TUTORIAL));

        assertFalse(modelManager.hasModuleClass(CS2100_LAB));

Similar to above.


        assertFalse(tutorsPet.hasModuleClass(CS2103T_TUTORIAL));

        assertFalse(tutorsPet.hasModuleClass(CS2100_LAB));

Perhaps you can convert the for loop in ViewHistoryCommand into a method residing in StringUtil class.

This is to avoid the explicit construction of expectedMessage. For completeness, the new StringUtil method also needs to be unit tested.

Should you move the 1 and 50 to static constants?

Perhaps naming the variables as they are is good enough?


    public static final String VALID_TIME_1400 = "14:00";

    public static final String VALID_TIME_1600 = "16:00";

    public static final Day VALID_DAY_WED = Day.WEDNESDAY;

    public static final int VALID_NUMBER_OF_OCCURRENCES = 7;

    public static final String VALID_VENUE = "COM1-B111";

Should you also test the edge cases of 0, 50, and 51?

Perhaps you can consider renaming WED_2_TO_4 to LESSON_WED_2_TO_4, so as to avoid confusing this constant as a time object.

Just noticed, not sure if 'integer' is considered a technical term.

Nice check.

I don't really quite get the purpose of the cache.

Understood the cache. Logger lgtm.

I think should be Class'.


    public static final String MISSING_FIELD_MESSAGE_FORMAT = "Class' %s field is missing!";

    public static final String MESSAGE_INVALID_STUDENTS_IN_LESSON = "Invalid student(s) found in lesson(s).";

    public static final String INVALID_FIELD_MESSAGE_FORMAT = "Class' %s field is invalid!";


            if (!studentUuids.contains(studentUuid)) {

                throw new IllegalValueException(MESSAGE_INVALID_STUDENTS_IN_LESSON);

Just throwing out this alternative: perhaps placing the Week object here would be better instead of in the JsonAdaptedAttendanceRecord class. So instead of having a List>JsonAdaptedAttendanceRecordList> attribute, there can be a Map>Week, JsonAdaptedAttendanceRecord>. Jackson supports Json serialisation of Maps: https://www.baeldung.com/jackson-map.

Purpose is for symmetry between the Model classes. And I think it may help in reducing lines of code and tests.

I think this current implementation is also suitable for purposes of this project.


  "_comment" : "StudentAttendance contains an invalid student attendance score",


  "_comment" : "StudentAttendance contains duplicate student UUID",


  "_comment" : "Records contains a null student UUID",


  "_comment" : "Records contains a null entry",


  "_comment" : "Record list contains duplicate AttendaceRecord",


  "_comment" : "null recordList",


  "_comment" : "recordList is empty",

Would this be better?


            + "lesson on a specified week.\n"

            + "Note: All indexes and numbers must be positive integers.\n"

            + "Parameters: "

            + PREFIX_CLASS_INDEX + "CLASS_INDEX "

            + PREFIX_LESSON_INDEX + "LESSON_INDEX "

            + PREFIX_STUDENT_INDEX + "STUDENT_INDEX "

            + PREFIX_WEEK + "WEEK_NUMBER";

Should this be moduleClassIndex?

Perhaps you can consider writing a test case for finding attendance in a filtered list?

Should you insert an assertion for lessonToEditIndex?


        assert targetModuleClass != null;

        assert lessonToEditIndex != null;

        assert lessonToUpdate != null;

Perhaps an assertion can be included here to check that the size of updatedAttendanceRecord has decreased by 1.

I think this can be simplified to


        Lesson modifiedLesson = new LessonBuilder(lesson)

                .withAttendanceRecordList(new AttendanceRecordList(updatedAttendanceRecords)).build();

I am wondering if these lines, along with the private methods declared below, can be abstracted into a class that deals with the manipulation of the Lesson and Attendance related classes. These lines of code are repeated in other commands and in test cases as well.

Should this be a requireAllNonNull check, since it is a public method now?


        requireAllNonNull(targetLesson, targetStudent, targetWeek, attendanceToAdd);

Same as above. I notice that this occurs in the other refactored classes as well.

Should you shorten the name of this method as well as the other refactored methods? Perhaps use addAttendanceToLesson?

Should the methods from LessonModificationUtil and ModuleClassModificationUtil be used here instead? Perhaps we can do it after unit tests for these 2 classes are completed.


     * @see tutorspet.model.Model#getTutorsPet()


 * Represents a storage for {@link tutorspet.model.UserPrefs}.


     * Saves the given {@link tutorspet.model.ReadOnlyUserPrefs} to the storage.


         * @see tutorspet.logic.Logic#execute(String)


     * @see tutorspet.logic.Logic#execute(String)

I think it would be great to include a javadoc comment here to summarize the purpose of this class.

Same as the above comment on javadocs.

Should you put these 2 variables as static constants or under a @BeforeEach method? They are used commonly in the test cases.

Same static constant abstraction comment as above.

Should you abstract these 2 lines out into a private method? These 2 lines are repeated in the add and edit methods.

For statements such as these, would it be better to put the String.format method on the next line?


        assertParseFailure(parser, " "

                + PREFIX_LESSON_INDEX + "1" + " "

                + PREFIX_STUDENT_INDEX + "1" + " "

                + PREFIX_WEEK + "1", 

                String.format(MESSAGE_INVALID_COMMAND_FORMAT, MESSAGE_USAGE));

Same as above.

Similar to the above comment, would it be better to format the statement as follows?


    private static final String INPUT_PREAMBLE = " "

            + PREFIX_CLASS_INDEX + VALID_MODULE_CLASS_INDEX_ONE.getOneBased() + " "

            + PREFIX_LESSON_INDEX + VALID_LESSON_INDEX_TWO.getOneBased();

Nice catch!

I think it will be good to add a unit test that tests this method directly.

Should this be h3 size instead?


### Display Statistics Feature

I think this should be labelled 1 throughout?


1. `Logic` uses the `TutorsPetParser` class to parse the user command.

1. A new instance of a `StatisticsCommand` object would be created by the `StatisticsCommandParser` and returns to

 `TutorsPetParser`.

1. `TutorsPetParser` encapsulates the `StatisticsCommand` object as a `Command` object which is executed by

 the `LogicManager`.

1. The command execution calls static methods from the `ModuleClassUtil` and `LessonUtil` classes.

1. The result of the command execution is encapsulated as a `CommandResult` object which is passed back to the `Ui`.


* **Alternative 2 (current choice):** Extract the methods out to another class


    * Pros: Does not violate the law of demeter. Increases cohesion and thus increases maintainability.


The Undo/Redo mechanism is designed around maintaining a history of `TutorsPet` states, and restoring a particular state when the user triggers an undo or redo command.

Perhaps consider reordering these statements or shifting the TutorsPetState diagram lower? So as to establish a clearer link to the diagram.

Should 'Alternative' be renamed as 'Choices'?


  * Pros: Will use less memory (e.g. for `delete`, just save the student being deleted).

Would it be better to shift this diagram to around line 278? The explanation is rather dense there.

Sure!

Should this method return a double instead to avoid rounding off errors?


            totalParticipationScore += getParticipationScoreFromLesson(lesson, targetStudent);

Same consideration as above, to change the return type to a double.

Would it be better to indicate 'weeks'? So index 4 will be name of the lesson and index 5 will be the string of weeks not attended.


            + "%4$s, Weeks: %5$s";

Would it be better to return List>Integer> or int[] here, where each element of the list/array is the week number the student is absent? This will reduce the responsibility of this method and make testing easier. The method to convert this list to a string can be shifted to StatisticsCommand and be made private.

Same consideration as above to change the return type to a List or Array.

Can!

Should you move this into a private method in this class?

I think you missed out on the casting. Might have to tweak some of the test cases also.


        return (double) totalScore / numOfWeeksParticipated;


For example:


This glossary provides definitions for special terms used in this guide.

Would it be clearer write like this?


  * `Lesson(s) not attended` displays all lessons not attended by the student. This means that future lessons 

     are also displayed.


  * Pros:

    * Does not violate the law of demeter. Increases cohesion and thus increase maintainability and testability.

  * Cons:

    * Requires more wrapper methods to carry information.

    * More effort to implement.


  * Pros:

    * Easy, straightforward to implement.

  * Cons:

    * Violates the law of demeter to a large extent.

Not sure if this class diagram is necessary, since the Implementation section has similar diagrams. Perhaps can just link to those?

I don't think there is a need to test this class. It is not necessary to enforce that the pre-defined colours map to a specific Hex Value.


the immutability of `Lesson`.


   1. Prerequisites: List all classes and students using the `list` command. Uses default tutor's pet data.


(Changed addressbook address entries to students, \t to \tag, Changed tag description, Removed AB3 address,

Should you put the null checks of the tags in the for loop instead?


* Added use cases `UC10` and `UC15`.

Will it be better to standardise to sentence case instead. If not, I think need to change all the subheaders to title case.


    * Store `Lesson` objects directly in `ModuleClass`.


**Command:** The text typed in by the user as an instruction for Tutor's Pet.


**Case-insensitive:** The treatment of uppercase and lowercase letters in the same way.


**Tag:** A word or phrase that labels a student.

Yup

@junlong4321 yup, that is right.

@dextertanyj agreed, will remove a student not in any classes.

Agreed. I was not so sure what exactly is to go into the Logic and Model components. That's why I switched to int.

Have included similar tests for JsonAdaptedModuleClassTest and JsonAdaptedStudentTest.

I think I will stick with the space, because it follows the comma then space convention.

For example: new A(a, b, c). So it feels more natural to have the space after colon.

Agreed. But I cannot do it for AddLessonCommand as there is no list to 'compare' to.

Changed to spaces before and after colons

I think I will leave it like that for now, because I want to show Attendance. Will clarify with Prof Damith or Clarence.

Screenshot just the dropdown menu of the theme button?

Yup, we should standardize comments. I think we can just follow the style you suggested. Everyone okay? @raymondge @itssodium @chiamyunqing

is it be better to use comment.trim().isEmpty() instead of comparing it to null?

i think you can use the TODO function so its easier to check what you have to do next time

eg.

//TODO: your todo item here

i'm not very sure, does the java doc require the parameter and the return value? eg.


/**

 * Returns true if a given string is a valid age.

 *

 * @param test....

 * @return boolean.....

**/

same for the java docs here!

okay can!

is it better if we do addpatient instead of addPatient? just asking out of curiousity, no need to change if you think its fine

i think this should be addPatient instead of add?

do you think we should add in details like the temp must be 1dp or that the age must be in the range from 0-120?

hmm, why do you need this variable? Essentially, the numofRoomsInString is equal to Integer.toString(numOfRooms). so maybe you can just use that instead of declaring another variable?

so for this, you can just use Integer.toString(numOfRooms)

maybe you want to change the name to SearchPatientDescriptor? can rightclick, refactor -> rename

not sure if this will fail the checkstyle because of multiple empty lines

i think you can change the Person's to Patient's

i think that this method might be a bit long, so maybe you want to extract out some lines of code into a new method? Its just a suggestion, it's fine without it also

I think the one that was removed is correct? Might need to check

is there a reason behind initializing the numerOfRooms to -1?

perhaps it might be good to catch the exception for negative integers inputted by the user?

Sorry, I don't really understand the need for a PriorityQueue in this class, can you explain the rationale for ti?

can i know whats the purpose of this constructor? because its empty but yet it takes in an integer parameter

i think i saw the method below this comment in the RoomBook class, so there might not be a need for this method here?

same as the previous comment, this method might be a duplicate?

since you are creating a new room every time the user adds a room, i think the previous data in the room might all be wiped?

this might be a duplicate method too?

it's only null for now right?

i think this might override the data of the previous rooms too?

i think you might want to change your naming for the priority queue and not use rooms? i got quite confused trying to read it

since you are only counting the number of occupied rooms directly, will there be a problem with this? eg.

i have 3 rooms

room 1
room 2
room 3

So lets say room 1 and room 3 are occupied. so numberOfRoomsOccupied = 2 correct? But next time if you load the RoomBook, it will give me room 1 and room 2 occupied since the numberOfRoomsOccupied is 2?

is the name of the file lol?

this indentation might be abit off?

let's work with the naming together for the test cases next time!

is there a purpose for this method?

i think you can delete this method if it is not in use

hmm, i dont really think there is a need to test if the priority queues are equal? or if you want to test, you can just do


int[] array1 = roombook1.toArray();

int[] array2 = roombook2.toArray();

Arrays.equal(array1, array2);

i think better naming of the paths would be good? it's a little bit hard to understand/remember what the constructor of RoomOccupancyStorage is supposed to take in

by accident? maybe a slip of the finger?

hmm, but i think you can just chain the methods together? like .getRoomBook().getRooms() etc

hmm, i thought that this field not supposed to be here anymore?

Hopefully we won't get merge conflict for this when we merge our UI hahaha

thanks for helping me to change what i have missed!

same here, thanks for catching this

should we make it such that there cannot be patient with the same name?

Is there a typo here? don't think we have UndoCommand and RedoCommand right? hahha

if this part is not needed, then will it be better to just delete it?

i think you can delete this line and subsequently, the convertPriorityQueue method

can delete the method below. i dont think it's in use anymore. i only created it to bypass the need for an observablelist

i'm not sure why it cannot be yyyyMd, is there a difference?

i think he used it because it allows easier tracking of the tasks due date using DateTime instead of a string

Very good use of ObservableList, this will help immensely in the integration into the UI!

i think this should be null dateTime instead of email?

i think this prefix is already used for periodOfStay in PatientCliSyntax.java, will it be affected?

thanks for cleaning up my unused method from before! 👍

i think its fine. It makes me wonder if I should convert my editroom prefixes to p/ instead of pn/ for patient name. hahahah

Yup, adhering to abstraction principle is good, however i feel it might not be worth it to extract only 2 lines of code into a new method. maybe what wl can do is to perhaps give a name to the variable to make it clearer.

eg. String[] stringNames = searchPatientDescriptor.getStringName().split("\\s+"));.

same here, abstraction principle is good, however, it might not be worth it to extract them out into a new method

yup! is there a reason why you are checking if the search result has only has one value? I'm referencing to the (patientNameList.size() == 1) cuz your getListOutput(list) method will just print out everything

hmm, just curious ah, why dont want just String stringName = argMultimap.getPreamble().trim().toLowerCase()? so eg. if you have searchpatient alex n/something, your stringName will be alex.

Also, what is the substring(2) for ah? i think for very long but i still cant figure it out

can consider Returns instead of Return? also, do we have to leave a line after line 70? i kind of remembered that it is in the coding convention but im not sure.

might be good to have a java docs header before this!

maybe you can use model.getUnmodifiableRoomList() here? model.getUnmodifidableRoomList() returns an ObservableList>Room> too. i discussed with yh last time about how the command class shouldnt be interacting directly with the room class but rather through the model class

i changed the checkIfRoomPresent() method to a static method because of the reason below. ideally, i feel that checkIfRoomPresent() should be in RoomList.java class. what do you think?

should there be an empty line before this line of code in the java docs?

should there be an empty line before this? also, there are some extra white spaces in line 23

same for the empty line before this

ah, i see i see, sorry!! hahaha

do you want to consider removing this comment? is it needed?

would be good to have a class header for java docs!

you can consider renaming your test method to toModelType_returnsOccupiedRoom_success() here.

same here for the naming

i think you can consider looking at the JsonAdaptedPersonTest class for an example of what to test!

hmm, why do you need this method? is it to get access to the ObservableList? If you are not planning to modify the elements in the ObservableList but planning to "look at" the elements in it, you can consider the asUnmodifiableObservableList() method in this class at line 84

do you want to consider moving these few lines of code into the map function from line 55? you can just write a one liner val = trimmedDueAt and i think it should do the trick?

can consider val = trimmedDueAt so that any whitespaces are removed

let us know if you need help with writing json test cases! Although Json is unfamiliar to me too, i'm sure we can work something out

consider adding a java docs header here

consider adding a java docs header here. Looks good to me for the testcases!

you might want to standardize the naming of methods, so maybe this method can be toModelType_sameModelType_success(). same for subsequent methods below toModelType_sameModelType_throwsException(), toModelType_sameModelType_failure()

remember to remove println statment here. you can consider adding a //TODO before using println statements, so you won't forget to remove them

can remove instead of commenting if this is not going to be used in the future

hmm for this right, why not just throw an exception in the method? why do you need to have a try-catch block to catch the exception and throw the same exception? eg. public void setTask(Task target, Task editedTask) throws TaskNotFoundException {

Edit: Nevermind, i understood, its because its a void method

would it be better to name the test parseCommand_editTask_failure() or parseCommand_editTask_throwExceptions() instead? Same for the tests at the bottom too!

actually, do you need to wrap this part in a else statement?

need fullstop here for java docs?

full stop here too?

i think you can unwrap from the else statement here too?

i think you should be asserting if the roomNumber is null? Because if the roomNumber is >0 then it should be the user fault and not the system fault no?

same here for what yq and i mentioned previously

thanks for indenting!

is this system println needed?

will it be possible to add in java docs for these methods?

i think there's already a method called setRoom()

maybe can check if taskList.isEmpty();

yup, i think it should be fine since you are doing unit testing to ensure that the function works

if this is not needed, it can be removed?

will this throw an Assertion exception if the roomlist does not contain the room or is there a check to ensure that the roomlist contains the room before calling this method?

is there a line separating the description and the @param in the java docs?

am not sure if there needs to be a line before @return for java docs

i think it would still be good to log the process though

maybe you want to use a private static final int MAX_PHONE_NUMBER_LENGTH = 20 instead of using magic constant?

yup, but what i'm thinking about is that it would be good to add a logger to keep track of the changes in the ui

i think this should be {@code ReadOnlyList>Patient>} instead of {@code ReadOnlyList>Room>}?

i think this should be {@code ReadOnlyList>Room>} instead of {@code ReadOnlyList>Patient>}?

makes sense, let me change it later

oh ya, i forgot. ill change it later

okay, let me change it now and update the pr

yup, i think i missed out on that, thanks!

i thought its already editpatient?

okay can can

whoops, let me rectify that

the - means that its deleted

all the red lines are deleted lines!

okay, will change it, thanks!

okay can, I will change it

i think instead of arraylist, it might be better to use ObservableList directly. ObservableList is what is passed into ListView (UI component) and allows the UI to be updated whenever there is a change in ObservableList.

okayy, ill change that real quick

yup, i will change the indentation. good catch

alright man, i have reverted all the wildcards imports! thanks for pointing it out

the "-" is to remove the patient from the room! so eg. editroom 1 pn/-, it will remove the patient from room 1

okayy, i will change it later! thanks for pointing it out

yup, good idea

i'm not sure how to use a switch here because the if conditions are all different, maybe you want to give me some suggestions?

yup sure! i will change it

cuz i feel like its not really an index, so grouping it under the index class seems wrong

okay, let me try it out

yes

because i have to check if the room is present in the ObservableList. There is no way to access the RoomList other than through the ModelManager.java. i don't think its suitable to have a method in ModelManager.java to check if the room exists and to return that room

sure, i can move the room related methods to RoomParserUtil

I'm allowing the users to set the room number already, so index might not be that great...

yup, i just changed it!

i initially used hasRoom() and setRoom(). i forgot why i didnt use hasRoom() but i didnt use setRoom() because roomList class already has setRooms(), i feel that it will be quite confusing to have 2 methods named so closely to each other but does totally different things

Yup, my test cases were failing, so I added a toString() to check. I thought about removing it, but I figured you might need it. Feel free to delete later. Don't think it matters

Hmm, now thinking about it, it does seem like bad design. I'll change this later and update this pr. I will probably use the observablelist.stream().anyMatch to replace this (so it will stay in EditRoomCommand.java but won't have a method) . Do you think its a good idea?

This is one of the dilemma I'm facing. Whether to have a static method in RoomList.java or have a method in EditRoomCommand.java (that is out of place). I think i will adopt the same method of just using the observablelist.stream.anyMatch() method and not create a new method. How does it sound?

Since i have to change other parts, I think i will just update it in case I forget about it in the future

thats true, let me shift the code there then

i will shift this method to the model manager also

okay sure!

HAHAHAH, i wrote it that way so the method name not so long. will change it later!

good catch on the ambiguity! i will make it clearer!

there should only be one patient in a single room though. also, it doesnt move the patient, you have to clear the patient from the room first. maybe for v1.3, i can implement the auto remove and move feature

yup, good catch. i removed it

because the original css also have scrollPane in it, so i specified the css

okay

because initially it was just internalList.add(sth) and it wasnt updating the UI unless i change it to setAll

not really, kinda forced to do it this way unless i dont use Index class for this method

if i dont use Index class right, then i'll be using integer instead. cuz if i use roomlist.getObservableList.indexOf(getPatientWithName("some name here"), it will return -1 if the patient is not found. but Index class doesnt accept negative integer, so it will throw out an exception

okay sure

so its kinda like a comparison of using int vs using Index, because either way, i need the position of the patient from the list

mayeb i will use this.roomList.getRoom..., because getRoomList returns the unmodifiable version

yup. i dont really feel its a hack tho, cuz the ModelManager is supposed to interact with the roomlist directly. We should make it so that other classes cannot interact with the roomlist directly and remove the getModifiableRoomList though

yup, wasnt really thinking sorz >>

that is true, we can look into this for next week

oki, i will do that next time HAHHAHA, didnt see

thats true

ya i think this one we dont have a choice but to couple them

You can take a look at the RoomListPanel.java for references. I suspect the problem arose because you are calling patientDetailsPanel = new PatientDetailsPanel(patientToDisplay) and patientDetailsPanelPlaceholder.getChildren().add(patientDetailsPanel.getRoot()) repeatedly. Perhaps you can move both these LOC from the handleMouseClick and updateDetailsIfChanged method into the constructor for PatientListPanel.java

i know its supposed to be like that, but i think we can include in the ug for better clarification?

we will probably delete this section

Can be taken into consideration for future design, will be closing this

i think it will take the last parameter

For 4, i will fix the RoomPanel by this Friday

as of v1.2 there is no feature that requires the generation of reports

interacting with GUI with a mouse* ?

Again, no reports yet

include date and time

This is not in v1.2

Don't edit the tutorial

Parameter name not changed

Good

uses '@' symbol

Comment: 32nd not 32rd

Comment needs to be updated

Looks like you forgot to change these comments as well

Comment should be day greater than 31 instead

Is it supposed to be date or Date, previously it was Phone not phone

KIV the prefix because this includes date and time

Perhaps it should be named modelDateTime

Missed this out

I personally feel that date and time should be separate, e.g. 01-01-2020 1200, we can discuss this in the team meeting tonight

Should probably be on separate lines

Should be named something more meaningful like status or taskStatus

Shall discuss whether these fields should be optional in the team meeting later tonight

Should be DATE_TIME

does this prefix make sense or do we need to revise it since its date + time now, maybe it should be due: for example

What is the purpose of this design wise? Is this to act as a null value without throwing NPE?

The rationale behind using java String#trim on Phone was to remove leading and trailing whitespaces. When considering the user's dateTime input do we need to consider white spaces inside the string as well? For e.g. "01-01-2020 1200" vs "01-01-2020 1200" if we are not going to trim it then perhaps we need to consider adding an exception for this and add the corresponding unit test.

Remove this

rename this

rename the date

why did you change this?

can change to complete or incomplete

has a state of incomplete

state of incomplete

May need to capitalise the first letter so that the UI is standerdized

integers*

separated*

Why is done not capitalised?

Do we need to use String builder or is efficiency not important? @BobbyZhouZijian

What does this return if the arg is empty @dearvae

do not add all the white spaces

no space needed here

why are there so many empty lines

what about status

Value of status* - this makes it easier for the user to determine what is wrong with their input if there are multiple attributes in a find command

Remove space

remove this space

why do you need to specify "which is null" when the attributes are the default values?

why cant the default desc be an empty string?

is it necessary to add an extra boolean when there was nothing wrong with the prev implementation?

fix this

I believe this is where you use parser util, code like this will be repeated, better to abstract it out

Too many checks, this is not ideal

remove this space

Where is the description for what an event is

^ same as above

fix this

hidden

list is missing

shouldn't it be

public static final DateTimeFormatter DATE_FORMATTER = DateTimeFormatter.ofPattern(DATE_FORMAT)

might wanna check if its null, javadocs specifies that it cannot be null, not sure if NPE will be thrown

hmm i already implemented this in lessonCommandParser, no repeated code, abstract this method out if needed

Magic number

MAX_INT = .....

then string format

Why is this called isValidTitle??? Rename

Test a few more values in each equivalence partition and especially near boundary values. Please include values such as 0, -1, some valid values and values near MAX_INT

e.g.

wont the user have to scroll down a lot to view the error message

This is repeated code, just renamed in both deadline and events, since both are a sub class of task, implement these methods in task and you can override later on

use the tags i have in commandTestUtil, do not use old tags from AB3

maybe name the parameters timeSlot and editedTimeSlot

timeSlot and editedTimeSlot

Good catch

Still valid?? awkward phrasing

with proper callouts and markdown

what about module tag and optional description?

manage their tasks and visualise it on a calendar as well as time spent on tasks and lessons

user with a lot of lessons

why did you quote UC05 isnt this UC05

and does not overlap

Why is it UC08/09

It is optional*

what does still valid mean? Maybe can specify that the task must not overlap with existing tasks or lessons after being edited

or overlaps with tasks and lessons

Remove

I think the space before status is not intended right

Hmm what about time or datetime

Maybe you should include the test for time and desc as well? Test the regex

Do lower case tags work?

this date is not in the coming week

not in the coming week

added extension

These are in addremark.md not actual code, not sure if it needs to be changed

same reply as above

ok undid changes in these documents, please review again

not in this PR

changed

done

changes reverted

this method is to list out the message constraints, in order to have a nice grammatically correct message the last type of task in this String should not contain a comma after it

e.g. Acceptable types of tasks are: A, B, C. instead of Acceptable types of tasks are: A, B, C, .

excellent suggestion, it works as well and is more concise

LOL i thought i deleted, it was for debugging 😃

yes need, good spot

Does not LGTM. Please include markdown for important commands or things to note of. Thanks.

Please include your portfolio under team/GabriellaTeh.md

Resolved merge conflicts and created a new pull request from a different branch

Hi Zijian, I conducted some boundary value analysis and found that it works as intended for the positive test cases but when i put in find status: it does not throw any error, it says 0 tasks listed, following equivalence partitioning i shall stop further tests

A few problems I found:

find status: XXX where XXX is an invalid input, returns 0 tasks found as well

Error message displayed should state that status can only be of 2 values: complete and incomplete.

find date:01-01-202 is also accepted and the date 01-01-2020 matches it, should this be considered an incorrect input

According to this method in Event.java this is not a bug @BobbyZhouZijian

@nuovonatura are you fixing this

I think you pattern did not match our command. Here is my suggestion:

(?>type>[A-Z]\s+)?(?>commandWord>\S+)(?>arguments>.*)

Maybe we rename this class to Contact now?

Ahh I see, just add another \ before each of the current

I think this should be kept simple, for example: "Adds a contact to the app" . This applies to all of your messages

You're missing the "T " prefix before the COMMAND_WORD here and at the example a few lines below too 😄 This applies to all 5 of your commands

I think the example for time here should have hour:minute as well, we'll support that too

As discussed, I think this should return a task's to string, and view it by Id! We won't have any find command

After coding I think that all of these "notes" like things should be called "notes" with a prefix of "note/", and this field is purely optional. What do you think?

for my iP I have written quite a nice date parser here, I think you can adapt it to this part (and add more supported format too)

this comment here is quite obvious right? I think can just write it as "Parses a Remark"

As I have commented on ViewTaskCommand, this should be modified accordingly

Ah my bad, by index

yeah I know, but like I want to create a special prefix for the note-like stuff, for users to throw anything they want into it

Okay then maybe you create an issue for that?

okay sure!

okay!

the Task.Type is missing here 😄

Missing Tash.Type here too!

should we merge Location into Remark now?

Not Email right?

Just wondering, is there any better way than manually checking 5 fields to see if they are null or not? I think there is a requireNotNull method as well right?

not String right? desc has type of String but for the message it should be Description

Not Double.class.getSimpleName() right? It should be Weightage

Okay sure

Yeah but for the message you can't output like "missing a double", better to just replace it by "Weightage" (a String) since the Double.class.getName() is basically get the name of that class

Hmm should we edit the module by index? or should it be index?

We haven't agreed on whether a task must be associated with a module or not right?

Should we merge location into remark now?

Should it be to switch to the module tab now?

love this simplicity 👍

actually it will like expand the task (view in greater details)

Now I think we should rename it to view

for this, is it better if we have the type like lec (for lecture), tut(for tutorial)?

"the length of the Lesson list" sounds a little unnatural, maybe "the number of lessons"?

not of that type right? now we changed to deleting by index already

same here, maybe "the number of lessons"?

why do you need to check Task.isValidString here? I thought only the latter check is necessary?

I think the remark doesn't need any kind of validity checking right?

Hmmm I think this is fine but later on probably I will abstract this thing to the "common" module

LOL It just crossed my mind, I think this is better as isDone (shorter and more "grammatically" correct haha)

hey this should be isComplete haha. A trick to faster change the name of a variable is to use Find and Replace haha

I think this method can be named like "flipDoneStatus", I think it will be a more intuitive name right?

yeah store it as an empty string is better

I think this can be better done by adding a new method to task, like belongTo(code) so that we don't need to touch so deep into task

Hmm is that SHOW_ALL? or show tasks that take place either today or after today

Okay this I think is fine!

Nicely done! Anw should we chain this together?

I think the index is one-based right?

I'm just thinking if it's better to put this logic in Model instead? I think Logic should only contain lightweight logic. Put it in Model will also make it more testable too!

Actually we should sort the internalList and just return the internalUnmodifiableList (because it wraps the internalList)

Any reason for this modification?

I think this should be named TaskSorter / TaskSorterByTime

Hmm yeah make sense! Maybe just keep it to see what the UI team will say 😄

Ah okay! But the index to display is one-based?

Ah I see

Hmm I just realized, aren't we comparing tasks by time?

this is a stub so it will always be like that

lol what's this

Not address book any more, it should be "Add a contact to the app"

This should be "displayed on the screen"

Can you look at Minh's new messages and standardise the message content?

It should be in the form of [DONE] + Name + Date: .... right?

we don't have the app-wide search anymore right? It will now be a contact tab?

Heyy you still need to edit it here too!

"basic operations" should be like "basic components"?

"The task manager is a crucial feature in TrackIt@NUS" same as above? I think it can be written like "The task manager is an elemental part of TrackIt@NUS" or something like that

Maybe also note that if a task doesn't belong to any module, it can only be viewed in the Upcoming section

not only the add but also the edit command as well

execute -> Execute

Also, nice use of process diagram here!

I think the CommandResult's label is missing, it should be "r"

Hmm do you think the name of objects should be longer? like model & task instead of m & t

Do you think we should highlight the self-call to createEditedTask?

"all tasks that belong to the specified module code" I think we can delete the trailing "code"

I think a better rationale(or at least better sounding haha) is that we implement all commands in a very similar way so that the logic is uniformed and also for better maintainability / less prone to bugs.

But I don't know should we place this here or put it in a more "general" section of this DG? And put more task-specific design consideration here?

I think we should put the shorter type before the longer type!

can you move all of these messages to commons/core/Messages.java?

Hi, I think the address should be more realistic (throw in some sample zoom links, some venues at the school like COM1-0120....)

hmm it's quite a big problem. Anyway, can you change the address to some random locations in NUS to make it more realistic? Because this is the sample data we will show the user too!

I think we can edit this sentence to this: " Phone numbers have to consist of just digits only, and can be of any length!"

Just a recommendation: I think the sample command should include 2 tags(same for edit contact) so that the user will immediately know! (Also, can you change the sample command in AddContacts & EditContacts as well?)

I think we can add in that email & phone number are optional!

Same as above!

The INDEX provided must be one of the contact' indexes being shown on the window? Does is sound better?

I think the message should be more specific, like "There cannot be more than 10 modules at the same time" or smt like that

Right now I think that this predicate section should be put in like a "general design consideration" section, because for lessons they will copy-pasted this exact thing, but on the other hand doing that will make our DG looks "shorter" and "less effort", so I'm not sure 😢What do you think?

I think this section should have a dedicated section like "Code design consideration", and also we should add in a "Feature design consideration"

Like this:

I think "to have everything" sounds "broad" and "big", maybe we should make it more specific or more reader-friendly?

I suggest we can change this to something like: "want to have their personal todos integrated with the academic calendar"

Hmm I think no need for this, because I think our app is good on its own and even with Internet there is nothing more we can improve 😄

My bad😢

True

Hmm I have removed this class already?

Ah okay not yet, my bad

Can you take a look at my new PR?

If that PR is good then can merge it first, so that there won't be too many commits in a PR

Okay I forgot. Actually the original code doesn't explain the returned result too (maybe too obvious?)

Yeah, since originally there were setContact and setContacts as well

the original code base doesn't have that throw as well. What do you think? (Honestly I haven't read about when we should state that this method will throw something and when we can just omit it). Anyway, will read it later on after I finish developing these 3 classes

I think we should best leave it as TrackIter (short,concise name). LOL It took me 1,5 hour to rename address book to TrackIter 😂 (And still there are a lot of leftovers)

Fixed in the latest commit

Okay lemme fix it now

When I thought on how to handle the program's logic, I found out that putting lessons and tasks in Module will make it way harder to find/delete tasks & lessons. Instead, I think that we just keep lessons and tasks in separate lists and everytime we need to find lessons or tasks of a module, we can just do a O(n) search. This will make the program's logic much simpler and less prone to errors

Yes. Is just a more detailed type of exception, so it doesn't need any implementation

It will be fixed in the next PR!

Wow I think this is a bug happend when I'm copying things

fixed!

Ah okay okay let's enable it

@simonteozw Maybe you approve this PR first then I make another PR? I just run the code formatter and it changed like 80 files

Actually I wrote the message for this exception already, but then deleted it because the exception caught on the very next line. Should I comment on why I leave that message empty or just write a message in it?

done!

this the auto toString method generated by IntelliJ. It will be used for testing only so I guess it's best to stick to the default format

for testing only

Sure

There is a warning that the operator (like + for string concatenation) must be on a new line, but I haven't found a way to make IntelliJ auto-format for that, and it's really minor so I will just disable it for now

Hmm because I haven't been able to get the IntelliJ to conform to this rule, and this is very minor (it's just the position of the operator) so I think it's best to disable it for now (if not forever)

No it's a good thing to keep, why need to remove right?

Yes, because as we have discussed this will be a "bonus" feature. I just leave it there so that later on we remember

Sure!

Ah yes, it's the formatter of IntelliJ, it auto-align the comments of params

Okay

Hmm then should we rename the method to getAllTasks()?

Yep I will remove that in an upcoming PR, but for now just edit it 😂

Actually the current hasModule is doing exactly this 😆 two modules are consider "same" if they have the same code

Actually I changed this so that it can be used for cases of module not exist in Lessons. The original version is only good for delete module

It has been moved haha

Fixed!

because now missing phone is not an error any more, later on I will convert them to positive testcases

Yeah I think we can!

Optional.empty here is actually still valid! null will throw exception!

Actually in the upcoming PR there will be several more TODOs, it's a common & quick way to note that there are things todo haha since IntelliJ can highlight all todos in the project when you want to!

Fixed! For the commit I just pushed to fix this I have manually tested deleting phones & emails and it all worked well!

fixed!

Yeah I copied his name from SoC's website 😄

because argMultimap.getPreamble() is actually to check if index is present, which is unnecessary in this case (in fact this is leftovers of copying from AB3 commands)

Sure!

it is very different because the IllegalArgumentException is an unchecked exception, which doesn't require the caller to try/catch for it. In other words, this function will crash the program (assert-like) if the provided date is invalid!

Also I will capitalize the "a" now

Done!

done again!

because I have added a very similar testcase to line 41-45

Ah this I copied from TaskTestUtil but realised it's not usable yet

Yes, I realised it too but I forgot to raise it up during yesterday's meeting! Will send Simon another PR.

Ah I resolved it already! Forgot to close this issue

@simonteozw can you review this commit then merge it for me so that the next PR won't be so huge

Actually "commons" in the name of one of the current module too! (seedu.address.commons)

Ah that checkstyle, I think it can be disabled for now, later on when I merge the later pull request I can enable it back again! Actually we can do cherry-pick there but I haven't had time to properly learn cherry-pick

@nguyendqminh can you take a look at my message above and provide me the deadline that you will resolve this? Thank you!

@simonteozw Hey can you take another look? If it's good then you can approve it so that I can make the final PR for Lessons

@nguyendqminh Hi, any updates on this?

@nguyendqminh Can you push your commits to the PR so that the team can know your progress? Thank you!

@simonteozw Hey. I think this PR is quite simple but I think it's best to have you do a quick review of it! Thank you!

@simonteozw this can be closed now right?

Closing #109

@simonteozw Hi Simon

So basically in this PR, I did the following things:

For Contact: Removed List & Clear commands
For Lesson: Removed List & View commands
For Module: Removed List & View commands
For Task: Removed View command
And I refactored all the common messages between commands to Messages.java + Standardised their names

Thank you for reviewing it!

Looks Good. I just want to check, if users edit and do T edit 1 m/ is it still a valid command? It should change the module code to null

Yep it will change it to null

Is this ready to be merged? @simonteozw

Hi @simonteozw . In this PR I have made the following changes:

made Email & Phone to be optional (this took quite a lot of time but I have done some manual testing and it seems to be working well)
replaced the Task.isValidString by a simple call to String.isBlank (because I think your intention is to check if a string is blank or not)

Please help me review this PR! Thanks a lot (x100)!

@nguyendqminh please help me clarify this in the UG!

@simonteozw Can you please check for Modules / Lessons / Contacts as well? Thank you!

@UncleGrandpa925 Please update the UG to clarify this!

@nguyendqminh Hi, can you help me clarify in the UG that the entered Index must be one of the indexes that are appearing on the screen? Thanks!

@simonteozw Please help me clarify this in the top section of the UG! Thank you!

@simonteozw Can you help me clarify this in the UG? Thanks!

@simonteozw Please help me clarify it in the UG! Thank you!

Hi @simonteozw . Actually this PR is kinda simple and there is not much to review, yet I still request your review so that you can know about the newly added test skeleton! Thank you!

@nottiffchan Can you check discord?

After this is done, a new issue will be created to edit the UG

Hi @nottiffchan since you are in charge of the UG now I will transfer this issue to you! Thank you!

Hi @simonteozw I think this PR is good to merge immediately but I just want you to take a look to see what I have done in this PR (mostly for the refactor of Lesson's messages, I wasn't aware that Lesson's messages structure were quite messy)

Can you change this to docs/UserGuide.md

Should we remove this *{More to be added}* line?

Can I ask what is gradeDist? Is it grade distribution?

Can I check why we are checking if other is instanceof Name? We should only check if other is also a Location right

Another instance here. I think should be other instanceof Location right?

Should we use Address Class for Task as well? I am unclear if there is a difference between Location and Address class class haha

Just curious, why did you remove the (String) typecasting?

Need to fill in return value here

Can I check, what is the difference between setModule and setModules? They are for different use cases?

Should ass throws ModuleNotFoundException, DuplicateModuleException to the method declaration right? Same for several other methods.

Just thinking. Shoudl we change this TrackItManager? Or TrackIt? haha. If it's too troublesome to change then nevermind.

Ok then we just leave it first. If need be we will let the others add in these methods when they implement further

Maybe we should add throws NullPointerException in the method declaration? Or remove that line in comments.

Can delete the @return here as well, or add the return value

Is this method supposed to be empty?

Can I check why this is removed? Are we leaving it to later to implement?

Why is @Override removed? The getTaskList method is from ReadOnlyTrackIter so we should keep the @Override right?

Is this the final PR for concrete classes? If yes we should re-enable checkStyle

Can remove this comment

Same. Can remove this comment

Here too. Remove comment

Remove comment

Should MESSAGE_USAGE be L list: sample? Maybe change to another word like CS2100 to make it clearer?

Remove Comment. Maybe change MESSAGE_USAGE to have a clearer keyword instead of sample

Should be There is no module matched to the given module code. Missing the to.

Maybe can add an example, like in AddContactCommand

Same here. Maybe should add example.

Same here. Maybe add example

Just curious. Is there a need for PREFIX_TYPE when there is already a PREFIX_NAME? OR this is just for clarity when reading code?

Since the function is parseTime, maybe should change Lesson.DATE_MESSAGE_CONSTRAINTS to Lesson.TIME_MESSAGE_CONSTRAINTS? Just a suggestion haha

Yes this sounds better

Should the ParseException be thrown with empty string? No message?

Can remove the 2 lines of whitespace here

Same here

Hmm maybe write the new message on this line then in the following line you can write catch (ParseException pe) { throw pe }

I meant here, lines 17 - 18

Actually I meant here lines 17-18

Maybe change the comment here address book to app or TrackIt

What does this do?

Why do we need this toString method? Maybe change to Code: and editModuleDescriptor: instead of code= and editModuleDescriptor=

Why do we need this? And Maybe change to Name: is this for testing purposes?

maybe can remove the @FXML private Label desc on top too

Hmm I think we should enable it before merging right?

Oh I didnt IntelliJ will autogenerate toString methods. Do you plan on removing this? Or keep it just for testing

Ok, but I think before we submit v1.3 on Friday we should remove this

Is this supposed to be commented out?

Should we specify this for Lessons?

Maybe remove the (must be a positive integer) since you already have the INVALID_INDEX_MESSAGE. To keep it consistent with Task and Module. Same for DeleteLesson Command too

Should this throw an exception? Or is there another way to handle this?

This will be changed in a later PR?

Actually for this I wanted to check why you need this method here. Why not just sort the lessons in UniqueLessonList under the function asUnmodfiableList(). Then everytime UI calls for a list of lessons it will be sorted

I think should change to Names should be a non-empty string and should not contain '/'

Is the extra space supposed to be there?

Actually this method just returns all tasks so lets change the comment to @return the list of all tasks

I think change to @return the list of all tasks that take place on the specified date

I think we can do this later. I believe UI team may feedback and we may need to refactor the method signatures abit anw

Out of curiosity, why change this? I don't see anything wrong the old version

Actually I thought we were going to remove the ListLessonCommand, or are we leaving that to a later PR?

This works? hasModule only checks based on code and not name?

Why is this removed? Is it because not called at all? Minh wanted to keep this in initially so maybe should discuss w him before removing it

Wouldn't it be better to keep the import so you dont need to type java.time.DayOfWeek

If you remove this, how will we ensure that Lessons are always sorted?

If you remove this, how will we ensure that Tasks are always sorted?

I think for the messages about duplicates, all should end with already exists, no need already exists in the app.

Can we shorten this to 1 else if { instead of else { if { ?

Same as phone

Should this be Optional.empty()? Or maybe we should add another test case for that

Why are these lines commented out?

What if the contact originally has a phone number and the user wants to edit to remove it. This will ensure that if the user types C edit 1 p/ the phone number will remain unchanged when it should be changed to null

I think we should create a github issue abt this so we dont forget about it. And include all the lines we commented out so we know what to replace.

I think this should be changed to get index of

Same here. get index of

Sorry I just realised, should you update the predicate to show all Modules? Or doesn't matter. In task and lesson we will predicate first

I think we should remove the dd/MM/yyyy hh:mm. Or I can do that in my own PR later

Why did you remove !argMultimap.getPreamble().isEmpty()?

Is the CHIA intended to be all caps? Haha

Hmm Actually how is this different from the normal parseDate? And why not just use the same Messages.DATE_MESSAGE_CONSTRAINTS? In any case, I think the first letter should be capitalised: An invalid date...

Sorry actually for grammar it should be "An invalid date has been passed into parseValidDate"

Hmm why did you remove this test case?

Should be The Class Diagram above

Can I check how come suddenly need to add this?

I think we can change this to COMPONENT_NAME Manager class

Just some grammar. Can change this part to clicks on a module tab not click on a module tab.

Somehow the Note is not correctly displayed. But since we already have the information source I think we can just remove the Note completely. Also, change last line to due to a limitation in PlantUML, the lifeline continues to the end of the diagram

I feel that this function should also check if the module alr exists in trackit? Or maybe rename the function to hasEnoughSpace to make it clearer

Why is this commented out?

Ok I tried to change to this but err java gives me an error: Illegal escape character in String literal

What do you mean by view it by Id. Task doesn't have ad id associated with it haha

Hmm actually I think writing note/ will be very cumbersome, and may confused users because they are used all 1 letter not 1 word

Hmm ok then can I suggest we stick to r/ for remark, I believe note/ is too cumbersome

Hmm I am following the standard comment format. I think better to keep it this way for now

Ok. I suggest for now we leave it as is. Since Lesson and Task have a date component, we can standardise once both have been merged in and refactor it to be one of the 'commons'. Then that will be cleaner. Maybe leave for v1.3

I think that will require some refactoring. I suggest I create an issue for it and we settle in v1.3

Yes but apart from checking not null, we must also check if the fields fit the specific requirements, which differs for each requirement. Maybe we can look into it, but probably for v1.3

There is no description class. Description is stored as a string thats why I used String

There is no Weightage class. Weightage is stored as a double thats why I used Double class.

Yes ok I will change it

I think we can just leave it for now

This is to support the feature that when the user types c/ it will reset the code to null, in other words they can remove the module code. If only have the latter check c/ will throw error

Same as above. I want to distinguish between storing remark as null vs storing it as an empty string. Unless maybe it is better to just store all null as empty string?

Ok I will leave it first then

Hmm ok I shall refactor this

Hmm I did this because I wanted to show overdue tasks if there are any too haha. But ok I can change it

We get the int based on indexOf, which is zeroBased, so when we return the Index object we should use the fromZeroBased constructor

All these date changes are just to pass the test cases. Because the task list is automatically sorted by date

Yup! But displaying it as one-based will be done by UI team

Hmm yes I suppose. Will change it

Ok I shall remove it then. There is already a Contact Manager section

I considered that but I am not q sure how to draw that out in UML

I think we can put this in th eArchitecture section of the Dg

Hmm yea I will change it to the general overview section

Done

Just finished refactoring. I think we can merge this first then I can create another PR where I rename the files to AddContactCommand? and etc

Also rmb to fix issue brought up by Weihong. criminal lawyer is not alphanumeric.

https://discordapp.com/channels/@me/763052081266950177/763128915186155520

Core issue is that All Edit and Add commands were designed to update the predicate to show all Contacts/Tasks/Lessons. This is not good for stuff like when you are adding a Task in the Module or editing a Contact/Lesson in the module. Hence, I removed this Predicate

Is this ready to be merged? @simonteozw

No don't merge yet. I will request a review when it is ready

Could you change this instance of 'AddressBook' to 'Athena'?

Change this instance of 'AddressBook' to 'Athena' as well

Adds >i>an>/i> event instead of >i>a>/i> event

Consider adding Javadocs to this method and the newly implemented methods below

What exactly is this change?

Please commit only relevant changes to the branch in the future. This is probably more relevant when adding the editEvent command

Add class-level javadocs for this class

Update this javadocs for the context of AddEventCommand

Use the >code>// some comment>/code> for this instead of >code>/* some comment */>/code> as that is relevant only to the method/attribute right below it which in this case is >code>PREFIX_DESCRIPTION>/code>

Please include class level Javadocs for this

Consider placing this into the constructor?

Update javadocs to specify calendar

Update Javadocs to specify it is about events not persons

Add class level javadocs to tell us about the class

Add class-level javadocs to tell us about the class

What is the difference between these two methods? Should the >code>setEvent>/code> method check 'equality' between two events and replace the one in the list with the one outside?

I believe this replies to the wrong part of the review? Please use this only to reply to the specific comment above

Consider adding this method and the test methods below to a separate class called >code>AddEventCommandTest.java>/code> to separate tests for Bangyi's >code>AddCommand>/code> and tests for your >code>AddEventCommand>/code>.

Consider adding these messages as constants instead of magic literals

Is the prefix necessary at all?

Should be able to obtain the index directly similar to the Delete command for example

This seems to be outdated compared to what is actually implemented

Would be nice to have a brief Javadocs description of the class

This Javadocs is outdated

Should probably remove this as it is not used at all

Should remove this from the interface and the implementing classes

Should probably remove this as it is only used by the unused sortPersons method in AddressBook

Should probably remove this as it is not used at all

This method should probably take in a Comparator instead in line with how the updateFilteredPersonList method works. Model Manager shouldn't need to know exactly which Comparators it needs

The three comparators should probably declared as static constants within the SortCommand class itself?

This should probably be done in the SortCommand class itself. execute chooses the appropriate Comparator in the execute command to pass to ModelManager.

Does each class really need to know the COMMAND_TYPE string? It seems like it would be better to just have the AddressBookParser store the main COMMAND_TYPE string variants. Either that, or these classes should be taking the AddressBookParser's COMMAND_TYPE definition. Because right now, to change the COMMAND_TYPE string, every single file has to be edited

And it seems that the COMMAND_TYPE String is largely not used except to reconstruct the equivalent user input

I would suggest something like -c and -e instead of /c and /e as I believe we should differentiate field specifiers from object-type specifier. Especially since add /c n/some name looks kind of strange

My suggestion was actually to not have this at all. But the enum-type would probably be the second best alternative as both AddressBookParser and the relevant commands will depend on the String specified in the enum-type. Because as is right now, the current implementation is the equivalent of the cyclic dependency you mentioned, just not strictly coded in. If you change AddressBookParser's string to detect Contact-type commands, then you'll still have to change those within each Contact-type command class.

If you're removing references to the Command-type string inside the Command classes themselves, then the reconstruction of user input tests have to be moved to AddressBookParserTest instead. The individual Command-types will handle only their own share of input (everything that is after {command name} {contact/event}

I think only one enumeration is sufficient (CommandType). Because 'add' is a unique identifier for the AddContactCommand, or at least it was. But I feel like the reason both AddressBookParser and the individual command classes should not hold the contact identifier's specific implementation within them is that it is a property that they all share and depend on. So a separate enumeration would fit this.

I change my mind regarding holding references within the command classes themselves to their CommandType. It does make recreating the command for testing easier.

i think there is merit in having the test cases remain in their current classes as they are intended to test certain classes.

I don't think this is really relevant to the discussion because the individual command classes don't actually use their own command word and command type for testing. Only AddressBookParserTest uses them to recreate it.

specifically, i believe it should be

public static final String COMMAND_WORD = CommandWord.SORT.toString();

public static final String COMMAND_TYPE = CommandType.EVENT.toString();

would it be possible to add the 3rd line into a separate branch to continue working on? as you have mentioned that it is not quite implemented yet. So we should merge only things that fully work to master

Related to the above comment, to add this to a separate branch and subsequent PR so it is obvious to us what the changes are in the future PR.

although i think it would be better to have the detection of invalid inputs handled in SortEventCommandParser.parse.

the SortEventCommandParser.parse is already implemented. But I do agree with the suggestion regarding the default branch. I think it is in-line with defensive programming to reserve the default block to throw an exception instead in order to protect others who might be using the code.

This comparator does not seem to match the description specified in the indexMessage(Index) and MESSAGE_USAGE. This seems to compare the number of tags instead of the number of participants.

This doesn't seem to have any indication of the actual number of participants though? It seems to mostly just compare the tagName string-wise. To get the actual number of participants from each tag, I believe you need to use the model.getPersonsWithTag(Tag) method to get the actual Set>Person>

but tags are not the same thing as participants?

Also the comparison itself seems kind of strange. If o1 has 5 tags and o2 has 10 tags, this falls under the last branch which compares only the first name of the first tag found in the set. Also, I believe this is prone to changing as Sets do not have a well-defined order.

I was under the impression Events would hold a Set>Person> (added without any specific tagging) as well as a Set>Tag> (of groups of participants identified by the tags). The total number of participants would then be a conjunction of all the participants found from the Set>Person> and each Set>Person> belonging to each Tag.

I believe this is a typo

It seems to me that this comparator has some issues. In particular, the tags are actually stored in Java's Set which has no guarantee of order preservation. So this could result in different comparator results on different calls of the compare method.

I believe this might be related to the same Comparator in SortContactCommand

Additionally, consider creating a PersonsComparator class which stores all these comparators as public static constants so that both sort commands can refer to the same Comparator object.

consider using case 1: return NAME_COMPATOR;... and throw a CommandException for the default branch. This can potentially safeguard the code from misuse by other developers.

Will this fail if a sort is performed on an empty Athena? Perhaps, it should instead just not do anything if the list size is 0.

I believe the name of the method would be more appropriate as something like permSortContacts or permSortPersons as we will eventually need to remove instances of 'addressbook' within the code. Additionally, I believe the argument name would be more appropriate as something like comparator as chooseComparator sounds more like a method name.

Would be nice to include test cases that check against the permanently saved file to see if using the command changes it.

Is there a guarantee that the first tag being displayed in the GUI is the same as the first tag found in the set.iterator()?

On a related note, I wonder if this comparator is necessary because it seems quite arbitrary. I was going to suggest perhaps some sort of way to request sorting in the reverse order, so the name comparison would put Z at the front etc. In this case, I think a comparator that allows sorting by number of tags might fit this better. Though I am unsure how this might be useful as well.

Do reflect these changes within the origin SortContactCommand as well. Thanks!

There is an additional '9' here. Also consider leaving a line between the class declaration and the first javadocs

Consider changing the description to be something more explicit like: "Permanently sorts and edits the underlying save person-list save file" to clearly say that this changes the save file.

Also consider changing the argument name to just comparator instead of chooseComparator

This internalList assertion seems slightly problematic. Given an invalid json save, the json save would be wiped out and replaced with an empty json save. This will create an internalList with size 0 which seems common enough to not warrant an assert. Perhaps a simple assert c != null would suffice.

"A window similar to the one below should..." instead of "The GUI similar to the below should..."

ContactTagIntegrationManager has a method for deleting a tag and all contacts with the tag. I think it's called deleteTagAndDirectContacts method that does that. I think you should use that instead as it properly preserves the tag relations in the tagTree as well. Can implement it in Model

If it can't throw, the method should not have a throws keyword. Any other method that uses this are forced to implement catching the exceptions or throwing them again. Which is not the same as "this method cannot throw a CommandException or a ParseException, handling can be ignored".

you realise that any command that uses execute has to either catch and deal with a CommandException and ParseException or it has to throws it as well?

Also, it would be really helpful to say why something isn't a good implementation instead of brushing it aside as one.

I don't think this is quite right. More specifically, the term used here should be Command Line Interface.

i second this

I second this.

contact at the specified INDEX

is more precise as it denotes that we are referring to the contact instance occupying that INDEX at the moment.

same as above

This does not seem to follow the general example format of other commands. The format usually goes as

"{command} Sorts all currently ... " starting with a capitalized verb

This does not seem to follow the general example format of other commands. The format usually goes as

"{command} Sorts all currently ... " starting with a capitalized verb

In markdown, the difference is significantly more prominent. I do not think this is a necessary change.

In the context of markdown, the change does not make any difference.

"There is no need to save manually." is more succinct and less awkward than "There is no need to manually save the data.". The inherent meaning is the same.

I would argue that where the save files are located should come before what the save files are. Would like to hear your thoughts on this.

I believe only Tags have the view command. Events might have one in the future but it is not implemented yet.

perhaps this should return a list of accepted CommandTypes? Otherwise, I think the name is slightly misleading. Maybe something like getAcceptedTypesString() {..}

Besides the MESSAGE_INVALID_SEARCH_FIELD, the rest seem to overlap with the ViewTagCommand. can consider abstracting these out to a general TagUtil class.

I believe this method is also shared in ViewTagCommand. Can consider abstracting it out as well

Pretty daring to change the sample test tree. But I guess maybe the original one might not have been comprehensive enough.

great catch!

The 'This' is not necessary here. Adding it here would only confuse the reader as 'This' could refer to multiple things in this context.

Please leave the original. If you want to change this, it would be more precise to say 'Tag removal is done before tag addition'.

I think we should default to the one without a space.

'Indices' instead of 'indexes'

My point is that adding 'This' is a language error. Adding 'This command' is redundant because the entire statement is about the command.

'This command' is really not necessary. It is implied at the start of both sentences

As it turns out, private comment Javadocs are not really standardised throughout the code. I think this is not a big issue

it is a runtime exception. I do not believe it is necessary. Especially since there should be no reason why this exception occurs at all if Person changes are done through AddressBook.

Is there a difference in wrapping in an Optional? It would still be

Optional.ofNullable(tagPersonSetMap.get(tag)).orElse(Set.of()) which I don't think is much better

Ok, as it turns out it's only one instance from the original. The description of the getFilteredList() from the Model interface. I'll change it

This was supposed to be 'contains only tag-person mappings from the persons list.' The original message was not written very well. Thanks!

yes, thank you very much.

or would be appropriate, thanks for pointing this out

I think the individual behaviors have to be explicit. In this case, the upcoming editTagCommand will specify tags to add and tags to remove as two separate tag sets. As such, I wanted to be clear here on the behavior of the method for each case.

The documentation of these methods' purpose is in the TagTree abstract class. I wanted to leave open the implementing class in the event someone could come up with a better underlying system for it. Admittedly though, many classes do depend on associate with TagTree and as such, depend on TagTreeImpl anyway.

i am genuinely unsure about this. Perhaps you could decide and tell us? I do believe the original JsonAddressBook class uses json instead of JSON.

yep. the requirement for a tag to exist is that it must have at least one contact with the tag or the tag has at least one child-tag.

tagtree handles tag to tag relations. addressbook handles tag to person relations. As such, one can be in one without being in the other as the requirement to exist in either is that it has at least one object assigned to it.

I believe so. This is for when someone performs ctrl+f "parent-tag". I could restate the same thing for "parent-tag" but I think the two are close enough in proximity unlike in the glossary in UG.

instead of using "and also", i changed it to "..., then ..." which is closer to the actual implementation anyway.

I changed it to "if available" to say that not every method related to tags and contacts is inside this class. Only those that might affect both at once. Some other methods will still need to be done with AddressBook and TagTree.

I believe it's "the" set. I thought about this and settled for "the". "a" seems to imply that there exists multiple sets containing different number of Person objects that have the tag.

Well, I would argue that ModelManager is a Facade class. Having two methods implies that ModelManager is now handling logic that should be implemented elsewhere.

Also, as mentioned in the PR, deletePerson does in fact affect Tags as well. It could possibly remove a Person that has Tag1. And Tag1 might have only one contact which is this Person. This causes Tag1 to be deleted. If Tag2 is a parent-tag that only has Tag1 as its only child tag and no direct contacts, then Tag2 should also be deleted. Thus, I believe this, and the other edited methods should be implemented in ContactTagIntegrationManager. Given a choice, I would have refactored the entire AddressBook and TagTree into ContactTagIntegrationManager but it seems a little too late to do that.

This was the cause of a bug that I found that I believe is the cause of the issue attached to this PR.

Thanks for pointing it out anyway. Appreciate the review!

good point, thanks

Issue has been fixed! Thanks for the notification. I ticked the 'Require status checks to pass before merging' option without realizing that I had to specify which CIs I wanted passed before being able to merge. This has been addressed and our CI is now passing.

Is the sort method supposed to sort the current shown list? Or is it supposed to sort the full list of contacts before showing it? Because the former would be much easier to implement and I believe is what we intended to do originally? There is the model.getFilteredPersonList() method which gives the last shown list.

Also, I agree with the Hendey's comment about the sortPerson method. I do not think that all the model classes need to have such a method.

Please settle the merge conflicts by including both methods for the two different conflicts. Then it'll be good to merge. Thanks!

Looks good to me. I'm just wondering how the TagManager class helps to keep track of the participants (persons) of a particular event without implementing necessary changes in Calendar class or respective events class?

This was done mostly with the context of supporting Bangyi's delete by tag and add to events by tag. Shouldn't the Event's class have references to the Tags it contains similar to the Persons it contains? Anyway I believe someone else is implementing this. This was just to help support that.

I don't really agree with this. I believe that we should limit the options the user has in this case. Otherwise, suppose a user creates a tag Cs2103 and starts assigning things to it. This tag will be permanently stuck at Cs2103 and unless we give them a new command to change the specification of the tag name to either CS2103 or cs2103.

Not to say that forcing upper-case is definitely a better solution than what you suggested, but I do feel that enforcing capitalization is a more agreeable policy as opposed to someone not realizing that they can't change the capitalization of their tags after adding hundreds of contacts under the tag.

Upon further deliberation, I realize that an edit tag name-type command is inevitable. As such, this should cover whatever I was concerned with initially. Thanks for the suggestion!

On further further deliberation, I realize there is still a necessity to standardize the capitalization of tags. When two separate Persons are added with tags cs2103 and CS2103, should a lookup of the tag produce both? Otherwise, if yes then why not standardise how the tags themselves look. If no, then I personally feel that it kind of beats the point of implementing search by tags to begin with.

I don't think this is the way to do it. We should probably refactor and separate it out into separate interfaces like CalendarModel, ContactModel and a final CombinedModel so that we do not need to keep adding to the AddContactCommandIntegrationTest model stub and keep having to change other test cases

Hi, could you clarify the purpose of FauxPerson and why you chose to use it instead of a direct association with Person?

The bug description isn't very helpful.

I'm not saying that there isn't a bug but perhaps doing a list -t to show us if there are any left over tags that were not properly deleted from related interactions. And a view -t t/family would be helpful too.

This seems trivial. The idea is that if and when we add more terms into the glossary, these definitions will be separated from each other. We can still click on the glossary links to view the related definitions.

Also, I can't believe this person put severity.Medium for this.

This also seems trivial. Anyone feels that we should implement unique email address?

As a team, we intended for tagging to provided extended functionality for experienced users. Perhaps, we could add that to the user guide to specify that tag-level commands are only relevant for experienced users who are dealing with greater number of contacts.

The point of the list command was to give a brief summary of what tags exist and who is under which tag. An issue already exists that if they were too many contacts under 1 tag, it would fill up the panel. As such, we reduced the information present to only what is immediately relevant and required, with the supertag notation denoting that a tag in fact has child-tags.

The view -t command already exists to view full details of a tag including all child-tags, all other sub-tags, and all related contacts.

Additionally, regarding the last point, it was an explicit choice to not do that. The idea being that there exists groups of people of a parent-tag that are not part of any of the child-tag groups. We did not want deleting a tag to suddenly add 20 child-tags to a contact that once had the tag.

The reconnection of deleted tags was more a way to preserve the top-down hierarchy. As deleting a tag in the middle of the tree should not immediately disconnect all child tags as they are still technically a sub-tag.

Just a comment regarding single responsibility principle

My understanding of this is that ModelManager class should definitely not handle the logic of both removing the Person and editing the TagTree.

Tertiary student instead of Tertiary students

expenses/incomes instead of expenses/income

Manage instead of manage


* Responsibilities: Scheduling and Tracking, User Interface




/**

 * Parses input arguments and creates a new AddExpenseCommand object.

 */

Add the full stop. The corresponding comment in AddIncomeCommandParser should have a full stop as well.


        assertParseFailure(parser, "1" + INVALID_TITLE_DESC, Title.MESSAGE_CONSTRAINTS); // invalid title


     * @throws ParseException If the user input does not conform to the expected format.

Either


        INCOMES,

        EXPENSES,


        INCOME,

        EXPENSE,


    public void parseCommand_unrecognizedInputWhenOverviewTab_throwsParseException() {

Also in other similar places.

Is it possible to not hard-code the value 7? Same as in ListIncomeCommandTest and ListTransactionCommandTest


        assertEquals(model.getFilteredExpenseList().size(), getTypicalExpenses().size());

This together with an additional import statement:


import static ay2021s1_cs2103_w16_3.finesse.testutil.TypicalTransactions.getTypicalExpenses;


        // ensures that outOfBoundIndex is still within bounds of finance tracker list of expenses


        // ensures that outOfBoundIndex is still within bounds of finance tracker list of incomes

Line 73


// ensures that outOfBoundIndex is still within bounds of finance tracker list of transactions


    - Add a class to store frequent expenses/incomes (such frequent expenses/incomes will be in a separate list)


    - In Analytics, make use of `YearMonth` instead of `LocalDate`


 - Investigate feasibility of UI testing. If not viable, then remove it from the testing suite.


        Expense editedBubbleTea = new TransactionBuilder(BUBBLE_TEA)


    public static final Expense TUITION_FEES_2 = new TransactionBuilder().withTitle("Tuition Fees")


    public static final Income TEACHING_ASSISTANT_2 = new TransactionBuilder().withTitle("Teaching Assistant")


    public static final Expense BUBBLE_TEA_2 = new TransactionBuilder().withTitle(VALID_TITLE_BUBBLE_TEA)


    public static final Income INTERNSHIP_2 = new TransactionBuilder().withTitle(VALID_TITLE_INTERNSHIP)


            assert (transactionToEdit instanceof Income);

            return new Income(updatedTitle, updatedAmount, updatedDate, updatedCategories);

Since the previous assertion was removed, maybe an assertion here might be necessary? Same for similar occurrences.


            assertTrue(transactionToEdit instanceof Income);

            editedTransaction = editedTransactionBuilder.buildIncome();


            assertTrue(lastTransaction instanceof Income);

            editedTransaction = editedTransactionBuilder.buildIncome();


            assertTrue(transactionInFilteredList instanceof Income);

            editedTransaction = editedTransactionBuilder.buildIncome();


* On app launch: Initializing the components in the correct sequence, and connecting them to each other.


    public static final String COMMAND_WORD = "convert-frequent-expense";


    public static final String COMMAND_WORD = "delete-frequent-expense";


 * Deletes a frequent expense identified using its displayed index from the finance tracker.

Remove unnecessary newlines.


    public static final String COMMAND_WORD = "edit-frequent-expense";

Should FrequentExpense be a subtype of Expense? Consider the fact that they appear in different lists, and are treated very differently. Moreover a method to convert a FrequentExpense to an Expense is implemented .Also note that FrequentExpense should not have a Date field, since its date is undefined. Only the Expense that it converts to should have a date.


public class FrequentExpenseList implements Iterable<FrequentExpense> {

This follows from the class TransactionList and the deprecated ExpenseList and IncomeList. This will account for the method iterator in line 82.

With reference to the comment on line 11 in FrequenceExpense, date should not be present.


     * Constructs a {@code JsonAdaptedFrequentExpense} with the given frequent expense details.


     * @throws IllegalValueException if there were any data constraints violated in the adapted frequent expense.

These lines are repeated in lines 106-107.

Remove extra newline.

This class seems debatable. Note that TransactionBuilder was used to cover both Expense and Income. Should the same be done here? i.e. FrequentTransactionBuilder to cover FrequentExpense and the upcoming FrequentIncome.

Similar to the issue in FrequentExpenseBuilder, should a class TypicalFrequentTransactions cover for both FrequentExpense and FrequentIncome?


     * Returns an unmodifiable view of the frequent expense list.

Same with similar Javadocs in this class.

This method seems to be taken from getFilteredExpenseList and getFilteredIncomeList, which are found to be buggy. Please modify it to be an ordinary getter.


    /** Returns an unmodifiable view of the filtered frequent expense list. */


            "The transaction index provided is invalid.";

Is it possible to just have equals since these two methods are exactly the same?

Also, for the sake of consistency, use:


getTitle().equals(otherFrequentExpense.getTitle())

Similar for other places.

Unnecessary use of super.

This method is repeated in AddExpenseCommandParser and AddIncomeCommandParser. Perhaps in a future PR this method could be placed somewhere else, then imported into classes that require it?

Remove unnecessary newlines.

These Index objects are repeated from those above. I would suggest reusing those above rather than create multiple repeats of the exact same object. Perhaps maybe rename the three indexes above to something more general, like INDEX_FIRST and so on.

A more appropriate name should be used.


     * Converts this Jackson-friendly adapted frequent expense object into the model's {@code FrequentExpense} object.


        FrequentExpense validFrequentExpense = new FrequentTransactionBuilder().buildFrequentExpense();

Undescriptive variable name

There is a similar method in TypicalTransactions. Moreover, the FinanceTracker object returned by this method has no transactions while the other one in TypicalTransactions has no frequent expenses. Consider putting these two classes together so that getTypicalFinanceTracker will return a FinanceTracker object that has at least one item in each of its lists.

.iml files should not be committed. Also, there should not be an .iml file here in the first place, unless you did something you were not supposed to do.


        return internalFrequentIncomeList.iterator();


        FinanceTracker sampleFt = new FinanceTracker();


            @JsonProperty("categories") List<JsonAdaptedCategory> categories) {

For some reason checkstyle accepts indentation level 8, though according to the textbook in this case it should be indentation level 12.


            @JsonProperty("categories") List<JsonAdaptedCategory> categories) {


            @JsonProperty("incomes") List<JsonAdaptedIncome> incomes,

            @JsonProperty("frequentExpenses") List<JsonAdaptedFrequentExpense>

Follow this indentation for the lines below as well.


     * Returns an unmodifiable view of the list of {@code FrequentExpense} backed by the internal frequent expense list of


     * Returns an unmodifiable view of the list of {@code FrequentIncome} backed by the internal frequent income list of

Remove unused field.

Shouldn't this test mirror FrequentExpenseListTest? There are less tests here than in FrequentExpenseListTest.


    public <T extends Transaction> FrequentTransactionBuilder(FrequentTransaction<T> frequentTransactionToCopy) {

        title = frequentTransactionToCopy.getTitle();

        amount = frequentTransactionToCopy.getAmount();

        categories = new HashSet<>(frequentTransactionToCopy.getCategories());

    }

Missing Javadocs

Not all methods from FrequentExpenseList are mirrored here.


     * Edit filtered frequent expense list where index is larger than size of filtered frequent expense list,


     * Edit filtered frequent income list where index is larger than size of filtered frequent income list,

Use a more descriptive variable name.


        EditFrequentTransactionDescriptor editedFrequentTransactionDescriptor =

Not all tests in FrequentExpenseListTest are mirrored here.


        return new CommandResult(String.format(MESSAGE_SUCCESS, toAdd), Tab.EXPENSES);

Same for AddFrequentIncomeCommand as well.

This will remove the need to have an Index field to specify which Tab to switch to.


                .anyMatch(keyphrase -&gt; StringUtil.containsIgnoreCase(transaction.getTitle().toString(), keyphrase));

Remove duplicate code. Same for other places within this class.

Missing Javadocs


            Model expectedModel) {

This should be the more appropriate indentation level, according to the standard. Ignore the indentation IntelliJ gives you.


            Model expectedModel, boolean isCalculateBudgetInfo) {


            Model expectedModel, boolean isCalculateBudgetInfo, Tab tabToSwitchTo) {

Redundant field.

Glossary terms shall remain unformatted. Edits will be made.

Yes, it will remain unchanged.

Agree. This will be handled in a future PR.

Removing this comment fails checkstyle.

PR has been recorded by the grading script.

ModelManager::filteredTransactions was ideally supposed to contain both expenses and incomes from FinanceTracker::expenses and FinanceTracker::incomes, through the methods FinanceTracker::getExpenseList and FinanceTracker::getExpenseList while completely omitting FinanceTracker::transactions. Thus, ModelManager would have 3 lists while FinanceTracker would have 2.

However, the implementation of the class FilteredList is that one of its fields (source) is an ObservableList object, and constructing a FilteredList as such:


ObservableList<E> observableList = FXCollections.observableArrayList()

FilteredList<E> filteredList = new FilteredList(observableList);

would result in source = observableList.

In essence, a FilteredList object needs to keep track of an ObservableList object.

Thus, filteredTransactions needs to keep track of its own ObservableList object, and cannot track both expenses and incomes together. Therefore, FinanceTracker::transactions cannot be removed, and neither can the class TransactionList.

Possible solutions:

Add a switch statement that refreshes the tab after every command.
Modify CommandResult to indicate any changes.
Make use of listener, somehow.
Add additional getters for the lists or for the transactions based on index.

FinanceTracker::resetData does not account for frequent incomes. This stems from FrequentIncomeList class missing some methods. Reference FrequentExpenseList for these missing methods. From there, FinanceTracker and ModelManager should have similar methods as well.

Can consider renaming function to execute_invalidPersonName... instead of Index since we are editing by name now.

Just a side note, can consider "editPatient" as command word in case we want to have an "editTask" command in future. Up to you! 😃

Good use of Optional here!

Typo @code instead of @cod

I like how you included this test!

Your implementation of editpatient supports editing multiple fields in 1 command. Can consider adding an example of this. E.g. editpatient Alex Yeoh c/Add comment d/20200303-20200315

In the example, should be editpatient not edit haha >>

Perhaps you want to consider changing the message to "Search for patients who fulfill the given criteria in Covigent." since the output may be a list of patients.

Personally, I think including an example for search via temperature range may be better since this may be more difficult for users to understand how to use.

Actually you can remove the isPersonFound attribute totally. if (personName.equals(nameToSearch) can just return new CommandResult(String.format(MESSAGE_SEARCH_PERSON_SUCCESS, personFound)) directly. If the execution of code proceeds beyond this for loop, can just throw new CommandException outside. Just a suggestion to keep your code shorter 😃

Good test coverage!

Good to include an attribute string for message usage (similar to the other commands)

Will be good to include a MESSAGE_SUCCESS attribute or something similar for the string " rooms are added in a hotel" (can refer to the other command classes to see what I mean).

E.g. in addPatientCommand your have the attribute String MESSAGE_SUCCESS = "New person added: %1$s";

So what you return is return new CommandResult(String.format(MESSAGE_SUCCESS, numPersonToAdd)) instead of the hardcoded string.

Just to clarify, this exception is thrown if the user did not call the command addnumberofrooms right?

This attribute was what I was referring to for MESSAGE_USAGE earlier. Perhaps you may need to shift this attribute to AddNumberOfRoomsCommand class instead to keep it consistent with the formatting of other command classes.

Ok actually I am kind of confused of the flow and purpose of the addNumberOfRooms command. I thought for first time user we will get them to initialise the number of rooms and that will be fixed through out the usage of the app. So addNumberOfRooms in this case should be for initialisation? It doesn't make sense if halfway throughout the usage of the app I suddenly call addNumberOfRooms command again unless I built more rooms for my facility. 😕

Actually why do you need to add code for room under AddPatientCommand?

Just curious, why did you choose to use PriorityQueue instead of something simpler like ArrayList? 😛

Good test coverage for Room!

Remember to delete this!

This will be handled by allocate person command no worries.

Nice!

If we have to convert to priority queue, do you guys think if it's better to use array list directly instead of priority queue for room list?

Right, that's true!

Should be after search patient command but it's okay for now. We will do a massive UG clean up in future as a group 😃

Will be starting with an empty "room list" or something instead of AddressBook. Just to clean up traces of address book from the code haha.

I agree with this too. There may be errors if we forget to update this variable when needed.

Neat class that adheres to format of the existing codebase!

I was just wondering why you need to have a date time created attribute for task 😛

Neat I like this!

Good test coverage.

As in I meant the attribute "DateTimeCreated" haha, like why do you need to know when the task was created 😛 . The tracking of tasks due date is by attribute "DateTimeDue".

Sounds good!

Thanks for spotting this :X

Good! We will need to add test codes for patient addition for editRoom command too.

Very neat!

Do you think it is better to write "Lists all the rooms in the application." instead? I got confused with the word 'available' thinking it meant like empty rooms without patients.

Do you want to standardise the MESSAGE_SUCCESS with that of list patient command? Like "Listed all rooms."

To add on, can even add a "Please initialise the number of rooms using initRooms command".

Allocates*, edits* and existing*. Can change only when we do our massive UG clean up also.

Removes*. Comprehensive examples given here!

Do you think we should put this function under EditRoomCommand class or should it be the responsibility of RoomList class?

Nice check! Thank you for adding this 😃

I am not sure if it is a good idea to make this function static and expose it to the outer world, considering how you also need to call the getRoomList() function from the model to get the ObservableList>Room> as your parameter for this method so the roomList will be from your existing RoomList class anyway 😕. Just a thought to consider!

Very comprehensive test cases in this class. Well done!

Just curious why we need this toString() method. Is it for testing haha? But can keep it anyway.

Hmm I was thinking of having the function "isPatientAssignedARoom" in the Model interface instead. Since the Model contains roomList and the patientRecords, Model knowing whether isPatientAssignedARoom kind of makes sense (essentially it will call on another isPatientAssignedARoom method in the roomList class to get the result).

I think the key here is that the command should only know of Model and should not be accessing roomList directly. (like the Law of Demeter that we learn for this week) That's what I intend to improve for my deletePatientCommand because I also accessed the patient list directly from model, but I think it's not very well designed since there's a deletePatient command directly from model (original code from address book).

Yep no worries!

Typo: "tasks with"

Can consider "Searches all tasks before the given date."

Searches task(s)* -> I think the output may be more than 1 task right?

MESSAGE_SEARCH_TASK_SUCCESS

I think you will have to display the output in the "Tasks" tab instead. So you shouldn't be returning the result in the bot's response.

Good!

Can consider adding some success test cases and check if the output tasks are as intended.

Is it better to use the prefix_room_number from RoomCliSyntax instead since room number is an attribute of room?

Seems like success cases are covered in equals() method test.

Comparing patient to null is not very elegant, maybe check if roomObservableList.get(i).isOccupied() instead? (presumably isOccupied = true means patient != null)

Thanks for removing the duplicated messages!

Actually now I'm wondering if you do your assertion early on in the constructor, then the app will directly crash and will never reach here :X

Same issue, if you assert in constructor, will this Message Invalid room number be received by user?

If the task to delete is null, the app will just crash?

Will this crash the app?

Should we change the Message_Duplicate_Room to make it clearer? I believe this message is sent when the patient is already allocated to the room and the user calls the command to allocate the same patient to the room again. Maybe the message should be "The patient is already allocated to this room." instead of "This room already exists..." to make it clearer?

Do we still need this case since previously it was meant for change room number?

Same for this, do we still need this case since previously it was meant for change room number?

Should we use the PREFIX_PATIENT_NAME in PatientCliSyntax instead of RoomCliSyntax?

I personally don't really like this method because it's kind of weird to call this method in the command classes. But I'm not sure how else to go about it either 😕

I think this line should be added back cos it's meant for the next function removePatientFromRoom()

and this line should be removed.

Mmm just wondering what this function and occupiedRooms() function is for? Do we need to know the list of empty and occupied rooms? Unless it's to find the first unoccupied room which I think your priority queue will have been able to find?

Can remove this System.out.println()

I think you may need to change this json file back to the original one since this json file should follow the rooms set in getTypicalRoom() from the TypicalRooms class. The getTypicalRoom() function is being used by other test cases for task and patient commands which heavily depends on the order in the room list so I am not sure if changing this file will propagate errors to those test cases for tasks and patients. 😕

I think it's fine to have so few rooms in the test cases since we are just testing that the functions work as expected rather than testing if the app works on a large scale. What do you think?

Remove the System.out.println?

Good use of logger here.

I think the command is "initroom" and not "addRooms" anymore?

Do we still need this for listroom since our implementation for listroom and listpatient ignores the excess words?

I was thinking if we should reduce the maximum number of rooms further since our target audience is small boutique hotels?

Not sure if you still need these 2 lines of code since you commented out, but if you don't need it anymore, don't forget to delete it!

Good!

Sounds good. I've changed the names to AddPatient instead of AddPerson for better clarity. However, if we are going to implement Staff, maybe can extend from Human instead of Person because there will be too many changes required to replace Person to Patient.

There's a possibility that comment may be a null object (since it's an optional field) and .trim() method exists for String class so it wouldn't work if comment is a null object 😛

That's a very good suggestion, will use this function in future! 👍

I followed their existing format. 😛 Since checkstyle doesn't give error, I assume it's fine?

Yes!

Yep I will change to add patient instead!

Thanks for pointing out!

I think the temp should write but the age probably no need haha.

Yes, good suggestion. We definitely should adhere to this in the next UG update!

Yep, should take note of the standardisation in UG.

I agree with Ming De I think we should stick to making sure patient does not have the same name. If we delete by index, in the case of 1000 entries, the user may have to scroll too much to find the patient (using searchpatient command doesn't show the index also 😕).

If we just ensure patient cannot have the same name, then all we need to change is the isSamePatient(...) function (to guard against duplicate patient being entered). If we need to check for the age and phone number identifiers, then we may need massive changes for deletepatient and editpatient command 😕.

Well, we can justify that the odds of patients having the same name is really very slim haha (https://www.quora.com/What-is-the-probability-of-two-people-having-the-same-name-and-also-living-in-the-same-city)

Yep yep the search room command is incomplete as I've mentioned haha. The main thing in this PR is just refactoring.

I think we will have to shift checkIfRoomPresent() to Model class also. But I will fix that in my next PR for SearchRoomCommand. The key for this PR is just refactoring.

I will change all the empty line thing. Thanks for pointing out!

Sure, I will change to "All patients are listed."

I realised search room for now is just search by room number. So it only returns 1 room haha.

Oh the whole populatePanel function is deleted haha so the logger is gone.

Roger that sir.

I realised I should be making the pull request from my fork instead of editing directly in this repo for UG.

Incorporated with editRoom command.

Not sure why Java CI failed even though it passed on my end.

Can be closed.

Duplicated issue.

Bro that was spot on. Error was in the handleMouseClick

This issue will have been fixed since we added the step-by-step usage with step 1 being "navigate to the ____ tab".

We didn't mention that phone number must be 8 digits since we allow for international numbers too. Not an issue.

Updated the UG with 0 (inclusive) to 120 (exclusive). Not an issue now.

@raymondge I will fix this for my temperature side first then you check if it affects your temperature range. (by right, if I fix temperature already, you shouldn't need to do anything).

I think he was referring to the line "If the number of rooms is less than the number of patients error is thrown when decreasing the number of existing rooms." ?

For this, I think we need to state explicitly in the UG that if multiple same parameter inputs are included, we only take the first.

I will fix the temperature class first.

Since our target audience is small hotel owners, number of rooms shouldn't be that many. We should state clearly in UG that target audience is small boutique hotel owners.

Can only link up to max. 10 issues. Once this PR is closed, to close this following issues too : #208 #188 #193 #201 #158

Already mentioned in UG that duplicate names are not allowed.

Updated UG under Command Format section

@LeeMingDe I've already made the relevant changes. Let me know if you think the temperature message needs to be changed some more. If you think it's fine, can just close the issue.

Not a bug in my opinion. Still fulfils the functionality of listpatient and the presence/absence of those additional words will not affect the functionality.

Section has been updated in UG.

RoomPanel fixed

Will make this PR to master branch instead.

Maybe the patients should be caps (for standardisation)

I think there is a double spacing between Nuudle and shows

Would delete an appointment be clearer?

Would mark an appointment be clearer?

I think appointments here should be singular?

Maybe it will be better to use the specified appointment?

Seeing that appointment is dependent on the patient, should it be clear all appointment entries instead? What do you think?

I think this should be person or nurse instead

Should AssignLoaderBuilder be DateTimeLoaderBuilder instead?

Because there is no AssignLoader object.

Should there be a closing square bracket?

The boolean isAll seems to be unused.

Maybe instead of using a boolean can consider using PREDICATE_SHOW_ALL_APPOINTMENTS in Model.java then there is no change in the implementation

Lemme know what you think about this! 😄

I think that he handled this under NuudleParser but I think it would be better to do the argument checking in this file instead?

Maybe can try doing the isEmpty check before tokenize?

Maybe can rephrase this to Mark the specified appointment as done or Mark the appointment specified by the date and time as done (more specific version).

Lemme know what you think! 😄

I am not really sure if we should create an appointment without a patient for checking purpose. I made a PR to remove the optional field of Patient so an appointment cannot be made without a Patient (see #90)

Maybe for the filter in line 60, can change it to check if an appointment has the same date and time? (hasDate and hasTime) Do you think this works?

It seems wrong to use a nested class in AssignCommand for non-assign related command.

Should we abstract out the DateTimeLoader into a class on its own? Maybe this can be addressed in future PRs.

editedPatient should be editedAppointment instead.

For this can just add throw new AssertionError("This method should not be called."); similar to above

The check should probably be !target.startAtSameTime(editedAppointment) && hasOverlaps(editedAppointment) instead. (If the edited version is different from the target, make sure that there is no overlap with the rest of the appointment.)

I think that the else { part can also be removed so that the happy path is made more prominent. 😄

This should still be AddressBook?

Should it be Exiting Nuudle instead

Should it be Nuudle instead?

I think Updates all appointments with the given {@code Patient target} with the given {@code editedPatient} would be better as it implies that multiple appointments will be updated.

I think this is correct.

I believe that the check is if target and editedAppointment does not overlap, check to ensure that the editedAppointment does not overlap with any other appointments.

If the target and editedAppointment do overlap, you are sure that there will be no problem adding the editedAppointment as it can safely replace the target.

Actually for simplicity, we can also consider this: call remove on target, then call add on editedAppointment. If it throws OverlappingAppointmentException, then we add back target

Yes. It will still throw an exception.

Good effort on updating the user guide! Thanks for correcting the cancel and view documentation too! 👍

Just a comment: Should we include a constraint on the date and time not being in the past for cancel and done? It's not implemented currently, but I guess we can add it in the next milestone.

I think that the DATE and TIME should be DATE and TIME instead? Same for the documentation for cancel.

I agree with Wanlin actually, I think that it should be ParseException instead. Although IllegalValueException is the parent class, we expect parseIndex to only throw ParseException and if it throws anything else we know that this is unexpected behaviour that we should fix.

I think this can be removed as it's not used in the program?

I think remark should be added here too for the requireAllNonNull

For now, the only possible constraint I can think of is the word length, otherwise, a user can add a whole paragraph to a remark. What do you think?

Ohh I was comparing it with the other command parsers and they were using ParseException. So shd be ok to change it to ParseException

Yep this looks much better! 👍 But is it abit long? Maybe can shorten the last part to refer to help instead?

Should be a {@code Remark} here

Hahaa nice effort! 👍

Do you think it is better if we include the index directly in the tests instead of here?

Because currently it seems a bit inconsistent with the rest.

Not really a big issue tho. Let me know what you think

I think the link should be updated to our group repo

I don't think there is a VersionedPatientBook here

The appointment should not be created when called with lastShownAppointmentList.filter.

toMark.markAsDone should call the markAsDone method in toMark:Appointment which in turns call the constructor of doneAppointment

The link here should also be updated?

The phrasing seems a bit off.

Would it be better if we phrase it as The 'DURATION' is measured in minutes and will be defaulted to 60 minutes if omitted?

Do add on if the phrasing can be improved further. 👍

I think the second line can be omitted. (Addressed in the 5th point)

Should it be parses instead?

This shd be adds instead

Sorry just a bit curious about this function, this is currently not used right?

Yes I agree with Wanlin, isPresent() would be better. The user can change to a specific date, time or duration without changing the rest.

I think that !(appointmentToEdit.startAtSameTime(editedAppointment) && model.hasAppointment(editedAppointment)) would be a better form of checking.

This checks if the 2 appointments are "equal" first before checking if the edited appointment has any complete overlaps with the other existing appointments

Remember to edit this part 👍

The logic for setting appointments can be handled in UniqueAppointmentList and this part can be edited to catching OverlappingAppointmentException and throwing the relevant CommandException.

Might be good to add JavaDocs for the class

Similar to above, might be good to add JavaDocs to the class

Might be a bit repetitive since VersionPatientBook also has the same exceptions.

Hmm because this is edited using drawio, the class UML diagram is not consistent with the other diagrams. (The colouring and the font) Maybe it might be better to use plantUML to ensure consistency?

Currently, there is a gap number between 3 and 4. Maybe it's better to shift this to 5. (before XZ's implementation)

Good activity diagram!

Would Activity diagram be better than Architecture diagram ?

Not sure if there will be implementation of AddCommand and EditCommand tho, cos its not really implemented by us. 😆

Would Sequence diagram of remark command be better?

We can use the UML diagram similar to the current diagrams in our DG architecture.

You can refer to LogicClassDiagram.puml and ModelClassDiagram.puml for the labels and the multiplicity.

Because your current diagram looks very similar to what we have in our DG, just that the font size and colors are not standardised. Let me know what you think! 😄

Should this be updated to Finds patients by name, NRIC or phone numbers?

Would this sound better?

The search requirements cannot be left empty, at least one search requirement (by name, Nric, or phone number) has to be provided

Thanks for updating the UG!

Would it sound better if and displays them as a list with index numbers is removed?

What do you think?

I'm not sure about this but wouldn't the assertion fail if certain prefix is not used?

E.g. if name prefix is unused, wouldn't there be no namePredicate?

Would it be better if its abit more straightforward? Alternatively, you can also use the edit command to add or edit remarks if you wish to change multiple ?

It feels abit long-winded to me. I think can remove the left side part?
Lemme know what you think about it? 😄

Would it be better if we refer to the original appointment as the first appointment in the appt list?

Just some Java trivia.

You can also take a look at the isBlank() method for String. It returns true if the string is empty or only contain trailing whitespaces. 😄

Would it be better to give a more direct message rather than a generic one? (Since this msg is only used once)

Maybe we can use: "Cannot view appointments from the past. Past appointments are archived and can be accessed from the archive folder" ?

Let me know what you think! 😄

Maybe it would be better if the check is done in ParserUtil.parseDuration instead? This way the check will apply to ChangeCommandParser too. (Can just compare the duration with CLOSING_TIME - OPENING_TIME)

Lemme know what you think about it?

Hmm, true. Then I guess this will work 👍

Would the following phrasing be better?

undo command cannot reverse a command execution from the previous Nuudle session.

Same as above. This can be rephrased to:

redo command cannot reverse an undo execution from the previous Nuudle session.

This comment is for line 346.

For the line:

Multiple calls to redo will reverse multiple undoable command execution, starting from the most recent command.

(should be undo instead of redo)

Should the JavaDocs be updated too?

Should also update line 173: 1. User types done d/DATE t/TIME into the app.

Should also remove line 169 (about DateTimeLoader)

Ps: Writing here bcos I cant comment on other lines.

Hmmm, I don't think this should be edited. An invalid command format message shd be shown if the index is missing.

I took a look at the current code in ChangeCommandParser and I think that the message for line 42 (throw ParseException) should be MESSAGE_INVALID_COMMAND_FORMAT instead of MESSAGE_INVALID_APPOINTMENT_DISPLAYED_INDEX.

Do you think it would be good to add a comment on top to explain the numbers? or it's quite self-explanatory

Oh yeah. I missed that out. Thanks 👍

Oh I forgot to change it to INDEX. Thanks for spotting it 👍

Hmmm, do you think if something like that will be good? See

Oh I missed that out! I'll update it to "hour". Thanks 👍

Ohh yeah. I have updated this on my side. Thanks for spotting it 👍

Agreed 👍

I think this is auto-correct on my part! It should have a tab right?

I have edited this on my side. 👍

Edited! Thanks for spotting it! 👍

1. is actually a markdown format for numbering bullet point. They will automatically assign the number to it, this way don't have to manually update the numbering everytime a point is added or removed.

Can take a look at this for the markdown preview: Dev Guide

Ok I will add it in and update the helpMessage image

Ok added

Thanks for spotting it!

For this, I follow the documentation style of the writeToFile method above. So I think Writes will be better?

Good catch! 😄

Yep, I missed that out! Good catch 👍

Good catch 👍

Agreed! 👍

Good catch 👍

Added! 👍

Thanks! 😄

Thanks for the review!

Yep, I agree. Already updated it on my end.

Patient details refers to basic information such as phone number, email, address, etc

Same as #18

Will implement together with #31

Addressed in #95

Is this similar to #7?

Implemented as tag during the creation of patient with add

Will be solved by #21

Chaining of multiple commands. Unlikely to do for current iteration

Nuudle app is developed with typing preference in mind

Similar to #12

See commit and workflow for sample workflow run

Shouldn't the text name for this be matriculationNumber?

Maybe INVALID_MATRIC_NO could be changed to INVALID_MATRIC_NUM instead?

Shouldn't there be a method call withMatriculationNumber(...) as well?

Perhaps MATRIC_NO_* could be changed to MATRIC_NUM_*?

Should there be an awkward line break right after MATRIC_NO_BOB? Same issue with the other test cases.

Shouldn't there be a method call withMatriculationNumber(...)?

Shouldn't the message be ATAS has deleted all students! or something like that?

Perhaps these could be renamed to ACCEPT_COMMAND_FULL, ACCEPT_COMMAND_SHORT, REJECT_COMMAND_FULL and REJECT_COMMAND_SHORT?

Perhaps comments could be added to explain what you're testing for each statement (+ expected result)?

I noticed a similar issue previously. Maybe more comments explaining each test case could be added?

Do you think it would make more sense to include the use of the abstracted wrapper class Index here?

Would this make more sense to put in an if-else block (with comments to describe the else block)?

Should this unncessary extra line break be removed?

Maybe these could be renamed to PREFIX_SESSION_NAME and PREFIX_SESSION_DATE?

Shouldn't the form be dd/MM/yyyy?

Maybe some comments could be added here to more clearly explain the thought process?

Unnecessary additional line break?

Maybe these two if blocks could be merged into one?

Would it make more sense if all instances of SESSIONNAME got changed to SESSION_NAME? (same for SESSIONDATE and SESSION_DATE?

Unnecssary whitespaces?

Unnecessary whitespaces?

Unnecessary extra line break?

Unnecessary line break?

Unnecessary whitespaces?

Shouldn't this be renamed to Editing a student to fit the rest of the item naming?

Maybe this class could be made public?

Shouldn't the command participate be in all small letters?

Shouldn't this be enterses?

Shouldn't this be presence?

Shouldn't the command here be editses?

Maybe you could add a TODO for next time?

Should this be something like saveStudentList?

Maybe change this to JsonSerializableStudentList and correspondingly ReadOnlyStudentList?

addressBook -> studentList?

AddressBook -> StudentList?

addressBook -> studentList?

Maybe this could be changed to Clearing the student list?

Maybe this could be changed to Delete Student, seeing as we are deleting one student at a time?

Perhaps the last comma could be changed to a full stop?

Maybe this comment could be deleted?

Maybe this comment can be updated since we're no longer using a hash map?

Maybe this comment could be deleted?

Maybe this line could be removed?

Perhaps some Javadocs could be added here?

Perhaps the starting word for each Javadoc comment could be "Recalculates"?

Perhaps the comment could start with "Updates"?

Maybe this comment can start with "Recalculates"?

Maybe each comment could start with "Replaces" instead?

Return -> Returns?

Obtain -> Obtains?

Replace -> Replaces?

Perhaps there could be a space between "below" and the opening paranthesis after it (last few words)?

Maybe Memo could be de-capitalized? Same issue in line 728.

Perhaps Features#Students could be renamed to features#students? Same comment for line 322.

Perhaps this could be renamed to features#current_session?

Perhaps this could be renamed to command_summary#students?

Maybe the opening "(" at the end of this line could have a space between the word "student" preceding it?

Perhaps a comment could be added to provide a brief description as to what tracker is for? The name isn't as clear atm.

Perhaps a comment could be added here to describe what happens?

Perhaps you could rename this package?

Maybe this could be renamed to student list to more accurately reflect the naming convention used?

Perhaps another extension could be added to highlight what happens if the user tries to enter the same session he is already in?

Maybe "Should" should be de-capitalized here?

Maybe pictures could be provided for at least one positive test case and one negative test case each?

Perhaps these parts could be wrapped in their respective div boxes for better organisation of info?

Perhaps these parts could be wrapped in their respective div boxes for better organisation of info? Noticed the same issue in other areas as well.

Thanks for pointing this out, as well as in other places!

This implementation is under the ModelStub and this method is not used at all, so I thought returning null wouldn't make much of a difference either way.

Do you have any alternative suggestions for this part?

Same as above:

This implementation is under the ModelStub and this method is not used at all, so I thought returning null wouldn't make much of a difference either way.

Do you have any alternative suggestions for this part?

Did I not add it in? Lines 22-24.

Ok thanks, will do!

Thanks for the suggestion, will be refactoring some methods to make this possible!

Not an issue because Alt+F4 is a thing

Not sure about this. Will look into it and discuss with teammates

Will look into this

This is intended. There are two types of commands: those that commit (save data in the app) and those that don't. Even if you perform a command that does not commit after a command that does, you will still be able to undo the command that committed.

Will look into this

This is intended

Will look into this

Intended

Will look into this

This is intended

Will look into this

Irrelevant as Alt+F4 is a thing

Will look into it

???

Will look into it

Further thoughts:

I think a better design would be to treat memo as a separate entity from sessions and students.

undo should only work for commands related to sessions and students; memo already has built-in undo features in Ctrl+Z.

I will make this distinction clearer in the UG.

Further thoughts:

Could not find situations wherein just numbers are not allowed.

https://stackoverflow.com/questions/2049502/what-characters-are-allowed-in-an-email-address#:~:text=The local-part of the,digits 0 to 9 %3B&text=dot . %2C provided that it is,unless quoted (e.g.%20John..

Will be disregarding this issue

Perhaps it'd be better if you could maybe list out the specific bug fixes for easier referral in the future though?

Should the naming of the images be x.x.x.x-desc instead of xxxx-desc?

@YuunoKun I've made the relevant changes to the naming!

Maybe you can use an empty line instead of using >br>

There is an extra >br> at the end, which will increase the gap between this line and the Acknowledgement. Is it intended?

Should there be an extra white line here?

Maybe there shouldn't be a > here?

I think you broke some of my parts. You can review this markdown file again to find out more.

Before

After

I have night mode enabled so it is more obvious.

There's still something wrong here.

Did you change the package name to fileAddress?

Shouldn't it still be tag?

Maybe can replace person with tag in the message as well.

Should the person package be renamed to tag?

This may not work later because of the FileAddress field. Maybe add a //Todo here for reminder.

JsonAdaptedTag was used to store tags for person. For now shouldn't it be deprecated since we do not have that functionality?

Is it really person details?

Is this println for debugging?

Should this be "Tags list contains duplicate tag(s)."?

Is this for debugging?

This may not work. But for now it's okay.

For now it's okay. This will be looked at again by the Logic team.

Are these tests no longer working?

Extra spaces here.

Are these 3 variables no longer independent Ui parts?

// Independent Ui parts residing in this Ui container

Maybe the name of the variables here could be changed?

Maybe "valid" file path?

Could this be changed to a more sensible tag name?

Should there be empty lines here?

"Person" should be predicate here?

Method name should be test_keywordMissing_returnsFalse?

This validation regex is for names. Should this be dropped?

Should this class be named ObservableFileList?

The file can be changed to HelloFile.jar?

Displays

managed tag names -> managed tags?

"Renames a tag's name"?

Typo in design?

Absolute path is already ensured in TagCommand, but its still okay to get absolute path again here I think.

I get it now.

This part should not be changed. This are the default tags when HelloFile is launched the first time. We might want to keep this list empty?

Should there be an empty line here?

This edit is not correct? TagCommand do check if the file is present using java.io.File.exists().

What?

Is this a wrong JavaDoc?

newTagName

Is label command left out?

Nice after that can merge alr

Should you do nothing here? Maybe indicate the error by changing the text in ResultDisplay?

Again as before

Okay I understand now. Everything looks good then👍

Wrong comment here?

Happy path is not prominent here. Maybe you should change this to


if (!labels.isEmpty()) {

...

}



return new CommandResult(String.format(MESSAGE_SUCCESS, editedTag));

Add another UnlabelCommand with same label but different TagName for 100% coverage.

Test for this case:

this.tagName.equals(((UnlabelCommand) other).tagName))

Test for non-empty preamble (parse with a string starting with "unlabel") for 100% coverage?

Test with new UnlabelCommandParser.parser("unlabel ...").

Testing this condition: !argMultimap.getPreamble().isEmpty()

I'm not sure if you can change this only. You can refer to the rest of the file. I'm not sure why storage test can pass if you only changed this label but not the rest.


    "tagName" : "myfile 3",

    "fileAddress" : "c:\\a\\b\\myfile3.txt",

    "labels": ["testLabel"]

  }, {

    "tagName" : "myfile 4",

    "fileAddress" : "c:\\a\\b\\myfile4.txt",

    "labels": ["testLabel"]

  }, {

    "tagName" : "myfile 5",

    "fileAddress" : "c:\\a\\b\\myfile5.txt",

    "labels": ["testLabel"]

Actually it will pass. But do you have a reason for changing this?

If you do not use withLabels, it will still have a label called "testLabel"

Perhaps don't change this since it won't be consistent with TypicalTags?

Alrighty👍

I think Find Command does not distinguish between tag and label. So this will find any tag with tag name or label that contain "tagname1" or "label1"?

Redo can actually be undone.

I don't know if show and exit screenshots are necessary. Perhaps remove them?

Also maybe extra spacing will be nice.

Grammatical error here: Command history will be deleted once the app is closed!

Same as above.

Should be "is closed"?

Same as above.

This screenshot is a bit sensitive?

Missing :. Should be **:warning?

Same as the previous one.

Will this be really valid for CdCommand?

This does not create a new addressbook, so the same addressbook is used through out all testcases. Is this intended?

Should the method name be removeTag_tagInAddressBook_success? Since the result of the method being tested is not actually returning false.

Should the method name be removeTag_nullTag_throwsNullPointerException?

Should the method name be setTag_tagInAddressBook_success?

setLabel_labelInTag_success?

As in the addressbook will be reused so all the tags that you have added previously will persist across all testcases.

Maybe can set up an empty addressbook by using @beforeEach.

Shouldn't this still be showing help for tag?

Roger that

We need to change all the entities in testUtil.

It's not a typo, it's a real word =)

conform

/kənˈfɔːm/

verb

comply with rules, standards, or laws.

I find that without "\n" the format is very hard to read, so I added them.

That's going to be more readable in my opinion.

Right now the tag command is like this. You cannot distinguish tag name and file address easily.

Ok will change that

I don't think we will be doing manual testing anymore. Moreover, this appendix is for us to read and probably not suitable to be included in DG.

I think writing equals() this way is very clear and easy to understand, like a pipeline.

It's thrown afterwards, so that all tags that can be opened are opened.

Done!

test

Resolve #36

Hi Heinrich, could you make a stub so that we can use it to work on Logic? Thanks.

Yes! I think that will be good.

Looks good. Is it possible to have a toggle for this theme?

You mean something to switch to different themes?

Yup

Cd can change current address.

Format:

cd f/absolute address

cd p/

cd c/child_folder_name

Getter and setters

FindCommand can have t/, d/ or (t/ and d/).

Alternative

cd f/absolute address

cd ../

cd ./

Can't really check the UML..but LGTM!

You can use "view file" at the top right corner to see the markdown file.

Command format:

label t/tag l/label [l/label]

Append labels (accept multiple)

Only redo commands Clear, Tag, Untag, Retag, Label, Unlabel.

Only undo commands Clear, Tag, Untag, Retag, Label, Unlabel.

like AB4

Open command only takes 1 label or 1 tag but not both.

Maybe this is a feature?

Introduction

Basic workflow

Command Format -

Command Summary

Glossary

Accepted as normal

Add a note for Linux/MacOS users at the front of UG. "/Users/user/Desktop".

Add some examples for MacOS/Linux

Add a scenario and a screenshot.

Change UG to dark theme. Change light theme (default) to light theme.

Add a warning in UG to say only the last prefixed parameter is accepted.

As far as possible, use setTag instead of delete + add

What if we do not undo for 10 years. Will take 10GB.

Add in UG. Redo and Undo do not work after app has been restarted.

Update CdCommand

cd ..

cd ./

cd f/

good suggestion

Use setTag

setTag

Change argument prefix from / to >.

Update UG too.

Looks good to merge!

LGTM! Have you tested the minimum window size? How does it look?

I tested a bit, at the minimum size, the window doesn't look good, but I think maybe shouldn't make the minimum size too big.

Good to go then👍

Looks good. The words in galaxy theme is a bit hard to read though.

Another thing, could you update the UG as well?

Sure, I try to add theme switching to UG

Ooo, just found it's already added, then I will update the images.

The changing theme section is not updated to reflect your changes. Could you also update the screenshot if possible?

Changing themes

HelloFile comes in light and dark themes. ...

How do I modify the color to make it consistent?

Doesn't matter for now. We probably need to change those screenshots later because the words are too small...😢


Edits an existing tag in StonksBook to the specified tag name. All entries previously associated with this tag will be updated to associated with the updated tag.

I think we can remove the here


* All contacts that have been previously associated with this tag will be updated automatically to be associated with the updated tag.

Should we mention friends here? I think it may be better if you just mention that it updates the name of the first tag (as per tag list)

Same comment for here (about whether to mention friends)

Maybe we should consider switching to an ordered list if we're going to make reference to other points

Think you're missing a Use case ends. here and in some other portions below as well

Can this be indented to be the same level as 2a? Likewise for the remaining use cases


2. StonksBook adds the provided tag.


| `* * *`  | efficient salesman                | list all sales of a contact                                   | see all sales made to a contact easily                                                        |

I think here we're assuming that contacts are sorted before sales right? Should we add a comment stating this assumption?

Can we write this section into an if-else block with the above? Then we can also remove some duplicate code

Hmm, is associations a bit hard to understand here? Would it be better to be more verbose here and say something like Note that all items that have been previously associated with this tag will be updated automatically to be associated with the updated tag. as per the user guide?

P.S. May also need to update the user guide: it currently says contacts when it's supposed to be generic right?

Same feedback here as in DeleteCommand

Is this comment still relevant? If I'm not wrong it refers to the tags stored in the persons/sales right?

Javadocs here is inaccurate

Would it be better to initialise a new HashSet with the original tags, remove the target, then add the editedTag in order to prevent arrowhead-style code? Same can be done for the removeContactTag

This should be equivalent tag instead of person right?

Should be tags here instead of persons

Is this javadoc accurate?

p.s. i think these 2 lines are common across the conditionals. maybe we can extract it out of the conditional? same for EditCommand

Is this part relevant?

Is this description accurate? I think the javadocs you have in AddressBook.java would be better here!

Based on the name of the method, I am inclined to think that this method returns a list of contacts. Maybe you want to rename it so it's clearer? Idk. But I think updating the javadocs would be good!

Same for findBySaleTag

Should this be be model.findBySaleTag?


     * Lists all sale items associated with {@code target} tag.

ps still got the parameter here that needs to be updated as well

Does using ++count instead work? Same for below

Maybe can replace this with just AddCommand instead of the fully qualified name?

Maybe can use AddCommand here instead?

Just checking, but what's the desired behaviour if a user supplies both c/ and s/?

P.S. I think I extracted this out into a method in ParserUtil. Maybe can import it from there instead of duplicating?


     * Returns true if all the tags of the provided {@code sale} item exist in StonksBook.


     * Returns true if all the tags of the provided {@code sale} item exist in StonksBook.

Is this part necessary? The part where you throw an exception, then catch it, and throw it again

I think this javadocs here is inaccurate?

Maybe can add a note here that the default reminder list is based on reminder find st/pending?

Maybe can replace 'find' with 'filter' in this section

st/STATUS is optional right? So should it be reminder list [st/STATUS] instead?

Think this part is missing the prefix

P.S. for this section, is it possible to change such that you create a sorted list from the filtered list? So that it's more consistent with how the other models behave since the other models also filter first, then sort.

Then this can remain as getSortedReminderList


* Deletes the contact tag or sales tag at the specified `INDEX`. The `INDEX` refers to the index number shown in the list displayed by the `tag list` command.


* `tag find st/3 cl/` displays all contacts who have purchased items associated with the third sales tag.

I think this can be deleted?

Would prefer if you use the PREFIX constants here and in line 32 as well

I think this part should be PREFIX_CONTACT_TAG + INDEX or PREFIX_SALE_TAG + INDEX?


3. The **Result Box** will display a message noting that the command was successful, as well as a list of contacts who are tagged with friends.

I think can remove my name here haha since you wrote most of this section


5. Type `sale delete s/3` in the command box, and press <kbd>Enter</kbd> to execute it.


2. Suppose the sale to be edited is at the third index in the sale list. Then, type `sale edit s/3 q/20` in the command box, and press <kbd>Enter</kbd> to execute it.


3. You should see that the sale has been updated to reflect this new quantity.

Does this backslash affect anything?


5. Type `sale delete s/3` in the **Command Box**, and press <kbd>Enter</kbd> to execute it.


2. Suppose the sale to be edited is at the third index in the sale list. Then, type `sale edit s/3 q/20` in the **Command Box**, and press <kbd>Enter</kbd> to execute it.


StonksBook will not remove a contact from the archive if it is not in the archive!

I think this sets the icon to be permanently white even in the dark theme. By right the icon should be green when the reminder is complete, and red when the reminder is overdue.

In the light theme, the text doesn't reflect the colours as well.

Past meetings should be "greyed out" but this doesn't seem to be the case in the light theme

Can we capitalize the first sentence of each step and use <kbd>Enter</kbd> to denote keystrokes? Also, for all UI components that we make reference to, can we capitalize and bold them?


1. Type `contact find alx yo` in the **Command Box** and press <kbd>Enter</kbd>.

I took a look at your images, and I'm not sure why your aspect ratio is different from mine. Mine is a rectangle which is longer horizontally than it is vertically. Maybe we can check with the rest how their apps look, and standardise it? Otherwise our screenshots will look very inconsistent. After which, we can decide on a width that we should all follow for images. 400px looks too small for mine. So right now, most of my images are set to 900px


1. Type `help` in the **Command Box** and press <kbd>Enter</kbd>.


1. Type `meeting stats 6` and press <kbd>Enter</kbd>.


1. Type `sale list m/8 y/2020` in the **Command Box** and press <kbd>Enter</kbd>.


1. Type `contact sort s/ desc` in the **Command Box** and press <kbd>Enter</kbd>.


2. The contact list now contains contacts whose name is similar to alx yo.

Just checking, should UniqueMeetingList#removeMeetingsWithContact be updated as well? Likewise for UniqueSaleList and UniqueReminderList


* An additional `cl/` (stands for 'client') field can be provided when performing searching on sales tags. If provided, instead of displaying sales associated to this tag, StonksBook will display the clients who have purchased items with this tag.

Should this be updated in the command summary table in the UG as well?

Based on your screenshots, this should be lowercase right?


    private Path addressBookFilePath = Paths.get("data" , "stonksbook.json");

I see. Thanks for clarifying! I'll leave Jin Ming to do the approving!


:bulb: Tip: You can learn more about the `contact find` command in [locating contacts by name](#locating-contacts-by-name-contact-find-aaron-seah).

Nice! Can help perform this change for reminder edit as well?

Thanks for pointing that out!

Oh, my bad. I didn't know the new line would affect the formatting. Thought it was just code styling. Will remove it!

Not yet! Just adding this in here so that I won't forget. Sorry for the confusion

This just prevents the loop from flagging meetingToCheckAgainst as conflicting (if it does) if it's in the excluded list. But anyways, I've updated this method to return a list of conflicting meetings so that I can display it in the command feedback!

Thanks for pointing that out!

Yep, I think so. I plan to do them over the weekend, don't think I can finish it by tonight lol

@Asthenosphere ps can help resolve the merge conflicts?

LGTM

Thanks!

Think we're all done with this. Nice work all!

LGTM! Could you merge the updated master and push again though? Renaming CONTACT_INDEX to CONTACT_INDEX_SECOND might affect some of the test cases that have been merged.

Sure!

Not really relevant to this PR, but I think the parameter and example for editing a tag is missing the updated tag name. Example should be something like tag edit 1 t/furniture. Feel free to merge this PR if you want to resolve this in another PR.

Tested locally, LGTM! Good idea to abstract ModelStub out to another class.

Can I just check: whether a reminder is overdue or not is evaluated at program startup, are there any plans to either have the reminder display update immediately when the reminder time has passed, or to have a command to manually refresh the reminder display (like perhaps on reminder list?

Good point! I've added a force-refresh at the end of every command. Idk if this would be too inefficient though...

See #127

Done in #114

Yep, sure!

Also, I was initially thinking that the filtering should be implemented as part of the reminder list command. Similar to sale list.

LGTM besides the minor things pointed out!

Just an idea, I think it would be helpful to print the conflicting meeting to the user when the error is thrown!

Makes sense. Thanks for the suggestion, I've included the above!

When testing, something interesting happened: I created an upcoming meeting and used meeting list to display all meetings. After the meeting was over, I retyped meeting list, and the meeting was greyed out, but still present. I think there's a need to refresh the contents of the list in this case?

Other than this issue, the code looks good! Great decision to use ListMeetingDescriptor

Great catch, fixed! Thank you!

That's weird.

Just to confirm, the steps to reproduce are as follows: (assuming current time is 26 Oct 2020, 18:32)

Open up app
Execute meeting add c/1 m/fnakldsnlk d/2020-10-26 18:32 du/1
Execute meeting list
Wait for 18:34
Execute meeting list
- Newly created meeting should disappear, but appears in the list (although greyed out)?

I'll review this in more depth after the other PR has been merged, but looking from the screenshots, would it be better if you merged the contact and sales tag list into one, and have some other form of differentiation between the two? I just feel that the way the sale tags' numbering doesn't start from 1 is quite jarring especially when it's presented as being a separate list. Not sure what you think about this but I think we can leave it as it is now first.

Also, regarding your other PR, I've submitted a PR to your branch on your repo. Not sure if you've had the chance to take a look at it yet?

UI Terminology:

Result Box
Command Box
Contact List
Sale List
Sales Tag
Contact Tags
Meeting List
Reminder List

Any reference to the above should be in bold and capitalized accordingly. Feel free to call them something else, just need to make sure it's consistent throughout

Cover Page

Must have the word "User Guide"

Should be before the introduction
Must be numbered (OK to have bullets)
Ensure proper casing (for simplicity, I suggest that we all stick to sentence case - capitalise ONLY first word, with the exception of proper nouns)
Check that links are working
Parallel structure for each feature
- I suggest the following format:
  - ___ing ____: command word
  - E.g. Adding a contact: contact add
  - Note that extra parameters to the command are omitted

Introduction (DONE)

Overview of Product - first statement tells you what the app is, next statement tells you target audience, followed by main features + how it is designed using CLI with GUI (explain these technical jargon - CLI and GUI. Should also be written out in full the first time you mention in instead of abbreviating them)
- See: OASIS example
Purpose of Document
Section explaining how to read the guide
- Explain any special notations, markups, symbols, navigation

Individual Features

Note: Anything not marked with a name will be considered a team effort. So do indicate your names to the respective sections that you've written.
Ordering of features within each section: let's standardise it to: List, Add, Delete, Edit, followed by other miscellaneous commands that are related to that particular model.
Steps must be numbered and start with a verb. For results, should be “The result box will …”
For each step, explain what needs to be done first, then display an image. Ensure that the image matches what you say needs to be typed. Image after the step.
To explain features which require some form of INDEX, first tell the user to type the list command and explain why this is necessary. Then, "Let's assume that ... has index ..."

Let's standardise the format for writing each feature:


### Reminders 



<include preface statement>



#### Adding reminders: `reminder add` \[Sebastian Toh Shi Jian\]



<include preface statement that follows the below form - "Adds ..." >

Adds a reminder scheduled on a particular date that is associated with the specified contact to StonksBook.



<any notes if applicable - should be wrapped in a div tag with the appropriate classes so that it gets rendered as a note>



**Format**: `reminder add c/CONTACT_INDEX m/MESSAGE d/DATETIME`



* Adds a reminder associated with the contact at the specified `CONTACT_INDEX`.

* The index refers to the index number shown in the displayed contact list.

* The index must be a positive integer 1, 2, 3, …

* The datetime must be in the format `yyyy-MM-dd HH:mm`



**Example**: 

Suppose you want to .... This is what you need to do:



<EACH STEP SHOULD END WITH A FULL STOP>

1. Type ____ in the **Command Box** and press <kbd>Enter</kbd>.



<IMAGE FOR STEP 1 - WIDTH SHOULD BE 900>



<figure>

  <img src="images/meetingListMockup.png" alt="result for 'meeting list'" width="900px">

  <figcaption>Fig. **{TODO}** - Meeting List Mockup.</figcaption>

</figure>



2. ....



<image for step 2>



3. ...



4. The **Result Box** will ... and the **Reminder List** will ...

Command Summary (DONE)

Let's split our command summary based on how we split the Features section in our UG. So we'll have multiple command summary tables. Remember to add a preface between the headers for each section!
Within each section, the command summary table should be sorted in ascending order alphabetically.
SEE: FitBiz's Command Summary
I also propose splitting the examples into a third column of it's own:

Here's the template:


| Command                                                                   | Summary                      | Example (if applicable)                                                                                                          |

|---------------------------------------------------------------------------|------------------------------|----------------------------------------------------------------------------------------------------------------------------------|

| `contact add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…[r/REMARK]…` | Adds a contact to StonksBook | `contact add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague r/birthday: 20 August` |

|                                                                           |                              |                                                                                                                                  |

|                                                                           |                              |                                                                                                                                  |

Stuff in General

Avoid excessive paragraphing (should not have multiple paragraphs with only 1 sentence each)
Should refer to the reader directly.
- e.g. "You should ..." rather than "Users should ..."
MUST always have a preface between headers
- e.g. in Quick Start, before listing down the steps, add something like: "To get started, following these simple steps:”
Informal diagrams, which follows right after the text, need not be labelled.
Insert page numbers
Be as concise as possible.

Other Stuff to Standardise

Let's use <kbd></kbd> to denote keystrokes. e.g. <kbd>Enter</kbd> to get Enter
Labelling of figures: I think we should KIV this first, until we're all done with the UG, otherwise if we were to all add labels, we might have to constantly update the label numbers.
Sections should be numbered - let's not worry about this for now too. I think there are tools available to automatically number it for us. I don't think it's necessary for us to manually write the numbering in your headers
Let's use red for any image annotations, and rounded rectangles over sharp-cornered rectangles
Any screenshots of the UI should omit the top menu (so that the images look consistent regardless of OS)

Sorry, didn't expect that you would have to refactor all the tag commands. Anyways, I tested and it works well!

I think you need to update the examples for the tag commands as well. Also, maybe can update tag add to also use ct and st just for standardisation? (p.s. don't have to do it if you don't think it's worth changing / you're busy atm)

Haven't really looked at the code yet, will do so once the other PRs are merged

LGTM! Just a few tiny changes. Also, for the screenshots, perhaps can remove the top menu (just keeping the UI) so that they look the same for all OSes?

Thanks for pointing those changes out! I've amended them, as well as standardised some formatting stuff throughout the document

Closed in #150

Can't seem to reproduce this. I suspect that the tester has already created a separate meeting called Talk show on 29 Feb 2020 that is not displayed in the list. That is, the two meetings pointed out in the images are different meetings as evident by the different capitalization of the message: Talk show in the output vs talk show in the displayed list.

To check with prof regarding the changes to be made to monitor code coverage

Minor issue, remember to capitalize Supplier and line 276 and 280 as well.

Same issue, minor typo for Supplier

Capitalize also

Similar to comments left on UniqueWarehouseList, should this be removed instead?

Similar to comments left on UniqueWarehouseList, might want to change to replaceSupplier

Minor issue, capitalise Suppliers

Capitalise Suppliers here

Would this mean that 0 is acceptable? Or is isNonZeroUnsignedInteger meant to be a stricter check?

Oh I see that it is being used for index and quantity separately in another file.

Alright got it!

Message should be "Deleted Warehouse: %1$s" instead

In the 3rd sentence:

Should add a space between "The" and edit

In the 4th sentence:

Could be two different way of expression in "the last type specified will use processed"

The rest are well described.

I cant figure out why this paragraph is bold in the file. (Can click the three dots at the top right then click view file)

Minor issue:

Can make warehouse plural as well in this sentence - "Furthermore, another alternative considered would be to create separate commands for warehouse and suppliers respectively."

Will there be a {@code userMacros}? I'm not too sure about how this component of the code.

Maybe "Problem encountered while reading..." or "Unable to read from..." would be better here

Same as above

I think there is missing a word here, should be "original input string when no macro is used"

Can remove extra line here

Oh {@code UserMacros} exist here, the one on top can include too!

Represents 'an' alias

Oh alright! 👍

Minor typo, should be "product or remark" instead

Should it display the biggest warehouse with any PANADOL product or SUSP product instead?

Not sure if it's helpful but one way to make it more concise is to initialize all nameKeywords, productKeywords and remarkKeywords to Optional.empty() then only keep 3 if statement to update them if necessary

Same as above

Can consider renaming the function name to contain Supplier and Warehouse for better readability

Should be "name, product or remark" instead

Should be Updates I think

Have to discuss this later, how to handle it efficiently since not every command takes in email/address/name and like in FindCommand we have to add this to check for "/".

Minor typo, should be "workflow of a" instead

Can consider removing "it is" too

What does this do? Expand the width of md?

Should be removes

"product in a supplier" sounds a bit weird, maybe "a product managed by a supplier or warehouse" is better

Add warehouse or supplier to a supplier?

Should be add "warehouse or supplier" instead

Same as above, "product managed by a supplier or warehouse" would be better

Here too, we should review it if these are retrieved from our individual commands

I forgot a full stop after "e.g" previously, should be "e.g."

Maybe could be like "at least one of the parameters with its corresponding prefix"

Should have a space between i/2' and :

Should I include this in AddCommand as well? Since it's the first touch for users

Minor typo, should be "from"

Consistency across all log messages, should we be keeping the full stop? It concerns the above files as well.

Should be EditSupplierDescriptor instead of Warehouse

Is this meant to be an additional level of check?

Extra line here

Wow nice addition for these

I think it's alright here because it's easier to take just the first word which would be the command word, in the parser we can ignore everything that comes after since there are no params to process.

Could include the file format in front like TxtCommandHistoryStorage if appropriate

Can consider directing the user to the function and class that does the saving since it is being mentioned here.

Will try to help resolve this test case

Are the blank spaces meant to be?

I think is typo cos the rest don't have it

Sentence can be quite long. Can have a line break for "Furthermore" onwards, should be a full stop instead of comma too.

Minor issue but two blank space between the comma and last part of the sentence.

Or a suggested phrasing could be:

The user frequently updates a specific warehouse and decides to create a new macro with the alias "uwm" for the command string "update ct/w n/MainWarehouse" so as to shorten subsequent command inputs.

If the above were to be adopted,

If the user no longer needs the macro with the alias "uwm" and decides to remove it, it can be done by executing the removemacro uwm command.

Should we standardise whether to use correct or valid?

For data and format

Same as above, should it be invalid or incorrect?

Small issue but extra space here, commenting in case I miss it later

Should be missing a space here

Omg this is a lot of effort you put in. I'm thinking if we can use regex on this to pick out all the invalid prefixes

Good work including comments for better readability

Very good work abstracting all these out, it's still a headache that within each command there are so many different things to check for.

Well explained

Undone and redone sounds off, maybe can say Undo/Redo can only be used for commands that modified the CLI-nic data

Can use 'if you' or 'the user'

Can include in the example that the user wants to undo an edit command for example.

Otherwise the second half can consider changing to 'the command executed will be 'undo'.

Should there be more undoable commands?

Good one including these comments for better readability

Are these left empty intentionally?

Hmmm... Okay I'm including these line breaks,

Thanks for pointing it out, I do agree with you and have specified in the next commit!

Oh yes good spot, these were written before we finalized the changes in our commands

Yea this is outdated now, I have fixed it earlier. No wonder I couldn't find it hahaha

Okay as per user guide, we only have Tag for products so yes this should be Remarks!

It shouldn't be remarks either, it would look like this now and should be pretty straightforward without explanation. We can improve on it at a later time because UML is still rather unstable.

Fixed!

I'll update accordingly depending on how we are integrating Macro feature into all other features!

I've broke it up to two parts so the warehouse only doesn't cover the front few prefixes.

I've put it in tildas as it is a param

This makes sense, I've edited it accordingly thanks!

Hmmm... I'm not sure what you mean by that, do we have to implement a command class for logger? Aren't we using the in-built logger?

I wrote it the way as you mentioned initially, then intellij prompted me that it will always return true and thus suggested to change to != null instead. I'm not sure which is better coding practice but I could change it back and ignore the warning if we standarize it across out code

Yup, because it is now an optional field and to make UI a lot less painful I've decided to set optional fields to "".

Unless we want to remove missing fields from UI which can be quite a headache.

Oh yea you're right, I'll look into what I can abstract out without violating SLAP

Oh yea I tried to use Type.supplier and Type.wareshouse but ran into some difficulty when testing for invalid input. I would have to create false input of Type format to do testing. I'll look into this again to see how we can resolve it, same as for the one below.

Yea definitely!

Thanks for the spot!

I've made the change, thanks!

I've changed it to use one of the pre-created descriptor!

Oh yes, thanks for the good spot!

Took me a good minute of staring hahaha, good spot here too!

Good idea, will add in more comments

Undo and redo should be fine and I'll add listmacro after it is merged in

Oh yes I'll fix this, good catch!

Hmmm okay I shall standardise them, another improvement is to display the help message when users select the autocomplete message

Got it thanks!

Yup, i was in the midst of editing both and got distacted by my UML hahahaa

I've resolved this as well as standardise it with adding supplier! Good catch!

Opps it wasn't meant to be changed but I forgot to change it back

Approve for testing purpose to see the badge shows CI fail

Test successful, icon changed to failing.

@zhengweii Revert back to pass CI