Disable add/edit/delete buttons when type is view
Software Factory
A view is by default not editable so it would be nice if the SF automatically disables the add/delete/edit/mass update and import buttons when you create a view. Now it is often forgotten to disable the buttons what results in errors if the user uses them.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
When an instead of trigger gets configured for the view, the apropriate button should become available.
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.
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.
Why? No means of actually inserting means by default, you should not be able to.
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.
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.
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.
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.
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 Working on it! → Next release
This functionality will become available in the 2021.2 version of the Thinkwise Platform.