chrisqgeorge / open-everything-app Goto Github PK

API route to retrieve user data from the database.
Should use the current logged in user to get one of the datapoints (Weight int for example) and pass the complete dataset to the frontend for display. May need some data aggregation in the API to create charts as well and pass the images or compressed data to the frontend (numpy?)

We should develop an automated unit testing pipeline that is run before any push to main. Any pushes without a minimum code coverage should be rejected.

We could also make an additional unit testing framework to evaluate plugins automatically.

Connect the api/token route to a login screen and serve data with an authenticated user. Also take token and store it so that the user doesn't have to login on every page refresh

For pages with user addable widgets, the user should also be able to change the layout of widgets. Need to figure out default layout behavior if a new user data attribute is added (don't change layout by default?)

Api route that allows the user to login

Route to allow for arbitrary user setting changes in the user settings list (might be a better way to represent user settings in DB). This route should only change settings, not add additional settings. The settings can be initialized on user registration.

A method should be created to parse json integration files and automatically get data from those integrations. The OpenAI GPTs API feature is a good example of this. The json might be able to be stored in the database and be user editable rather than hardcoded. (hardcoded for MVP should be fine)

An API route to add datapoints to the database. The route should add the data to the document with the matching datapoint name with the matching username. If the data storage document exists, should use $push to add to the storage array. When the document approaches the document size limit (15 mb), create a new document and link current document to next document in a linked-list style. This should rarely happen as even a years worth of heart rate data fit's in one document. Example schema below.

data{
_id,
user_id:int,
attribute_name:string,
datapoints: [{index: int, timestamp: timestamp, datapoint: int, string, bool, float}, ... {index: int n, ...}],
datapointNo: int,
startTimeDate: timestamp,
endTimeDate: timestamp,
nextDocument: Null || _id
}

A simple data input page for manually tracked . Loosely basing the design language off of this mockup. the UI should automatically populate page based off a tracked datapoint list from the user profile in the user collection (assume "/api/data" route which is yet to be made). For the MVP, it can just track mood and a journal entry, but anything to make future development easier would be best.

Currently, the API and DB schema are written in a dumb way that would create unbounded arrays to hold data. Rewrite this so that there are separate collections that can hold default known data in a not dumb way, and then a generic attribute collection for custom user attributes

Create an api route, database connection, and register page.

To allow for arbitrary user data attributes, a datatype such as int and a category such as health should be added to user attributes. For reference, this would be the adapted user schema
User Document db/users
{
_id:int,
username:string,
email:string,
password_hash:string,
profile_image:binary,
roles:[
role1,
role2,
...
roleN
],
attributes[
{attribute_name: weight, datatype: float, category: health,
{attribute_name: running time, datatype:float, category: health},
...
custom attribute 1,
custom attribute 2
...
custom attribute n
],
settings[
...
],
disabled: bool,
...
}

Import wizard for CSV data. CSV's should only be expected to contain the "Data" column and "Timestamp" column. Should automatically convert time to the proper format. Timestamps with limited accuracy will default to values for the above timestamp accuracy, for instance, timestamps without seconds will be assumed to be on the first second of the minute, timestamps without hours will be assumed to have taken place at noon, timestamps without a day will be assumed to have taken place on the first of the month.

A page which gets and displays data trends over time. Should have user addable widgets. (hardcode for MVP?)

A user setting page that gets and displays user settings and allows them to be changed (might be able to hardcode specific settings?)

The dashboard page should include summaries of data (separate from raw data collection?) that would include many chart types including, bar, scatterplot, pie, and some simple datatypes like int, str, float, bool, etc, and display the last raw value (Current weight or previous journal entry for example)

There should be a small library of user selectable widgets that will display or collect data. For instance, a user can select a pie chart to show a months macros rather than a line chart which would show macros over time. Same data, just a different widget. Another example is data collection. If a datapoint is a particular category or datatype, the input should change and/or be user selectable. For instance, a journal widget for writing a few paragraphs, a short text box. int slider, etc. The widgets should also have a built in time selector for the previous week, month, year, and arbitrary.
Here is a starter list.
Data Display: bar, pie, line, comparison bar (multiple data points), comparison line (multiple lines), text, value, float, gauge (filling circles for example)
Data Capture: text box, large text box (example: journaling with multiple paragraphs), number slider, checkbox, yes/no slider, tag selector, emoji picker, color picker, radio button, button

Currently, only bearer tokens are implemented, which means that the user is regularly logged out. Refresh tokens should be implemented to automatically re-auth the user if the bearer token expires and the user is stilled logged in.

Users with non-unique emails will throw a 409 error, but will still allow registration and log in.