This PR includes several changes to the backend implementation, aimed at expanding what a User can personally do, and restructuring the database format to put several columns where they belong.
The /user/<username> page has been modified - it now gives a simple welcome message to the user's page, with the auth token now only being visible if you are logged in as the user owning the page. I'm sure that more backend methods will be needed for future user actions, but for now you've got access to the boolean @user_owns_profile which should be a good start to having user pages be more distinct between "This is my private page" and "This is someone else's public page".
Several table columns have been moved/changed to better match their purpose:
The fields relating to device specs have been moved out of Report and into Device.
Report no longer has user_id as a foreign key, instead having its device's UUID. It didn't make much sense that users owned devices AND users owned reports, but there was no real link between each report and device. Now, a User owns many Devices which individually own many Reports.
As part of these changes, the raw_data endpoint has been moved into the Device controller. I've changed the variable names to reflect this in the front end too and it seems to work fine but it's worth double checking.
New functionality exists to tag devices:
Each device has a tags field. This field is an array which may hold any number of user-defined tag strings. These may be used in future for users to group or label their devices. Tags are always ordered alphabetically.
The /add-tag/:device and /delete-tag/:device endpoints have been implemented. Sending a POST request to either of these endpoints (with :device substituted with the relevant device UUID) and the text body being the tag to add/remove. I'm open to changing this implementation to whichever style is easiest to work with from the front end - this one just seemed simplest to me.
Tags are considered private information - you must include your auth token in your request to add/remove tags, and they shouldn't be displayed to anyone except the user who owns the device.
The PR also cleans up an issue with database migrations in which it wasn't possible to roll back the User table being created.
This PR includes several changes to the backend implementation, aimed at expanding what a User can personally do, and restructuring the database format to put several columns where they belong.
/user/<username>page has been modified - it now gives a simple welcome message to the user's page, with the auth token now only being visible if you are logged in as the user owning the page. I'm sure that more backend methods will be needed for future user actions, but for now you've got access to the boolean@user_owns_profilewhich should be a good start to having user pages be more distinct between "This is my private page" and "This is someone else's public page".Several table columns have been moved/changed to better match their purpose:
Reportand intoDevice.Reportno longer hasuser_idas a foreign key, instead having its device's UUID. It didn't make much sense that users owned devices AND users owned reports, but there was no real link between each report and device. Now, aUserowns manyDeviceswhich individually own manyReports.raw_dataendpoint has been moved into the Device controller. I've changed the variable names to reflect this in the front end too and it seems to work fine but it's worth double checking.New functionality exists to tag devices:
tagsfield. This field is an array which may hold any number of user-defined tag strings. These may be used in future for users to group or label their devices. Tags are always ordered alphabetically./add-tag/:deviceand/delete-tag/:deviceendpoints have been implemented. Sending a POST request to either of these endpoints (with:devicesubstituted with the relevant device UUID) and the text body being the tag to add/remove. I'm open to changing this implementation to whichever style is easiest to work with from the front end - this one just seemed simplest to me.The PR also cleans up an issue with database migrations in which it wasn't possible to roll back the
Usertable being created.