demonuspc / burnreport Goto Github PK

Right now the report takes a list of products for processing. This is neat when you are working with a single recipe or working with a single meal. Tracing for example one day does work. But the data becomes flat. It is better to be able to view insert and view the data in a meal oriented way (or at least timed way).
This issue proposes:

Backend

• Nothing to be done. This issue should not change the backend API. The report API will be redone as part of a different issue

Frontend

• Report result should not change. This will be done as a separate issue
• Report Form should have another layer to the form
• The user should should be presented with an empty meal.
• If bar allowing the user to add a meal should be present.
• Adding a meal should add a card that contains the current product form
• For now the search bar can stay on each card.
• When submitting the form the front end should send the same flat payload.

The setup method does not run the full sql that is needed to bootstrap all of the tables and views.
In this issue:

• Refactor the setup functions to just run through all of the setup SQL on every start.
• Must include the full_product view.

Right now the data functions are operating on the assumption that the data will always return. This is of course not always correct. This issue proposes:

• Adding a wrapper interface to all data fetching functions. (Generic)
• The wrapper should indicate if request was successful or not
• The functions should be updated so that they do return a failure state
• Update downstream components to account for failure and success.

Adding single products is sufficient for most cases. This has also been extended with custom portion sizes. However for more complex objects this can be tedious, especially if dieting or meal prepping where the recipie sizes will be quite standard.
This issue proposes:

Backend

• Adding a recipies back end api
  • A separate search api for recipies
  • Listing all recipies
  • Getting a single recipie
  • Createing a new recipie
  • Updating an existing recipie
  • Deleting a recipie

Three more tables:

• Recipes, this is the top level table containing the general recipe details
• RecipeEntries this table will contain all the product and mass relationships to the recipes
  • It will contain the foreign key to the recipe
  • Foreign key to the product id
  • The mass in grams/ml of the product
• Servings: this will be the portions table but for Recipies

There are 2 ways of doing this:

• Perform 2 db queries. One for the top level recipe and one a join select for the recipie entries
• Perform a union select and return a large flat structure that I will then be filtered out. (As with hierarchies)

Frontend

• A new page: Recipe

• The page should be similar to the Products page.

  • There should be a search bar
  • The user should be able to search all available recipes by name

• Instead of in page product information the user shuld be redirected to the single recipe page

• The recipe page should contain

  • Name
  • Total Nutritional information
  • Products in the recipe

• The page should not include instructions on how to make the recipe.

• The user should be able to recalculate the nutritional information based off

  • Grams
  • Serving
  • Or any other portion size the user can add

• The recipe page should have a link to delete the recipe

• Add Recipie page

  • A form similar to the product one
  • Additionally there should be a product form similar to the portions form where the user can enter products and their sizes. (In fact they will most likelly be identical)

When creating a report, the user is not able to add amounts other than whole numbers. MEaning that one cannot add 12.5 grams for example or 0.5 of a pot.
To fix:

• The user should be able to enter non whole numbers.
• The user should not be able to add negative numbers, this should default to 0