Disable add/edit/delete buttons when type is view

I agree, but maybe it would be better if this is configurable. I think there is a very valid workflow where (almost) all interfaces are in fact views, in which case most of the views would be editable.

Maybe this can become a validation? If a subject is a view and IoT is not present > get notified in validations.

Without getting information about the meaning of the view, the GUI could not know what to do. Right now the GUI keeps all options open.

I think it could derive meaning (on SQL Server) on the fact that there is an instead of (insert/update/delete) trigger in place. No instead of update trigger -> no edit button.
When an instead of trigger gets configured for the view, the apropriate button should become available.

Views that do not have multiple base tables do not require instead of triggers for inserts, updates and deletes. Because of this, the presence of instead of triggers cannot be used as a surefire way to determine if the view should be mutable.

Furthermore, trying to automatically enable/disable adding, editing and deleting for a view based on an instead of trigger being added or removed is problematic. Enabling inserts when an instead of insert trigger is added can be a little questionable. Disabling inserts when an instead of insert trigger is removed is simply wrong.

Creating warning validations to cover these situations is an option.

Vincent Doppenberg wrote:

Views that do not have multiple base tables do not require instead of triggers for inserts, updates and deletes. Because of this, the presence of instead of triggers cannot be used as a surefire way to determine if the view should be mutable.

Why would you have a view with one base table? That's a table variant, in my opinion. Furthermore, you could easily find out if the view has got multiple base tables, either by looking at the definition in the model (automatic views) or looking into the template that holds the select statement for the view.

Disabling inserts when an instead of insert trigger is removed is simply wrong.

Why? No means of actually inserting means by default, you should not be able to.

Why would you have a view with one base table? That's a table variant, in my opinion.

I'm not saying that there are many great reasons to do this, table variants were indeed introduced to greatly reduce the need to create views with one base table. Still though, there's nothing wrong with creating a view with a single base table, it's a feature that we have always supported. And if you think long enough, I'm sure it's possible to think of some edge cases where it's actually convenient to create a view over creating a table variant.

you could easily find out if the view has got multiple base tables, either by looking at the definition in the model (automatic views) or looking into the template that holds the select statement for the view

I wouldn't call parsing SQL code in templates to determine if a view has multiple base tables easy at all. It is deceivingly difficult to do this, especially when using SQL itself as your parsing language. To give the first example from the top of my head:



This view has one base table. And there are many conceivable examples that are much more difficult than this one.

Why? No means of actually inserting means by default, you should not be able to.

Because whenever someone does have a view with one base table, which, as we've established, is both supported and hard to detect, then removing an instead of insert trigger from that view does not at all mean that inserts should be disabled. We would then have created a feature that offers some minor convenience in some scenarios at the risk of straight up breaking others, however rare the latter may be.

Even views using multiple base tables can be updatable, as long as modifications only reference columns from one base table. More info here.

I'm convinced 🙂

I believe we get a bit sidetracked here, Remco intended when you create a view in the model the crud functionality is not enabled. And the developer has to enable the crud options to allow users to do something instead of the add button just being there without a intention of the developer to it beeing there.

So letting the SF decide something based on a trigger or such is not the question/idea. We see mostly that for views we in most cases we disable the crud options.

What I mean is indeed what Michael says. Wwhen you create a view that the sf disables by default the crud buttons. If the view will be used as editable the developer must turn the crud buttons manually on.

I agree with Remco. Most of the views I make are read-only and it would be great if that is reflected in a view's settings by default right after creation. From there if a view needs to be used for input then a developer can start creating necessary triggers and also further open up the view's rights.

That said, most of the views I make contain a template and I hardly ever use the auto option. For simpler views I resort to table variants because they don't require separate rights management the way views do making them easier to build and maintain. So perhaps we can make a distinction here: if a view is based on a template then make it read-only without crud buttons in its settings while auto views with a simple auto-generated 'from' statement (based on references) are editable and have crud buttons.

Updated idea status On the backlog → Planned

Updated idea status Planned → Working on it!

Updated idea status Next release → Completed