It was a work around to display a countdown since the CSS tweak for the stopwatch was no longer supported.
I only use Glide Tables.
I wont’ be able to run the app in production since it would lock automatically, even if I upgrade my subs.
Could anyone give me a way to fix this problem, and could Support reset my edit quota so I can fix the issue before my user testing?
A computed column, such as a math column, will not add to your edit count on it’s own. However, if a non-computed value in the data is changing, then that will count as an edit. Is the TimerStart value, or some other value, changing? Something must be changing in the data that would cause glide to see an edit. Edits should only be caused by a user doing something that will change data. Computed columns shouldn’t be contributing to that count.
It looks like only 3 tables were “modified” today.
So the edits happened in one of those 3 tables.
In those tables, only the columns that can be changed by a user initiated action would count.
So I can basically reject any computed columns such as Maths, rollup, lookup, template, if-then-else, relation…
Is that correct?
To me, that looks like a bug in the Glide’s quota computation except if one of my 2 users frenetically tapped on the favorite button last night. But how could I control that without a change log on the database?
Correct. Those computed columns shouldn’t be affecting anything as all computations happen directly on the user’s device, as opposed to the glide server.
Do you have any other apps in your team folder that are being actively used?
Is your app currently published?
Is there a chance that anyone else may have discovered the published url and started making edits within the app?
First check through this FAQ to make sure updates are counted as you would expect them to count.
If you still feel that there is a bug, then I would suggest submitting it to Glide support.
For information, while waiting for support’s feedback, I duplicated the project, moved it to a new team, published it, and I’m running the different user flows to identify which one is generating edits.
A bit cumbersome, but that may help others.
