Notes

Another example of an Epic, as it has multiple things which need to be created. Each of the things which are needed to create this should be a task in it's own right.

Also the description of this task includes references to specific view components, in a real-life user story no such technical detail will be present, as the user story needs to be readable by a user and should never include any technical details. I am including technical details here to give you hints on how to complete the tasks this Epic represents.

Before working on Epics, you should break them down into individual tasks.

On the client list view, add a button to the DataGrid for each row. The button should be called "Delete" and on clicking it:

• prompt the user to ensure that they definitely want to delete this client
• if no, do nothing
• if yes, call the a method on the ClientService called DeleteClient

The DeleteClient method takes a single parameter, the Client ID. This method will make an HTTP DELETE request to https://2023-invoice-gen.azurewebsites.net/Client/{Client ID} (where {Client ID} is the ID of the client. *

The DeleteClient method will return a bool based on whether the HTTP DELETE call succeeded or not. This will be passed up to the UI, and only on successfully deleting the Client will the DataGrid be updated (by removing that client from the list).

* = at the time of writing this issue, this endpoint doesn't exist. I will update the issue when this endpoint exists.

Notes

Another example of an Epic, as it has multiple things which need to be created. Each of the things which are needed to create this should be a task in it's own right.

Also the description of this task includes references to specific view components, in a real-life user story no such technical detail will be present, as the user story needs to be readable by a user and should never include any technical details. I am including technical details here to give you hints on how to complete the tasks this Epic represents.

Before working on Epics, you should break them down into individual tasks.

The invoice list will likely become very long and not easy to read once enough are added to the system, as such you should add paging to the datagrid.

There are lots of ways to do this, two popular approaches are:

1. load the entire list of invoices from the service (costly and will take a long time), then enable the DataGrid's paging controls
2. load a page of invoices (say 10) from the server, then add "next" and "previous" buttons, allowing you to request different pages of invoices from the server

I would prefer the second approach, but try the first approach initially. This will help you understand what paging looks like and how it works behidn the scenes.

This will require you to synchronise your work with the API engineer (me) to ensure that the API has what you want. Discuss with them how you would like to request a page of data from the API.

Currently there is no way to add Line Items to an invoice. Add a button near to the LineItems table and have it show a new window.

The AddLineItemView should have three inputs and one read-only field:

• Description – string
• Quantity – int
• Cost – double
• Total – double (read-only)

These should be mapped to four properties on a LineItemModel using two-way binding:

• Description – string
• Quantity – int
• Cost – double
• Total – double (read-only)

When a user alters the Quantity or Cost values, the Total value should update in the UI. For now ignore the fact that currencies exist.

The UI for the AddLineItemView should have those four properties shown, and an Add and Cancel button. On pressing the cancel button, the user is prompted (example: "are you sure?") and if they say yes, they are taken back the to InvoiceCreation screen and all values in the AddLineItemView are reset. Otherwise they stay on the AddLineItemView.

If the user clicks Add, they are prompted (example: "are you sure?") and if they say yes, the LineItemModel (not the LineItemViewModel) will do a check to validate the inputs:

• Description cannot be null or empty
• Quantity must be greater than or equal to 1
• Cost must be greater than or equal to 0

If validation completes, the LineItemModel will return the UI, which will:

• add the new LineItem and all of it's details to the list of LineItemViewModels internally
• update the LineItem datagrid to include the new value
• reset all values on the LineItemView

The MVVM pattern should be used to create a Model which represents the data behind the Create Client screen.

As a reminder, the Create Clien model should have the following properties:

• Client name – string
• Contact name – string
• Contact email – string
• Client Address – string

And each property should have validation ensuring that it is both present and correct. "Correct" in this context might mean different things for different values. For instance:

• Client name cannot be empty or null
• Contact name cannot be empty or null
• Contact email must be a valid email address
• Client address must not be empty or null

There are ways to validate the Client name, Contact name, and Client address with external libaries. But you should focus on the validation as a priority.

This Model will represent the values shown on screen, but also represent the data which will be sent to an API for saving the client model.

Notes

This is what is called an Epic, as it has multiple things which need to be created. Each of the things which are needed to create this should be a task in it's own right.

Also the description of this task includes references to specific view components, in a real-life user story no such technical detail will be present, as the user story needs to be readable by a user and should never include any technical details. I am including technical details here to give you hints on how to complete the tasks this Epic represents.

All epics should be broken down into individual tasks before you work on them.

We need a new view, an InvoiceView. This is a read-only view of all of the Invoices in the system. This view will have a DataGrid which contains all of the Invoices in the system. The DataGrid will have four properties shown per row:

• Auto Generated ID
• Data Created
• Total Value
• a View Details button

On clicking the ViewDetails button, the user will be taken to a view similar to the create invoices view, but all properties will be read-only/disabled. There will be only one button on the invoice view, which will close the view and take the user back to the list of invoices - i.e. "close"

Hints

• You will need a new view: InvoiceListView
• You will need a new service InvoiceListService with a single method GetInvoices
• GetInvoices will return a list of InvoiceModel
• GetInvoices will perform an HTTP GET request to https://2023-invoice-gen.azurewebsites.net/Client*
• The new view will two-way bind the list to the DataGrid
• Clicking on the View Details button will display the details from the relevant row in the InvoiceDetails view

* = at the time of writing this issue, the endpoint does not exist. I will update this issue when that endpoint exists.

