Every day, my customers will track their sleep, exercise and diet in a “habits” sheet.
I create a row for every day, then each user saves his habits as user specific datas.
This saves me a lot of rows
Then, I would like my dietician to acces those datas in an admin panel.
They would login, have the list of customers, and click to acces their data grid, including every user specific data (the one they just chose).
Actually I can’t access the data, can someone help me set this up?
If this is impossible as it is user specific data, can you help me do it without creating 1 row for each of my 100 customers each day? (3000/month, way too much)
User Specific Columns are just that. Columns that hold values that are specific to only one user. No user can see or access what another user entered into a user specific column…including whoever has been designated as the admin (dietitian). Glide will not even send that data to the user’s device if it’s not their own data.
With that said, what you are trying to do is not possible. You’ll probably need to restructure your data. So you’ll either have one row per user per day; or one row per day with all user data somehow aggregated into that row; or one row per user with all daily information somehow aggregated into that row. The last two methods would need some creative design populate and to parse out that data to make it viewable and useful in the app. The level of complexity to pull this off steps up quite a bit if you want to put all user data into a single row and still have it viewable in a nice way in the app.
Well, I don’t have an immediate answer. I think it would take a while to work out how to set it all up, and it would depend on a lot of things. For example, how many points of data are you looking to track each day? Most importantly, what are you looking to do with the data? Are you just viewing it for each day? Are you using it to calculate certain totals on a daily, monthly, quarterly, or yearly basis?
I guess I would focus more on having individual user rows and try to aggregate all of the daily data on each user row. This would eliminate any concurrency issues if multiple users are adding data at the same time. They would be updating their own row with daily information instead of a shared daily row with their information.
Now depending on what you want to ultimately do with the data, you could have a table with a single row full of user specific columns, where the user can enter their daily info. Then using a button, you could then package it all up into a single value using a template column. Then you could merge it with an existing column of prior daily input in their user row.
After that the tricky part is parsing it out in a way that’s useful to the dietician as well as each individual user. Like I said, it becomes quite involved and a lot more complex, all in an effort to save some rows. It’s definitely doable, but not simple.
Granted these are some very high level thoughts off the top of my head.
A simpler solution may be to use your existing setup with user specific columns updated in daily rows, but maybe aggregate some of the key totals into the user row. You could create comma delimited values in the user row that accumulate all of the daily values. Using that data, you could create something using quickchart.io to plot the data on a graph. Essentially your users will enter data normally, then press a button to set column values in the user table. You could build those values using joined list columns to create a comma delimited list of values for all days. Then the Set Column action will copy that joined list to a publicly viewable column in the user table. That may actually be a better solution, but again, it all depends on how you want to present the data to the dietician.
Could you group your User by week and have 7 days of date per week.
Rows get wide but you would cut down from 30 days to 4 or 5 weeks. 3000 to 400-500 is an 80% reduction.
The data editor makes it pretty easy to duplicate data and using data labels so you could see Mon/data1,2,3,4…, Tues/data1,2,3,4…, Wed/Data1,2,3,4… etc.
Your app would have to check which ‘Day’ to write data to but if your Dietician looks at weekly data then it might be easier for them to see a rows worth of data rather than using filtering. Plus you could do calculated columns pretty easily on a ‘weeks’ worth of data for your clients.
I think @MattLB has the most reasonable idea. One row per user per week with 7 sets of weekday columns. My idea is much more involved, and like I said, it largely depends on how the data would be used or viewed. I don’t really have a complete structure off the top of my head, but my idea was to append daily data into a single user row cell. Basically create a template that joins existing data and the new day’s data together, and then overwrite the column that contained the existing prior days data. So you would end up with a cell that contains a massive amount of data at the end of the year. Then through a lot of magic, you can convert it to arrays, and have a working table that will convert it to rows of data on the fly when you view an individual user’s data. Not for the faint of heart by any means.
