Why? List-View Editing Disabled OOTB for Reports [sys_report] Table

[JosephW1]

This question has arisen because I have many tasks where it would be very helpful if I enabled list-view editing for the Report [sys_report] table. By default, list-view editing is disabled on this table, though I have not been able to find any documentation on this restriction or why it was done.

QUESTION: What necessitated this list-view edit restriction on the Report [sys_report] table? As I'm sure there is a good reason, and I don't want to make more problems than I resolve by disabling this restriction.

As Adam Stout mentioned, the report table is loaded with dependent fields dependent on the report type, so building a report from the list could be quite complicated. Disabling it across-the-board would avoid the necessity of complex documentation/questions/answers on how to set/troubleshoot records users have modified via the list interface.

I get it that users could get lost/make a mess in the list view interface, but it is also capable as serving as a valuable config tool. I would think that a role-based list-view edit constraint could be beneficial for reports administration. That is, unless I'm overlooking something. That is precisely what I made this question to verify. And to figure out how to enable it, too, if appropriate.

Are there any other reasons that it is disabled?

 Thank you for your time!

 List-view edit example

[Chuck Tomasi]

If it's disabled by default, it's got to be for a good reason. I'm going to go out on an assumption on this one and say that sys_report has list-edit disabled because of the complexity of building a report. Not everything related to the report is directly accessed in sys_report. The report designer is the best way to create/update reports. List-editing can pose a risk to changing one thing and not a dependent item (automatically updated by the designer.)

FWIW, list editing is controlled by ACLs. There is an Operation field value for list_edit.

[JosephW1]

Thank you Chuck, I agree with the complexity argument - I also had that in mind -  but I still believe it is possibly widely true that those who administer reports can both benefit from and be trusted with the ability to list-edit their reports, so I am still considering pursuing this even though it is disabled OOTB. When editing minor aspects of multiple (20-100+) reports, list-view editing is so much more efficient than doing the same from the report editor and the hundreds of page loads that it would require.

I also see in the List Control for this table that list editing has been disabled. Simply toggling that value to "Save immediately (cell edit mode)" turned on list-view editing.

So, I guess the best method would be to combine this List Control on/off toggle with an ACL like you mentioned to enable list-view editing only for report_admins and admins.

Still, does anyone know of any documentation on why they made this decision?

[JosephW1]

To Enable List-View Editing:

In the List Control menu for the Reports [sys_report] table, change the List edit type setting to Save immediately (cell edit mode). Save the settings.

To Role-Constrain List-View Editing:

Enable list-view editing (above) and then reproduce the following ACL to restrict list-view editing on the Report [sys_report] table to admins and report_admins only.

[JosephW1]

To Enable List-View Editing:

In the List Control menu for the Reports [sys_report] table, change the List edit type setting to Save immediately (cell edit mode). Save the settings.

To Role-Constrain List-View Editing:

Enable list-view editing (above) and then reproduce the following ACL to restrict list-view editing on the Report [sys_report] table to admins and report_admins only. (Thank you @Chuck Tomasi)