Integrate centralized resource-sharing share button for monitors and workflows

[DarshitChanpura]

Description

Integrates the centralized share button from security-dashboards-plugin PR #2491 via its dependency-free DOM-marker SPI, surfacing per-monitor sharing directly in the monitors list.

How it works

• A Share column in the monitors table renders marker elements (data-resource-share-button + id/type attributes); the security dashboards plugin discovers them and mounts its centralized Share/Update Access button + modal
• Rows resolve their resource type per item: composite monitors map to the workflow type, all other monitors to monitor — matching the types registered by AlertingResourceSharingExtension in alerting#2180
• The column is gated on the core resourceSharing capability (enabled + type present in availableTypes), so it is completely absent when the security dashboards plugin is not installed, the feature is disabled, or the alerting backend does not yet contain #2180 — no dependency on the security plugin (no manifest changes, no imports)

Draft status

Blocked on two upstream merges: security-dashboards-plugin#2491 (provides the SPI + capability) and alerting#2180 (registers the types). Safe to merge before either — the column stays dormant until both are present.

Testing

• Compiled and loaded against OSD main + OpenSearch 3.8.0 with resource sharing enabled; column correctly absent while the backend lacks #2180
• Share flow semantics (modal, can_share graying, feature-off hiding) covered by the security-dashboards-plugin PR's unit/integration tests

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit badf579)

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to badf579

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Guard against non-string availableTypes value availableTypes is typed as string but may actually be an array or other type from capabilities. Coerce defensively to avoid a runtime TypeError when .split is called on a non-string value. public/services/services.ts [122-126] -const types: string = resourceSharing.availableTypes ?? ''; -return types - .split(',') - .map((type) => type.trim()) - .includes(resourceType); +const rawTypes = resourceSharing.availableTypes ?? ''; +const types: string[] = Array.isArray(rawTypes) + ? rawTypes + : String(rawTypes).split(','); +return types.map((type) => String(type).trim()).includes(resourceType); Suggestion importance[1-10]: 5 __ Why: The suggestion adds defensive coercion for availableTypes in case it's not a string, which is a reasonable robustness improvement given capabilities data could vary. However, the impact is minor as the current code likely works with the expected string format.	Low

---

Previous suggestions

Suggestions up to commit 5cf9fb4

