Are you, @Stefan_Huber , sure this is not caused by a filter? If so, it has always been like this.
When I open a modal on a filtered table, I can scroll through the records (rows) that pass the filter. If I open a modal on an unfiltered table, I can scroll through all the records.
When opening a modal from a (filtered) subtable, the filter doesn’t work at all and I can still scroll through all the records.
It’s because of the filter - maybe I am mistaken, but I remember a student a year ago that showed me that he was able to switch between all filtered rows in detail view by using the arrows - despite having set the filter. (filter worked in table view - then student clicked on the avatar enabling him to go in a row that was filtered in the table view and then in detailview the filter no longer applied)
This is a deal breaker for many of us, does Coda care about this?
Not sure why this has never been addressed.
This is really a shocking security breach - and it sounds like something they should be able to fix really easily.
This is NOT a security breach, let’s stop the nonsense with “security breach“. Once a doc is shared with someone, they can see anything in that doc. In Google Docs one can see their collaborators activity, what was changed by who was changed and when it was changed.
What it is… maybe an annoyance of many including myself that at least at a visual level, the collab activity cannot be turned of to at least not see it on top right, not theat you canoot see their activity overall.
Google Docs doesn’t have User() filters or hidden pages. Coda does.
Coda provides User() filters, hidden pages, locked tables, and page locking to restrict access. Having a sloppily implemented UI element that bypasses all of them with a click is indeed a security issue.
You can click an avatar and access content that Coda’s own access control features are supposed to prevent you from seeing. Either that’s a security breach or those features are misleading users about what they actually protect.
User() formula isn’t intended to provide “security” but rather to help you the maker to filter for a specific user related items while still at a fundamental level (doc level) everyone can still see everything.
Whenever you open a doc, over the time you will have the doc downloaded locally, items inside a doc aren’t delivered “on demand/need to know” basis with user() acting as a gate for the specific content.
Same with Hidden Pages, NOT a security feature, locked tables/pages aren’t a security feature but UX enhancers so that one doesn’t ends up page modifying structure via “fat fingers” episodes.