aaron-jaeger / servicerequestmanagement Goto Github PK

• GET method.
• Route api/servicerequest
• Response codes 201, and 204 (Chicken or the egg her... Either pull this ticket in first or create SQL script to clear out records for the 204 response).
• Responds with an empty list or a list of ServiceRequestDTOs.
• Write unit-tests.
• Document where necessary.

• Create seed directory with abstractions and interfaces.
• Create aggregate root domain model. Really hope this is a service request, because I'll have to change the repo name if it's not.
• Create CurrentStatus enum.
• Stub out ServiceRequestController.
• Create ServiceRequest DTO. Needs id, building code, description, current status, created by, created date, last modified by, and last modified date.
• Document things that aren't obvious or don't make sense.

Steps to reproduce:

1. Create service request with valid date.
2. Update any fields on the service request, but entirely remove the "currentStatus" field from the request body.
3. Observe the service request response.

Expected outcome:
The "currentStatus" property is "Created".

Actual outcome:
The "currentStatus" property is "NotApplicable".

Note: If the "currentStatus" field in the request body has an empty string as a value, it will throw a 400. Don't break that functionality when fixing.

Problem:
Domain validation is handled by throwing exceptions, and picking them up and converting to a 400 bad request with a custom ProblemDetails object. This is poor UX. If the user makes multiple validation errors in a single request, they will only know about the first error to throw an exception until they fix only that first error and try the request again. Also, the format for domain validation errors is slightly different than the format for model validation errors.

Proposed Solution:

1. Implement a solution that validates all the domain data and aggregates all of the errors into a single 400 bad request object.
2. Fix formatting of domain validation errors to match model validation errors.

• PUT method.
• Route api/servicerequest/{guid:id}
• Respone codes 200, 400 (need to think up some validation), and 404.
• Responds with the updated ServiceRequestDTO.
• Write unit-tests.
• Document where necessary.

• POST method
• Route api/servicerequest
• Request body should take at minimum building code (string), description (string), and current status (enum).
• Response codes 201 and 400 (I need some sort of validation for a 400. Maybe I'll add some required fields and character limits).
• Responds with ServiceRequestDTO.
• Write unit-tests.
• Document where necessary.
• After CreateServiceRequestCommand is created, register DI.

• Create a bunch of tickets to keep me organized.
• Create main branch, set as default, and delete master branch.
• Create API project in .Net Core 3.1.
• Create domain project in .Net Standard 2.1.
• Create infrastructure project in .Net Standard 2.1.
• Create unit-test project in .Net Core 3.1 with xUnit.
• Pull in Mediator NuGet package. Wire in with DI. Can't wire DI in yet. Need to do it when I have an implementation I can perform reflection on. Whoops.
• Create logging behavior. Wire in with DI.
• Set CORS policy to allow all.
• Pull in Serilog NuGet package. Set log levels in appsettings.json.
• Pull in Swagger. Set XML documentation output directory. Wire in with DI.

• Pull in EF Core NuGet packages. Probably just stick with a local SQLServer instance.
• Create DbContext class. Wire in with DI.
• Create DB transaction behavior. Wire in with DI.
• Create entity configurations.
• Stub out repositories. Wire in with DI.
• Add connection string to localdb in appsettings.json.
• Create and apply migration.

• GET Method.
• Route api/servicerequest/{guid:id}.
• Response codes 200 and 404.
• Responds with a single ServiceRequestDTO.
• Write unit-tests.
• Document where necessary.

• DELETE method.
• Route api/servicerequest/{guid:id}
• Response codes 201 (this seems confusing. 200 or 204 maybe?) and 404.
• Write unit-tests.
• Document where necessary.