I have a few columns that use Robert’s method of creating numbers from dates and using those to determine, for example, what line items were produced this month.
I’m using the Relationship by product name to lookup, then rollup in to an average daily output.
The issus is that the numbers don’t change… theh average is the same.
I went and had a look at the table, and the bottom half dozen rows are darker, while those above are slightly more faded. These faded items are the ones that were included in the original roll-up.
I’m not sure what the fading means, how to stop it and/or include the new data to get my dynamic rolling average up and running…
The fading means you are using Row Owners, so in the app, your computed columns will only be able to work with the data that’s owned by the signed in user.
Ah, thanks for the heads up on that. A manual refresh of Google Sheets sorted out the fading - they all have row owners. Unfortunately the problem still persists insomuch as no matter the user the data remains static. I’m a row owner on every item, but no change.
Is there something funky going on with the row owners only being able to transfer ‘so far’ along a relationship/lookup journey?
Sorry Jeff - I’m in the UK and it was … well either very late, or very early, depending on your sleep schedule!
I had a thought this morning which I checked - the issue is that the lookup columns mix data from different row owners. For example I’m pulling data from ‘this month’, that’s great, but as soon as there’s more that 1 row owner in that array then it throws its hands ups in horror. You can pull data from that mix according to row owner as much as you like, but if the lookup or relationship muddles any row owners together at any point, then from then onwards you’ll never be able to get back to Glide seeing it as ‘pure’ enough to display. I’m working on the assumption that the row owners are always defined by their email address - I have that in my head from somewhere: the email address in the user table is what constitutes a row owner.
I’m now stuck, unless I’m wrong, will every lookup and relationship I have needing to be made in a table that contains the row owners as its primary data source. If that’s not the case then please help me with my perspective!
Moving from spreadsheets to DB is still causing me a bit of mental blind spot - I can’t get used to only being able to look up one thing against one other thing - I’m so used to having access to more data without manipulating or formating it first.
First, I will say this. Don’t trust what you see in the data editor when row owners are involved. The data editor sees owned as well as unowned data, so relations, lookups, rollups, etc will use all of that data. In reality the forward facing app can only see and work with owned data.
A visual would be helpful here. I assume what you are explaining here is what I mentioned above, that the data editor incorrectly sees all rows regardless of row owners. I’m not sure so follow what’s happening when you say more than 1 row owners causes it to throw up it’s hands.
Relations, Lookups, Rollups don’t care about row owners. They only care about data that’s accessible. If data is unowned, then it’s non-existent as far as those computed columns are concerned.
What do you mean by this?
A column designated as a row owner column can contain either an email address or a role (when using true role functionality that’s been set up in your user profile configuration). For simplicity in this case, let’s just say yes, a row owner column must contain an email address. If the email in the row matches the email of the signed in user, then that row will be sent to the user’s device. On the user’s device, the computed columns take over and work with the data that is on that device.
Not sure I follow here. Like I said, lookups and relations work with data that’s accessible. If a table does not have row owners, then all data in that table is accessible. If a table does have row owners, then only the data that the user owns is accessible. Lookups and relations don’t care about row owners. They only work with the data they can see.