Notes

Another example of an Epic, as it has multiple things which need to be created. Each of the things which are needed to create this should be a task in it's own right.

Also the description of this task includes references to specific view components, in a real-life user story no such technical detail will be present, as the user story needs to be readable by a user and should never include any technical details. I am including technical details here to give you hints on how to complete the tasks this Epic represents.

Before working on Epics, you should break them down into individual tasks.

The client list will likey become very long and not easy to read once enough are added to the system, as such you should add paging to the datagrid.

There are lots of ways to do this, two popular approaches are:

1. load the entire list from the service (costly and will take a long time), then enable the DataGrid's paging controls
2. load a page (say 10) from the server, then add "next" and "previous" buttons, allowing you to request different pages of invoices from the server

I would prefer the second approach, but try the first approach initially. This will help you understand what paging looks like and how it works behidn the scenes.

This will require you to synchronise your work with the API engineer (me) to ensure that the API has what you want. Discuss with them how you would like to request a page of data from the API.

Related to #17

Using all of the code which exists at this point, allow the user to create a new invoice in the UI, adding arbitrary numbers of LineItems to it, and filling in all of the properties on the InvoiceModel.

When the user is happy with their new invoice, they can click a Create (or Save) button at the bottom of the Invoice creation UI. This will:

• display a yes/no box, prompting the user to ensure that they are happy to save
  • if no, dismiss the box and do nothing new
  • if yes, the InvoiceViewModel will perform validation on all of the invoice properties. These include:
    • Client; a valid client must be selected
    • Line Items; must contain at least one LineItemModel
    • Total Value; must be greater than 0
    • VAT Rate; must be a positive integer, but no higher than 25%
    • Invoice Total; must be a postiive number
    • Issue Date; must be today or in the future
    • Due Date; cannot be before today
  • Depending on the validation result:
    • If validation fails, show a MessageBox with details as to why
    • if validation completes, call a method on the InvoiceService which will send the Invoice data to the API

Notes

You do not have an InvoiceService, so you will need to create one.

The URL to POST the data to will be https://2023-invoice-gen.azurewebsites.net/Invoices, but at the time of writing this issue it does not exist. I will update the issue when the HTTP POST endpoint exists.

Notes

Another example of an Epic, as it has multiple things which need to be created. Each of the things which are needed to create this should be a task in it's own right.

Also the description of this task includes references to specific view components, in a real-life user story no such technical detail will be present, as the user story needs to be readable by a user and should never include any technical details. I am including technical details here to give you hints on how to complete the tasks this Epic represents.

Before working on Epics, you should break them down into individual tasks.

On the Invoice list view, add a button to the DataGrid for each row. The button should be called "Delete" and on clicking it:

• prompt the user to ensure that they definitely want to delete this invoice
• if no, do nothing
• if yes, call the a method on the InvoiceService called DeleteInvoice

The DeleteInvoice method takes a single parameter, the invoice ID. This method will make an HTTP DELETE request to https://2023-invoice-gen.azurewebsites.net/Invoice/{Invoice ID} (where {Invoice ID} is the ID of the invoice. *

The DeleteInvoice method will return a bool based on whether the HTTP DELETE call succeeded or not. This will be passed up to the UI, and only on successfully deleting the Invoice will the DataGrid be updated (by removing that invoice from the list).

* = at the time of writing this issue, this endpoint doesn't exist. I will update the issue when this endpoint exists.

The ViewModel for the Create Client workflow should have a new method which takes a ClientModel and sends a message out to a WebApi to store the new Client record. This new method should be called CreateClient and be called on by the CreateClient view.

When the method is called, it will ensure validation on the passed CreateClient model (see #9 for details), and should perform one of two actions based on the validation, either:

1. drop out of the method and have the view display a message (a simple MessageBox will do for now) letting the user know that they did something wrong, and what they did wrong)
2. continue on to call an external HTTP-based WebAPI

For the second pathway (i.e. Create Client details are present and correct), the method should perform an HTTP PUT of the CreateClient model to https://2023-invoice-gen.azurewebsites.net/Client. The code which does the HTTP PostPUT should live in the ClientService class - you will need to create a method in the service to do this, too.

The ClientService will need to return either true of false, dependant on whether the HTTP POSTPUT was successful or not. The ViewModel should return the value of the call to the ClientService back to the UI, and show a MessageBox with a relevant message.

If the HTTP PUT completed successfully, all inputs on the UI and values in the Model should be reset. If not, then they should be kept as is.

Note

The https://2023-invoice-gen.azurewebsites.net/Client PUT endpoint now exists. Take a look at the Swagger page on the live app for more hints and tips of how to use it.

Notes

Another example of an Epic, as it has multiple things which need to be created. Each of the things which are needed to create this should be a task in it's own right.

Also the description of this task includes references to specific view components, in a real-life user story no such technical detail will be present, as the user story needs to be readable by a user and should never include any technical details. I am including technical details here to give you hints on how to complete the tasks this Epic represents.

Before working on Epics, you should break them down into individual tasks.

We need a view which displays all of the clients in a DataGrid. The data grid should have three columns:

• Client Name
• Contact Name
• View button

The View button should take the user to a read-only view of the details in a client record. This should contain all of the properties of a client, but they should all be read-only/disabled. There should be only one button on the read-only view: "close", which closes the view and takes the user back to the list of clients.