Have Reporting use the Saved Object Client abstraction

[stacey-gammon]

I was thinking about the ability delete reports feature recently. Reporting uses it's own separate code to interact with reports (currently lacking the delete feature). Does it make sense to extend the Saved Object Client service to support other indices or index patterns so we aren't rewriting all the basic object functionality (get/find/delete/create, etc) ?

Some questions I have:

• The saved object client is space aware but reports are not. Could the saved object client be instantiated to conditionally not be space aware?
• Reporting has some special security logic to make them per user, while currently saved objects do not. What will Reporting look like in the RBAC world? If report objects used the same Saved Object Client interface, I imagine they might be able to take advantage of some RBAC features - for instance sharing report objects with other users.

cc @elastic/kibana-operations, @tylersmalley, @kobelb, cc @archanid

[kobelb]

Speaking from the security perspective, it'd make our life easier the more things that can be secured using the same SavedObjectClient interface, so extending it to work with different indices seems like a logical step in the right direction.

[fbaligand]

I’m interested by this feature as it enables to remove a report from Kibana UI.

[tsullivan]

What will Reporting look like in the RBAC world?

@stacey-gammon @kobelb I'm genuinely interested in this. Can we throw down some ideas?

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[YashMangla]

In Kibana, reports are stored under the default index and the pattern is following by .reporting-<yyyy.mm.dd> format.
One can delete reports from kibana followed by below command
DELETE .reporting-<yyyy.mm.dd>
eg.
DELETE .reporting-2019.12.01

[fbaligand]

Well, indeed.
But that’s not very user friendly, particularly for a business user.

[tsullivan]

We have de-coupled this issue from the requirement to be able to delete reports, and controls to delete reports exist now in the Management > Reports listing.

As far as migrating Reporting's data source to use the saved object abstraction, there are pros and cons.

A pro is that we would be able to implement migrations in the same way other plugins.

A con is that there isn't an easy migration to move from non-saved objects into saved objects. The work required there seems to outweigh the benefits, since Reporting doesn't have a real need for migrations right now.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[tsullivan]

I am considering closing this issue, since we don't seem to have a need for it. Even with keeping Reporting index as it is, Elasticsearch will be able to treat it as a system index and perhaps even have built in retention policies.

[legrego]

Ignoring the amount of work it would take to get here (and the current limitations of SO migrations), moving to saved objects would give you quite a few benefits for "free" (or nearly free), including:

1. Space aware reporting jobs (optional, they don't have to be)
2. User specific reports once Object level security, Phase 1 #86013 is resolved (you have this already, but it would remove the custom code you currently have to maintain)
3. Audit Logging capabilities ("Who created a report, and when?")
4. Support for Feature Controls ([Reporting] use new application privileges model for reporting’s security perms  #19914). This eliminates the need for the custom reporting_user role, which ends up resolving a few open issues for you: Automated Reporting triggered using Apikey because authorization fails #76210, Switch over to using API Keys for reporting (many open questions) #76964, https://github.com/elastic/kibana-team/issues/1331. It also partially unblocks [Reporting] Scheduled Reports #79905 if I understand the requirements correctly.

[tsullivan]

I am going to close this because we have a long-term vision of Reporting that doesn't depend on historical reports being first-class Saved Objects in Kibana.

Using Saved Objects provides in most cases. They provide:

• built-in security and management
• built-in migrations
• capability for import/export

None of these features give a lot of benefit to Reporting:

• It has internal implementations for security and management
• Migrations has not been an issue in the past or foreseeable future
• There is no use case for importing reports. Exporting reports is done by downloading the report.