kylestank / copeid-server Goto Github PK

The Contributor model only has a Name property. We need to add an extra Description (or similar) property to this model so users can fill our what a contributor's contribution actually was.

Requirements

• Add Description property to Contributor entity model
• Add Description property to ContributorQueryModel
• Create EF migration for model update

This is a fairly large issue that will need to be expanded upon once development begins.

We need functionality for authentication and authorization in our API. Currently, any user can use any endpoint and cause havoc if they know enough. Not fun. We must add both authentication and authorization to the application.

Requirements

• Controller to authenticate users
• Controller to authorize users

Note: This entire issue (and especially the listed requirements) will change once development begins. For now, we only need to be tracking this so it does not get forgotten.

While the Filter feature of the API works exceptionally well, it is very messy. The controller, service, and naming of view models needed cleaned up drastically.

Problem

The /Document/VerifyMime/{mimeType} endpoint gives a 404 on the API production application. This does not occur in local development.

Replication

1. Navigate to /admin/documents on the production client application.
2. Choose any file to upload
3. Open Chrome DevTools and navigate to the Console tab
4. If a 404 error is present, this bug has been replicated

Solution

We are unaware of what is causing this but we have some assumptions on the matter. Using a GET request to check a MIME type seems slightly odd, hindsight 20/20. Change this endpoint to a POST request and accept the MIME type in the body header.

While this error does not currently occur while in local development, similar errors have previously. This is most likely related to the structure of the route in the .NET application. Rather than passing an encoded MIME type value, we should just pass this value to the body in a POST request.

Summary

We need the functionality to store images for the Genus and Specimen entities within the application. Since we are using Azure for our production environment, we should make use of their file storage resource. We need access to perform essential CRUD operations within this resource.

Since we anticipated this ahead of time, there is a URL parameter in the Genus and Specimen entities. However, we may need to add some sort of file ID to each entity to properly keep track of uploaded file.

Furthermore, research into how Azure's file storage works is essential.

Requirements

• Setup file storage within Azure
• Research Azure file storage SDK/API
• Create service to perform CRUD operations within Azure's file storage setup
• Hook up file storage service to Genus entity
• Hook up file storage service to Specimen entity
• (Optional) Add Azure file ID field to Genus entity
• (Optional) Add Azure file ID field to Specimen entity

Summary

The abstracted BaseEntityController class does offer support for filtering results, ordering results, or including foreign key related results. We need all three of these capabilites in order to move forward with the Filter Module in copeid.

Requirements

• Create abstract query object for GET endpoints
• Add support for filtering/searching results
• Add support for ordering results
• Add support to include foreign key related results

Summary

The current CORS policy was recently updated to allow access to the API from anywhere in any environment. Initially this was restricted to development environments only. However, while completing issue #12, I committed a temporary hack to allow access to the API from any inbound connection.

This is not ideal.

Since we are not building a REST API that will be consumed by thousands of users on any device, an open CORS policy presents a potential security risk.

There are two potential solutions for handling CROS that I am aware of.

Solution One (Fallback)

Create a configuration item within our appsettings.json file that contains an array of allowed origins, headers, etc.

This is not the ideal solution as it requires hard-coded URLs within our configuration files. While this is better than actual hard-coded string values, there is a potential better solution.

Solution Two (Preferable)

Update the CORS policy within our Azure App Service for copeid. The primary benefit to this solution is that it keeps our configuration in the same area as the rest of the configuration for the entire copeid production environment. Updating configuration through Azure is a mere click of a button and thus more difficult to make stupid mistakes.

Requirements

• Investigate Solution Two
• Assuming Solution Two is possible, update Azure settings
• If Solution Two is not possible, fallback to Solution One
• Test client app in production to validate updated CORS policy has been properly implemented

Summary

There is no existing README.md file at the moment. In favor of describing what this project is, a README.md needs to be created.

Requirements

• Give brief description of what this project is
• Provide instructions for running/building the project
• Add code standards that must be at least somewhat adhered to (consider creating GUIDELINES.md)

The AdminPageModule, FilterPageModule, and InfoPageModule modules have a structure that is easy to modify, expand, and understand. The remaining feature modules should have a structure that matches the aforementioned modules.

Requirements

• Refactor structure of DashboardPageModule
• Refactor structure of DefinitionsPageModule
• Refactor structure of ReferencesPageModule

Summary

Every project will inevitably encounter errors. This is particularly true for web API projects, where clients will send only God knows what to the server. In order to keep our error messages coherent in our client application, we need to refactor the manner in which we process expected errors.

Requirements

• Create abstract error responses
• Create base API controller to provide methods to generate error responses
• Update existing controller errors to use new error methods

Wherever the client copeid application pulls an array of data from the API that is displayed within one of the many tables in the Admin pages, all of the rows within a given table are returned at once. For example, if a table has a total of 2000 records, all 2000 records would be queried, returned, and rendered at the same time. Behavior like this has multiple issues.

1. The user's internet connection will be using extra data
   a. If the user has a limited data plan, they will unknowingly be using their data for no obvious reason to them
   b. If the user's internet connection is slow, the final response will taken even longer than average requests already being slowed down due to speed
2. The database server will use extra resources to query results
   a. Our current database server is not expensive; therefore, queries returning a plethora of records tend to take some time
   b. Using extra resources for no reason is never a good plan
3. The entire UX will be degraded due to slower performance and response time
4. Following the example, returning 2000 records at the same time is not commonly required
   a. It does not make sense to return data that is not required
   b. When it is required, it is best to manually create an option in a query model and/or a custom endpoint

Requirements

• Create generic, reusable pagination models
  • Create a HTTP request model that contains a PageNumber and PageSize property
  • Create an HTTP response model that contains a Count and Data property
• Create either a service or static class that filters a given IQueryable based on the input of a provided HTTP request model
• Test implementation on any of the existing controllers
• (Optional) Investigate effort required to add pagination to EntityQueryModel
  • If it does not make sense to add pagination to all query models, consider adding a new [FromQuery] parameter to all GET methods for the HTTP request model

Summary

There is no existing production deployment of the application. Considering our application is built on the Microsoft .NET stack, it makes sense to deploy using Microsoft Azure. There are multiple steps outlined below that must be satisfied before we can have a functional production application running.

Requirements

• Create Azure App Service
• Create Azure SQL Server
• Create Azure SQL Database
• Configure settings for all three items mentioned above
• Update repo settings to automatically deploy when push occurs to master branch