I think that client readable views would solve some problems we face, but I’ve always really struggled with the idea that the column on which a restriction is imposed is no longer included in the view.
For example, if I have a Form accessible by two users, one of whom has access to all rows, but one who has access to a restricted set of rows, I might still want to include the column on which the restriction was applied.
If I had a Comments table with a User link, I might want a regular user to only see their own comments, but an Admin to see all comments. A restricted view could achieve this, but then I couldn’t use the User link in any of my Forms since that would fall down when using a client_readable view (since the User column would be filtered out for non-admins). That’s unfortunate.
Is there a reason to exclude the column imposing the filter in the view? I think I’d be much more likely to use these if I knew all columns would be returned, with only the ROWS being restricted.
1 Like
I’ve also had examples where I’ve wanted to use a filter that would include several values (date greater than iirc) and wanted those to be available.
I suspect that the original ideas was to present the Client with the illusion that they had a Table all to themselves.
Plus, if the filtered column is a Link – a very common occurrence – that could open some security holes. Client code could follow the link to get to rows that perhaps it shouldn’t. By default, such access should be a deliberate act on the developer’s part, not an accident.
Yep. But I sometimes would like to make that deliberate act and can’t.
1 Like
I have good news for all of you - this restriction is no longer in force in Accelerated Tables! If you include an explicit q.only_cols(...) specifier in a view, then you can control the visible columns separately from the view conditions. (Accelerated Tables also permits view conditions such as “greater than” that do not restrict a view’s column availability by default.)
4 Likes