Category	Suggestion	Impact
General	Include workflow type in column availability check The outer guard only checks MONITOR_RESOURCE_TYPE, so if only workflow is available (but not monitor), the Access column will not be rendered at all and workflow rows will lose the share button. Include the workflow type in the outer availability check as well. public/pages/Monitors/containers/Monitors/Monitors.js [132-147] -...(isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) +...(isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) || +isResourceSharingAvailable(ALERTING_WORKFLOW_RESOURCE_TYPE) ? [ { - // Resource-sharing SPI marker column: the centralized Share - // button is mounted here by security-dashboards-plugin when - // installed and resource sharing is enabled for monitors. field: 'id', name: 'Access', sortable: false, width: '120px', render: (id, item) => { const resourceType = item.monitor?.type === 'workflow' ? ALERTING_WORKFLOW_RESOURCE_TYPE : MONITOR_RESOURCE_TYPE; return isResourceSharingAvailable(resourceType) ? ( Suggestion importance[1-10]: 7 __ Why: Valid observation: if only workflow is available but not monitor, the Access column is omitted entirely, causing workflow rows to lose their share button. Including both types in the outer check improves correctness.	Medium
Possible issue	Trim entries when parsing available types The availableTypes string may contain whitespace between entries (e.g. "monitor, workflow"), which would cause split(',').includes(...) to miss matches. Trim each entry before comparison to make the check robust. Also guard against non-string values. public/services/services.ts [122-123] -const types: string = resourceSharing.availableTypes ?? ''; -return types.split(',').includes(resourceType); +const types: string = typeof resourceSharing.availableTypes === 'string' ? resourceSharing.availableTypes : ''; +return types.split(',').map((t) => t.trim()).includes(resourceType); Suggestion importance[1-10]: 5 __ Why: Trimming whitespace when splitting availableTypes adds robustness against formatting variations, though the current tests and expected format use comma-separated values without spaces. It's a reasonable defensive improvement.	Low

Suggestions up to commit 5cf9fb4

Category	Suggestion	Impact
Possible issue	Include workflow type in column guard The outer guard only checks MONITOR_RESOURCE_TYPE, so the Access column is hidden entirely when only workflow sharing is enabled, preventing workflow rows from rendering their share button. Include the workflow type in the outer availability check as well. public/pages/Monitors/containers/Monitors/Monitors.js [132-146] -...(isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) +...(isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) || +isResourceSharingAvailable(ALERTING_WORKFLOW_RESOURCE_TYPE) ? [ { - // Resource-sharing SPI marker column: the centralized Share - // button is mounted here by security-dashboards-plugin when - // installed and resource sharing is enabled for monitors. field: 'id', name: 'Access', sortable: false, width: '120px', render: (id, item) => { const resourceType = item.monitor?.type === 'workflow' ? ALERTING_WORKFLOW_RESOURCE_TYPE : MONITOR_RESOURCE_TYPE; Suggestion importance[1-10]: 7 __ Why: Valid concern: if only workflow resource sharing is enabled (not monitor), the Access column would be hidden entirely, preventing workflow rows from displaying the share button. This is a legitimate edge case.	Medium
General	Robustly parse availableTypes capability value availableTypes may be provided as an array by the security plugin, or contain whitespace around comma-separated values. Handle both array and string forms and trim entries to avoid false negatives when matching the resource type. public/services/services.ts [122-123] -const types: string = resourceSharing.availableTypes ?? ''; -return types.split(',').includes(resourceType); +const rawTypes = resourceSharing.availableTypes ?? ''; +const types: string[] = Array.isArray(rawTypes) + ? rawTypes.map((t: string) => String(t).trim()) + : String(rawTypes).split(',').map((t) => t.trim()); +return types.includes(resourceType); Suggestion importance[1-10]: 4 __ Why: The suggestion adds defensive parsing for availableTypes, but the actual format is defined by the security plugin and appears to be a comma-separated string based on the tests. The improvement is speculative but adds mild robustness.	Low

Suggestions up to commit 5464ef8

Category	Suggestion	Impact
General	Include column when either type available The outer column is only included when isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) is true, so workflow rows will be hidden entirely when only the workflow type is registered. Include the column when either resource type is available so mixed lists render properly. public/pages/Monitors/containers/Monitors/Monitors.js [132] -render: (id, item) => { - const resourceType = - item.monitor?.type === 'workflow' - ? ALERTING_WORKFLOW_RESOURCE_TYPE - : MONITOR_RESOURCE_TYPE; - return isResourceSharingAvailable(resourceType) ? ( +...(isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) || +isResourceSharingAvailable(ALERTING_WORKFLOW_RESOURCE_TYPE) + ? [ Suggestion importance[1-10]: 7 __ Why: Valid observation: if only the workflow resource type is registered, the Access column is entirely omitted, hiding workflow share buttons. Including the column when either type is available improves correctness for mixed lists.	Medium
Possible issue	Handle array or string capability shape The availableTypes capability may be provided as an array rather than a comma-separated string, and even when it is a string, entries could contain surrounding whitespace. Handle both shapes and trim entries to avoid false negatives when checking registration. public/services/services.ts [122-123] -const types: string = resourceSharing.availableTypes ?? ''; -return types.split(',').includes(resourceType); +const rawTypes = resourceSharing.availableTypes ?? ''; +const types: string[] = Array.isArray(rawTypes) + ? rawTypes + : String(rawTypes).split(','); +return types.map((t) => String(t).trim()).includes(resourceType); Suggestion importance[1-10]: 4 __ Why: The suggestion is speculative about the shape of availableTypes, but adding robustness (trimming and array handling) could prevent subtle bugs if the capability format changes or contains whitespace.	Low

Suggestions up to commit 7d344be

Category	Suggestion	Impact
General	Include workflow type in column gate The outer gate only checks MONITOR_RESOURCE_TYPE, so the Access column is hidden entirely when only workflow sharing is available, even though workflow rows would otherwise render a share button. Gate the column on either type being available so workflow-only environments still get the column. public/pages/Monitors/containers/Monitors/Monitors.js [132-147] -...(isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) +...((isResourceSharingAvailable(MONITOR_RESOURCE_TYPE) || + isResourceSharingAvailable(ALERTING_WORKFLOW_RESOURCE_TYPE)) ? [ { - // Resource-sharing SPI marker column: the centralized Share - // button is mounted here by security-dashboards-plugin when - // installed and resource sharing is enabled for monitors. field: 'id', name: 'Access', sortable: false, width: '50px', render: (id, item) => { const resourceType = item.monitor?.type === 'workflow' ? ALERTING_WORKFLOW_RESOURCE_TYPE : MONITOR_RESOURCE_TYPE; return isResourceSharingAvailable(resourceType) ? ( Suggestion importance[1-10]: 7 __ Why: Valid catch: the outer gate only checks MONITOR_RESOURCE_TYPE, so workflow-only sharing environments would miss the Access column entirely, which is a real functional gap. Human: </details></details></td><td align=center>Medium </td></tr><tr><td rowspan=1>Possible issue</td> <td> <details><summary>Handle array/string availableTypes robustly</summary> ___ **The <code>availableTypes</code> capability may be provided as an array rather than a <br>comma-separated string, and the current code assumes a string only. Coerce/handle <br>both shapes and trim whitespace to avoid false negatives when the type is registered <br>but formatting differs.** [public/services/services.ts [122-123]](https://github.com/opensearch-project/alerting-dashboards-plugin/pull/1496/files#diff-a6162938b9d34232fd7d02eff01760bbcdb939a751afbce8a6824da89096b071R122-R123) ```diff -const types: string = resourceSharing.availableTypes ?? ''; -return types.split(',').includes(resourceType); +const rawTypes = resourceSharing.availableTypes ?? ''; +const types: string[] = Array.isArray(rawTypes) + ? rawTypes + : String(rawTypes).split(','); +return types.map((t) => t.trim()).includes(resourceType); Suggestion importance[1-10]: 5 __ Why: Reasonable defensive coding since the availableTypes capability shape isn't strictly defined here, but it's speculative without confirmation of the actual API contract.	Low

[github-actions]

Persistent review updated to latest commit 5464ef8

[DarshitChanpura]

[github-actions]

Persistent review updated to latest commit 5cf9fb4

[github-actions]

Persistent review updated to latest commit 5cf9fb4

[riysaxen-amzn]

Nice clean approach — the dependency-free DOM-marker SPI with capability gating keeps this plugin decoupled from security-dashboards-plugin, and the availability helper + column tests are appreciated. A few items, one blocking:

1. Blocking: workflow resource type no longer matches alerting#2180

public/services/services.ts:

export const ALERTING_WORKFLOW_RESOURCE_TYPE = 'workflow';

alerting#2180 renamed the registered workflow type to alerting-workflow (commit 5798725f, "Rename workflow RSC resource type to alerting-workflow to avoid flow-framework collision") — see ResourceSharingUtils.WORKFLOW_RESOURCE_TYPE on that branch. As written here, composite monitor rows emit data-resource-type="workflow", which in the shared registry is flow-framework's type:

• isResourceSharingAvailable('workflow') checks the wrong type's availability
• the mounted share modal would resolve sharing entries against the wrong resource registry

The constant is even named ALERTING_WORKFLOW_..., so I suspect the value just predates the rename. The unit test in Monitors.test.js asserts 'workflow' too, so it cements the drift rather than catching it. Fix: value → 'alerting-workflow' in the constant, the test expectation, and the availableTypes fixtures.

2. Question: composite detection via item.monitor?.type === 'workflow'

Can you confirm this matches how the monitors list actually represents workflows? Other parts of this codebase distinguish via monitor_type / workflow_type fields. If composite list items don't carry monitor.type === 'workflow', they'd silently fall through to the monitor type and share against the wrong registry entry.

3. Question: MDS (multi-data-source) interaction

The monitors listed can come from a remote data source, but the resourceSharing capability and the mounted share modal come from the local cluster's security plugin. Sharing a remote monitor's ID against the local sharing registry seems wrong (or at best a no-op against a nonexistent resource). Should the column be gated on the local cluster being the active data source (e.g. !getDataSourceId()), or does the centralized button handle dataSourceId?

4. Minor: column gate asymmetry

The Access column only renders when isResourceSharingAvailable(MONITOR_RESOURCE_TYPE). If only the workflow type were in protected_types, workflow rows would get no share column at all. Cheap fix: gate the column on monitor or workflow availability — the per-row check already handles the rest.

Nits

• Column header says "Access" while the description calls it a Share column — pick one for consistency.
• width: '120px' is generous for data-resource-share-display="icon".

(CI note: the unit-test failures are unrelated infra — the job dies with bash: yarn: command not found after the nvm Node 22.23.2 install, before any tests run.)

[DarshitChanpura]

Thanks for the review suggestions. Addressed in badf579:

1. Include the workflow type in the Access column availability check — done. The outer guard now renders the column when either MONITOR_RESOURCE_TYPE or ALERTING_WORKFLOW_RESOURCE_TYPE is shareable, so composite (workflow) monitor rows keep their share button even when only the workflow type is enabled. Per-row gating still selects the correct resource type for each row. Added a renders the Access column when only the workflow type is available test.

2. Fragile availableTypes parsing — added .map(t => t.trim()) so values like "monitor, workflow" resolve correctly, with a whitespace-tolerant test. I left out the array-handling branch: availableTypes is produced by the security plugin's SPI capability as a comma-separated string, so the array form can't occur by design and defending against it would add dead code.

[github-actions]

Persistent review updated to latest commit badf579