[Saved Object Aggregation View] Use namespace registry to add tenant filter

[cwperks]

Signed-off-by: Craig Perkins cwperx@amazon.com

Description

Corresponding PR in OSD: opensearch-project/OpenSearch-Dashboards#2656

This PR uses the new namespace filter to add a tenant filter on the Saved Objects screen of OSD if the saved object aggregation view flag is enabled.

This PR also addresses logic on the typeToNamespacesMap to only include type for config when all namespaces are requested or the current tenant is in the list of requested namespaces.

Opening this as a Draft until corresponding PR is merged.

Category

[Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation]

Enhancement

Why these changes are required?

What is the old behavior before changes and new behavior after changes?

Issues Resolved

The first milestone of opensearch-project/security#1869.

Testing

Manual UI testing with many scenarios:

1. Aggregation view enabled
2. Aggregation view disabled
3. Aggregation view disabled -> Aggregation view enabled -> Aggregation view disabled
4. Tested without security plugin

Unit Tests

Check List

• New functionality includes testing
• New functionality has been documented
• 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.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[cwperks]

This will always include default in the dropdown. default comes into play when OSD deployments with existing saved objects enable the saved object aggregation view feature. These objects do not have the namespace of the saved object populated and will be given the default (or null) namespace.

[codecov-commenter]

Codecov Report

Merging #1169 (e946d2f) into main (f815e3c) will decrease coverage by 0.02%.
The diff coverage is 68.75%.

@@            Coverage Diff             @@
##             main    #1169      +/-   ##
==========================================
- Coverage   71.80%   71.78%   -0.03%     
==========================================
  Files          88       88              
  Lines        2011     2027      +16     
  Branches      265      274       +9     
==========================================
+ Hits         1444     1455      +11     
- Misses        505      509       +4     
- Partials       62       63       +1     

Impacted Files	Coverage Δ
public/plugin.ts	13.11% <20.00%> (+0.61%)	⬆️
public/apps/configuration/utils/tenant-utils.tsx	70.88% <90.90%> (+3.23%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[cliu123]

@cwperks Is this ready for review?

[cwperks]

@cliu123 This is ready for review now that the companion PR is merged.

[cwperks]

@cliu123 I noticed when testing this change that the following data structure comes out as:

{
    "global_tenant": true,
    "admin_tenant": true,
    "admin": true
}

Will the values in this map of tenants ever contain false? If so, should this skip over the tenants where the value in this object is false?

[cliu123]

@cwperks You might have logged in as admin, then you are expected to have all tenant permissions. If you create a role, grant permission to a specific tenant, create a user, map the role to the user, and log in as the user, then you'll see the difference.

[cliu123]

@cwperks The changes in saved_objects_wrapper.ts would break the aggregation functionality. With the changes, the Saved Objects table no longer aggregates object from all namespaces. Please consider the following changes:

      if ('namespaces' in options && !options.namespaces) {
        // Requests coming from "Index Patterns" table have "namespaces: undefined" in the options.
        _.assign(options, { namespaces: availableTenantNames });
      }  else {
        // Requests coming from "Save Objects" table do not have namespaces in the options.
        // Move the logic with `typeToNamespacesMap` to here.
        const typeToNamespacesMap: any = {};
        ...
        ...
      }

[cwperks]

@cliu123 I updated this to:

if (options.namespaces !== undefined) {
  const typeToNamespacesMap: any = {};
  ...

  options.typeToNamespacesMap = new Map(Object.entries(typeToNamespacesMap));
  options.type = '';
  options.namespaces = [];
} else {
  options.namespaces = [namespaceValue];
}

The else in this clause scopes the request not explicitly containing namespaces to use the current namespace (tenant). This is similar to what you have above, but just includes the current namespace.

[cliu123]

@cwperks With the changes in this PR, the Saved Object table does not aggregate saved objects. It only shows the saved objects in the selected tenant.

[cwperks]

@cliu123 This PR in OSD Core needs to be merged first: opensearch-project/OpenSearch-Dashboards#2696

The old behavior would send an empty array to signal to the saved_objects_wrapper that it should include all namespaces, but this was inconsistent with the behavior expected of the find API. Since this PR will register namespaces with the new extension point in OSD core, OSD core will ship either all registered namespaces or the list of requested namespaces (if the filter is selected or search text includes namespaces) with each request to find.

This PR has been updated to treat lack of namespaces (undefined, null or empty array of options.namespaces) as a request without namespaces and will only perform the request for the current tenant.

This will help with the issue of determining which page a request comes from. Since this change targets the Saved Objects screen we will expect that requests from that page will provide namespaces and similar find requests coming from other pages will not have namespaces in the request.

[cliu123]

Removing the backport labels for now and will add them back after backporting #1146

[cliu123]

@cwperks UTs and ITs failed. Could you please check?

[cwperks]

@cliu123 re-ran UT and IT and they are passing now. The failures were on flaky tests.

[cliu123]

Let's hold off the merge on this PR till merging the other one moving the utils. There could be some conflicts that need to be resolved on this one.