Merge branch 'bugfix' of https://github.com/AY1920S1-CS2103T-F14-4/main…

… into bugfix

docs/DeveloperGuide.adoc

@@ -201,6 +201,101 @@ Similarly, calling `free` command will:
 // end::task-scheduling[]
 
 
+// tag::task-feature[]
+=== Task Feature (E.g. Add Delivery Task)
+==== Implementation
+The *Add Delivery Task* feature adds a new task into a task list. +
+It uses the `AddTaskCommand`, which extends `Command`, to add a `Task` into the `TaskManager`.
+`AddTaskCommandParser` is also utilised to parse and validate the user inputs before sending it to `AddTaskCommand` to execute.
+'AddTaskCommand' requires the following fields: `Task`, `customerId`.
+The attributes of Task is as follows:
+
+.Class Diagram of Task class.
+image::Task.png[]
+
+As seen in the above class diagram, `driver` and `eventTime` are optional fields that are not mandatory when adding a task.
+They will be assigned subsequently using `assign` command. (Refer to Assign feature)
+The mandatory fields for users are: 'description', 'date' and 'Customer'.
+After the validation is completed, `AddTaskCommand` will fetch `Customer` using the `customerId` through the `CustomerManager`.
+A unique id will also be allocated to the task for differentiation.
+
+The following sequence diagrams show how the add task operation works:
+
+.Sequence Diagram of adding a task.
+image::AddTaskCommand.png[]
+.Sequence Diagram of Model interaction with the CustomerManager and TaskManager for adding a task.
+image::ModelInteractWithManagers.png[]
+
+[NOTE]
+The flow of how the task is being accessed and managed as shown above is the same for other task related command
+such as edit task command (`editT`) and delete task command (`del`).
+
+==== Design Considerations
+
+===== Aspect: Coupling of Task and other entities (Driver and Customer)
+
+* **Alternative 1 (current choice):** Task class contains Driver and Customer classes as attributes.
+** Pros: Centralised Task class that encapsulates all the information, which makes it easy to manage task.
+** Cons: Task will have to depend on Driver and Customer. Decreases testability.
+* **Alternative 2:** Driver and Customer classes have Task class as attribute.
+** Pros: Easy to access tasks through the respective classes. (Driver and Customer classes)
+** Cons: Having 2 classes depend on Task class. Decreases testability.
+// end::task-feature[]
+
+
+
+// tag:generate-pdf[]
+=== Generate PDF Task Summary Feature
+==== Implementation
+The *generate PDF Task Summary* feature creates a task summary in a user-friendly layout in PDF format for *user reference* and *archive* usage.
+`PdfCreator` class creates and saves the PDF document as well as formatting its layout.
+It is implemented with the help of an external library, https://github.com/itext/itext7[iText7].
+
+[NOTE]
+Regarding iText's license, it can be used for free in situations where you distribute your software for free.
+It is a Affero General Public License (AGPL) library. +
+Information updated as of 6 November 2019.
+For more information, please visit the https://itextpdf.com/en[iText official website].
+
+The following sequence diagram shows how the user command `savepdf` is being executed and handled.
+
+.Sequence Diagram of how PDF task summary is saved.
+image::SavePdfCommand.png[]
+
+NOTE: The lifeline for `SavePdfCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+Notice that only the `filepath` and the `date of delivery` is needed when calling `saveDriverTaskPdf`.
+This is because only the saving location of the PDF file and the date, where the task summary will be based on, are the only fields needed for the `PdfCreator`.
+The rest of the components, such as fetching of the tasks, will be handled by the `Model` while the formatting will be handled by `PdfCreator`.
+
+The following sequence diagram shows how the model interact with `PdfCreator` to generate the PDF task summary.
+
+.Sequence Diagram of how the model generates the PDF task summary.
+image::GeneratePdfSequenceDiagram.png[]
+
+The `PdfWrapperLayout` provides a outer canvas to encapsulates all the layouts.
+The following layouts are mainly what makes up the task summary:
+
+* `PdfDriverLayout` class - wraps driver details.
+* `PdfCustomerLayout` class - wraps customer details.
+* `PdfTaskLayout` class - wraps task details.
+
+The following activity diagram shows what happens when a user executes the `savepdf` command:
+
+.Activity Diagram of how a PDF task summary is generated.
+image::GeneratePdfActivityDiagram.png[]
+
+==== Design Considerations
+
+===== Aspect:
+
+* **Alternative 1 (current choice)**: Abstract the layout of each part of the task summary.
+** Pros: Encourages reuse and easier to manage and add on.
+** Cons: Harder to implement.
+* **Alternative 2**: Do the whole task summary layout in 1 class.
+** Pros: Easy to implement.
+** Cons: Harder to manage.
+// end::generate-pdf[]
 
 
 
@@ -313,44 +408,6 @@ We are using `java.util.logging` package for logging. The `LogsCenter` class is
 
 Certain properties of the application can be controlled (e.g user prefs file location, logging level) through the configuration file (default: `config.json`).
 
-=== Task Feature (E.g. Add Delivery Task)
-==== Implementation
-The *Add Delivery Task* feature adds a new task into a task list. +
-It uses the `AddTaskCommand`, which extends `Command`, to add a `Task` into the `TaskManager`.
-`AddTaskCommandParser` is also utilised to parse and validate the user inputs before sending it to `AddTaskCommand` to execute.
-'AddTaskCommand' requires the following fields: `Task`, `customerId`.
-The attributes of Task is as follows:
-
-.Class Diagram of Task class.
-image::Task.png[]
-
-As seen in the above class diagram, `driver` and `eventTime` are optional fields that are not mandatory when adding a task.
-They will be assigned subsequently using `assign` command. (Refer to Assign feature)
-The mandatory fields for users are: 'description', 'date' and 'Customer'.
-After the validation is completed, `AddTaskCommand` will fetch `Customer` using the `customerId` through the `CustomerManager`.
-A unique id will also be allocated to the task for differentiation.
-
-The following sequence diagrams show how the add task operation works:
-
-.Sequence Diagram of adding a task.
-image::AddTaskCommand.png[]
-.Sequence Diagram of Model interaction with the CustomerManager and TaskManager for adding a task.
-image::ModelInteractWithManagers.png[]
-
-[NOTE]
-The flow of how the task is being accessed and  managed as shown above is the same for other task related command such as Edit and Delete.
-
-==== Design Considerations
-
-===== Aspect: Couping of Task and other entities (Driver and Customer)
-
-* **Alternative 1 (current choice):** Task class contains Driver and Customer classes as attributes.
-** Pros: Centralised Task class that encapsulates all the information, which makes it easy to manage task.
-** Cons: Task will have to depend on Driver and Customer. Decreases testability.
-* **Alternative 2:** Driver and Customer classes have Task class as attribute.
-** Pros: Easy to access tasks through the respective classes. (Driver and Customer classes)
-** Cons: Having 2 classes depend on Task class. Decreases testability.
-
 === Customer Feature (E.g. Add Customer)
 ==== Implementation
 The *Add Customer* feature adds a new Customer into a Customer list. +

docs/UserGuide.adoc

@@ -195,15 +195,17 @@ Deletes task (Task ID: 1) from the task manager.
 * `del d/2` +
 Deletes driver (Driver ID: 2) from the driver manager.
 
-==== Saves assigned delivery tasks into PDF document: `savepdf`
-The PDF document is arranged in a table format to allow easy reference of the delivery tasks that is assigned to each drivers for the date. +
+==== Saves assigned delivery tasks for a specific date into PDF document: `savepdf`
+The PDF document is arranged in a table format to allow easy reference of the delivery tasks that is assigned to each drivers for the date.
+Its purpose is for user reference and archive. +
+Refer to <<PdfLayout>> for sample. +
 Format: `savepdf [DATE]`
 
 ****
 * `DATE` format is dd/mm/yyy.
 * `DATE` field is OPTIONAL. If date field is not declared, it will take the date of today.
 * PDF document will be saved under `data` folder which is the same directory as where you put the deliveria.jar.
-* Name of the PDF document will be DeliveryTasks (DATE).pdf .
+* Name of the PDF document will be DeliveryTasks [DATE].pdf .
 ****
 
 Examples:
@@ -263,3 +265,6 @@ There is no need to save manually.
 *Q*: How do I know the list of commands? +
 *A*: The `help` command will give a list of available commands.
 
+== Appendix
+.PDF Document generated by `savepdf` command
+image::/images/DeliveryTasks_Pdf_Layout.png[id="PdfLayout", Delivery Tasks PDF]

docs/diagrams/AssignActivityDiagram.puml

@@ -5,22 +5,31 @@ start
 'Since the beta syntax does not support placing the condition outside the
 'diamond we place it as the true branch instead.
 
-if (Is force assign?) then ([yes])
 
+if (Are the driver and task valid?) then ([yes])
 else ([no])
-    : Check against current schedule;
-    if (The most optimal time slot?) then ([yes])
+ stop
+endif
+
+if (Is the task already assigned?) then ([yes])
+
+else ([yes])
+    if (Is force assign?) then ([yes])
+    : Free that task;
     else ([no])
         stop
     endif
 endif
-if (Within working hours?) then ([yes])
-else ([no])
+
+: Check against the driver's schedule;
+if (Is the target driver available during the proposed time) then ([yes])
+    : assign;
     stop
-endif
-if (No schedule clash?) then ([yes])
+else ([no])
+    if (Was the task changed?) then ([yes])
+        : Restore that task;
     else ([no])
-        stop
 endif
 stop
+
 @enduml

docs/diagrams/GeneratePdfActivityDiagram.puml

@@ -0,0 +1,28 @@
+@startuml
+start
+:User executes `savepdf` command;
+
+:Checks if there is tasks
+assigned for the day;
+
+'Since the beta syntax does not support placing the condition outside the
+'diamond we place it as the true branch instead.
+
+if () then ([has tasks assigned for the day])
+    if () then ([file path does
+    not exists])
+        :Create file path;
+    else ([else])
+    endif
+    :Generates a task summary
+    in PDF format;
+    :Save PDF document
+    in the file path;
+else ([else])
+    :Notify user that no tasks
+    are assigned for the day;
+    stop
+endif
+
+stop
+@enduml

docs/diagrams/GeneratePdfSequenceDiagram.puml

@@ -0,0 +1,67 @@
+@startuml
+!include style.puml
+
+box Model MODEL_COLOR_T1
+participant ":Model" as Model MODEL_COLOR
+participant ":PdfCreator" as PdfCreator MODEL_COLOR
+participant ":TaskManager" as TaskManager MODEL_COLOR
+participant ":PdfWrapperLayout" as PdfWrapperLayout MODEL_COLOR
+end box
+
+
+[-> Model : saveDriverTaskPdf( \n FILEPATH*, 5/11/2019)
+note right: FILEPATH*: "./data/DeliveryTasks 2019-11-5".pdf"
+activate Model
+
+create PdfCreator
+Model -> PdfCreator : new PdfCreator(FILEPATH*)
+activate PdfCreator
+
+PdfCreator --> Model
+deactivate PdfCreator
+
+Model -> TaskManager : getList()
+activate TaskManager
+
+TaskManager --> Model: tasks
+deactivate TaskManager
+
+Model -> TaskManager : getDriversFromTasks()
+activate TaskManager
+
+TaskManager --> Model: drivers
+deactivate TaskManager
+
+Model -> PdfCreator : saveDriverTaskPdf(tasks, drivers, 5/11/2019)
+activate PdfCreator
+
+PdfCreator -> PdfCreator ++: createDocument()
+PdfCreator --> PdfCreator --: document
+
+PdfCreator -> PdfCreator ++: insertCoverPage(document, 5/11/2019)
+PdfCreator --> PdfCreator --
+
+PdfCreator -> PdfCreator ++: insertDriverTask(document, 5/11/2019)
+
+create PdfWrapperLayout
+PdfCreator -> PdfWrapperLayout :  new PdfWrapperLayout(document)
+activate PdfWrapperLayout
+
+PdfWrapperLayout --> PdfCreator
+deactivate PdfWrapperLayout
+
+PdfCreator -> PdfWrapperLayout : populateDocumentWithTasks(tasks, 5/11/2019);
+activate PdfWrapperLayout
+
+PdfWrapperLayout --> PdfCreator
+deactivate PdfWrapperLayout
+
+PdfCreator --> PdfCreator --
+
+PdfCreator --> Model
+deactivate PdfCreator
+
+[<-- Model
+deactivate Model
+
+@enduml

docs/diagrams/SavePdfCommand.puml

@@ -0,0 +1,73 @@
+@startuml
+!include style.puml
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant ":SavePdfCommandParser" as SavePdfCommandParser LOGIC_COLOR
+participant "p:SavePdfCommand" as SavePdfCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant ":Model" as Model MODEL_COLOR
+end box
+
+[-> LogicManager : execute(\n"savepdf 5/11/2019")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand(\n"savepdf 5/11/2019")
+activate AddressBookParser
+
+create SavePdfCommandParser
+AddressBookParser -> SavePdfCommandParser : SavePdfCommandParser()
+activate SavePdfCommandParser
+
+SavePdfCommandParser --> AddressBookParser
+deactivate SavePdfCommandParser
+
+AddressBookParser -> SavePdfCommandParser : parse("savepdf 5/11/2019")
+activate SavePdfCommandParser
+
+create SavePdfCommand
+SavePdfCommandParser -> SavePdfCommand : SavePdfCommand(5/11/2019)
+activate SavePdfCommand
+
+SavePdfCommand --> SavePdfCommandParser : p
+deactivate SavePdfCommand
+
+SavePdfCommandParser --> AddressBookParser : p
+deactivate SavePdfCommandParser
+
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+SavePdfCommandParser -[hidden]-> AddressBookParser
+destroy SavePdfCommandParser
+
+AddressBookParser --> LogicManager : p
+deactivate AddressBookParser
+
+LogicManager -> SavePdfCommand : execute()
+activate SavePdfCommand
+
+
+note right : FILEPATH*: "./data/DeliveryTasks 2019-11-05.pdf"
+SavePdfCommand -> Model : saveDriverTaskPdf(FILEPATH*, 5/11/2019)
+activate Model
+
+Model --> SavePdfCommand
+deactivate Model
+
+create CommandResult
+SavePdfCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> SavePdfCommand
+deactivate CommandResult
+
+SavePdfCommand --> LogicManager : result
+deactivate SavePdfCommand
+
+[<--LogicManager
+deactivate LogicManager
+
+@enduml