Read-Only Views

I have been using Fibery as a database for concrete mix designs (a bit unique I know :grin:). I use a table view to input the data which is great, but my team has been using a board view with filters to compare various groups of designs. This latter use has no need to edit the data, only view it.

While the board view makes it very easy to set filters and see the ingredients in each mix design, it is also very easy to accidentally move an ingredient to the neighboring mix and mess things up. An ability to make a view read-only would fix my concern.

Maybe I am not using board view in the intended way or I am being too paranoid. A simple solution would be to limit my team members to read only access which would work, for now.

Have others seen a need for this or am I the only one? I could not find any other posts on this topic.

I think a toggle to lock a board would be rather handy. I’ve not faced THIS problem, but I’ve faced similar problems as Admin, where changes happen a little too easily

If users don’t need to edit data, then consider making them guests, or setting the permissions for the space containing the data to view only.

Note: a view can live in a different space than the database that it is displaying data from, so you can put the database in a read-only space, but provide a space with creator permissions to contain views which users need to be able to configure.

Moving the view to a different space is definitely a possibility. If I actually run into the issues I fear, then that will be my solution. Thanks!

A toggle lock would be helpful. I have seen that feature in other tools. It was not something I thought I would miss

Not sure if it’s still relevant, but there’s a solution of adding a Formula field to the database you are displaying as cards, and referencing the Status field. This will then become a read only column you can use to separate your board. This will then not allow users to move items around in the board. Is that what you mean?

I want Bob in the Marketing space. That doesn’t mean that I want Bob to have edit access to every view in the Marketing space. I’m amazed that such basic functionality is missing.

Creating additional spaces - one for views that Bob can edit and one for views that Bob can only view - is an ad hoc solution that creates redundant spaces and views, never mind that changes to one view’s configuration won’t be reflected in the other.

Locking is not a robust solution. A view can be unlocked by anyone with edit+ access.

I am a bit confused about the various needs that are threaded in this topic.

For example, with respect to this

setting filters is a view configuration (with permissions inherited from the space and shared with all other views in the space) whereas moving items within a board view is controlled by permissions on the entities being moved.

So what does it mean to ‘make a board view read-only’? Does it mean that a user cannot change the view settings (decide which fields to show, add sorting or color coding etc.) or does it mean restrict editing of any/all entities that are shown in the view?

Views get their configuration permissions from the space they live in, and unfortunately that’s not likely to change any time soon.

If Bob needs to configure some views but not all views, then either multiple spaces are needed, or the marketing space views can be not configurable for Bob, and when he wants a view that he can play with himself, he creates it in his own private space.

This is completely independent of whether or not Bob can make changes to the entities show in the views in the marketing space - perhaps he can, perhaps he can’t - that is down to database/entity permissions.

If the use case is preventing accidental edits to entities, then Ron’s suggestion of read-only fields isn’t bad, but this would be inconsistent with this

since Bob can always create another view in which the original editable fields are visible and make changes there.

TLDR I think the posts in this topic blur the lines between different use cases

I think perhaps what is being asked for is the ability to remove the default board drag-and-drop behaviour to prevent entity edits accidentally.

I know I’ve had this issue on mobile, and even the calendar view is notorious for this, where in trying to click on the entity, I often accidentally change the day it is on.

You can create a Custom App version of the view which does not allow editing.

I’m sure you’re right. I added my complaint in a thread with an applicable title. I don’t know whether OP’s case is exactly the same as mine. I’ll just create a new post in Ideas & Features access should be adjustable at the view level and not just the space level.