[Response Ops][Reporting] Scheduled Reports - List and Disable API#220922
[Response Ops][Reporting] Scheduled Reports - List and Disable API#220922ymao1 merged 142 commits intoelastic:scheduled-reportsfrom
Conversation
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
… src/core/server/integration_tests/ci_checks'
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
… src/core/server/integration_tests/ci_checks'
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
…heduled-reports-task
…heduled-reports-task
SiddharthMantri
left a comment
There was a problem hiding this comment.
One nit regarding the authz config for the new route.
| security: { | ||
| authz: { | ||
| enabled: false, | ||
| reason: 'This route is opted out from authorization', |
There was a problem hiding this comment.
Nit: Can this be expanded to better explain the reasoning for opting out?
| next_run: string | undefined; | ||
| notification: RawScheduledReport['notification']; | ||
| schedule: RruleSchedule; | ||
| title: RawScheduledReport['title']; |
There was a problem hiding this comment.
This title is extracted from the jobParams, right?
There was a problem hiding this comment.
Yes, it currently is but we could also make it an explicit field set in the schedule API if that is preferable.
There was a problem hiding this comment.
Oh no worries, I receive the title from the sharing data before creating the jobParams string so no need to specify it separately 🙂
|
I tried out Verify steps with user1 and user2 and everything worked as expected. However, when I use a job id from user2 while logged in with user1 and do a bulk disable, I get the following: {
"scheduled_report_ids": [],
"errors": [
{
"message": "Insufficient privileges to disable scheduled report \"c348b993-d106-482f-b538-3c9aee190a9f\".",
"status": 403,
"id": "c348b993-d106-482f-b538-3c9aee190a9f"
}
],
"total": 1
}I'm wondering if we should return a 404 instead? If we go that route, perhaps we can log the message we're currently generating as a WARN, since it's obviously useful info ... |
…heduled-reports-find
Updated in 6030bf0 |
pmuellr
left a comment
There was a problem hiding this comment.
LGTM, left some comments
|
|
||
| export function scheduledQueryFactory(reportingCore: ReportingCore): ScheduledQueryFactory { | ||
| return { | ||
| async list(req, res, user, page = 1, size = DEFAULT_SCHEDULED_REPORT_LIST_SIZE) { |
There was a problem hiding this comment.
Feels like we should put each route in a separate file, but perhaps we can plan on doing that when we add the next set of APIs (enable?)
There was a problem hiding this comment.
Sounds good. I was following what already existed for the jobs APIs but I guess we can start doing things the way we're used to in response ops now :)
| }); | ||
| } else { | ||
| // check if user is allowed to update this scheduled report | ||
| if (so.attributes.createdBy !== username && !canManageReporting) { |
There was a problem hiding this comment.
if username is false, presumably we'd always go through this if block, maybe we could exit early instead?
| // check if user is allowed to update this scheduled report | ||
| if (so.attributes.createdBy !== username && !canManageReporting) { | ||
| bulkErrors.push({ | ||
| message: `Insufficient privileges to disable scheduled report "${so.id}".`, |
There was a problem hiding this comment.
I think the intention with a 404 is to not leak the existance of resources the client doesn't have access to. So the message should probably be "not found". Having the logged warn is good though, since it's ok to "leak" that info in the logs.
There was a problem hiding this comment.
Is it considered a leak though? If we try to access a saved object that doesn't exist, we get a Saved object not found error that returns ${type}/${id} in the message. This only returns the ID that we're trying to disable, not any additional information about it.
There was a problem hiding this comment.
I think I understand what you're saying...I'll update the message to be a generic not found.
There was a problem hiding this comment.
Ya, I think my general experience with things is when you don't have access (haven't logged in), results tend to look like "I can't find that" - but not sure if we have guidelines about things like that ...
| page, | ||
| perPage: size, | ||
| ...(!canManageReporting | ||
| ? { filter: `scheduled_report.attributes.createdBy: "${username}"` } |
There was a problem hiding this comment.
username can be false, at least type-wise, so in such cases (API keys?), this would search for reports by false.
There was a problem hiding this comment.
Good catch! We actually prevent scheduling reports if security is disabled and api keys are not available because we need that API key for scheduled reports. I probably carried over that typing from the normal reports so I'll fix the typing.
There was a problem hiding this comment.
Fixed the types, added a double check that username is specified and added a functional test to ensure we're getting an error when scheduling reports with security disabled: 1f6abbb
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
cc @ymao1 |
Resolves #216313 ## Summary This is a feature branch that contains the following commits. Each individual linked PR contains a summary and verification instructions. * Schedule API - #219771 * Scheduled report task runner - #219770 * List and disable API - #220922 * Audit logging - #221846 * Send scheduled report emails - #220539 * Commit to check license - f5f9d9d * Update to list API response format - #224262 --------- Co-authored-by: Ersin Erdal <ersin.erdal@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Ersin Erdal <92688503+ersin-erdal@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com>
Resolves elastic#216313 ## Summary This is a feature branch that contains the following commits. Each individual linked PR contains a summary and verification instructions. * Schedule API - elastic#219771 * Scheduled report task runner - elastic#219770 * List and disable API - elastic#220922 * Audit logging - elastic#221846 * Send scheduled report emails - elastic#220539 * Commit to check license - elastic@f5f9d9d * Update to list API response format - elastic#224262 --------- Co-authored-by: Ersin Erdal <ersin.erdal@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Ersin Erdal <92688503+ersin-erdal@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com> (cherry picked from commit a409627) # Conflicts: # src/platform/packages/private/kbn-reporting/common/routes.ts # x-pack/platform/plugins/private/canvas/server/feature.test.ts # x-pack/platform/plugins/private/reporting/server/core.ts # x-pack/platform/plugins/private/reporting/server/features.ts # x-pack/platform/plugins/shared/features/server/__snapshots__/oss_features.test.ts.snap # x-pack/platform/test/api_integration/apis/features/features/features.ts # x-pack/test_serverless/api_integration/test_suites/chat/platform_security/authorization.ts # x-pack/test_serverless/api_integration/test_suites/observability/platform_security/authorization.ts # x-pack/test_serverless/api_integration/test_suites/search/platform_security/authorization.ts # x-pack/test_serverless/api_integration/test_suites/security/platform_security/authorization.ts

Towards #216313
Note
This PR will be merged into a feature branch
Summary
Adds internal APIs for listing and disabling scheduled reports. For this initial iteration, we are not adding an
enableAPI.This adds a
Manage Scheduled Reportsfeature privilege that, if the user has it, allows them to view and disable the scheduled reports of any user in the current space.To Verify
user1) with the ability to generate reports but not manage reports. Use the schedule API to schedule some reports as this user.user2) with the ability to manage reports. Use the schedule API to schedule some reports as this user.user1, use the Dev Console to list scheduled reports. You should only see those created byuser1.user1should also be able to disable their own reports.user2, use the Dev Console to list scheduled reports. You should see reports from bothuser1anduser2.user2should be able to disable a report created byuser1.