Add bulk assign to saved object tagging

[alexfrancoeur]

Building off of #74571 and #79096, we'd like to add bulk actions for adding tags to existing saved objects. Members of our community can have hundreds if not thousands of visualizations and dashboards. Having a quick easy way to apply a tag to all saved objects will make this transition significantly easier.

There are some early flows from @MichaelMarcialis here:
https://www.figma.com/proto/kh7Gm1iM0zJPj504BeDQC4/Mockups-Version-3-Awaiting-Dev?node-id=445%3A0&viewport=13425%2C-7073%2C0.5&scaling=min-zoom

I'm thinking we may want this experience in the tag manager, but would like to open up the discussion. Here's the flow I'm envisioning:

• Click into a tag action "Assign"
• Open fly out with a similar experience as the add panel view in a dashboard that allows you to filter on supported types (in this case SO's that support tags)
• Filter by search / type, select appropriate tags via checkboxes
• Assign tag
• Repeat for another tag

This flow would of course adhere to RBAC permissions.

What do you think @MichaelMarcialis @ryankeairns @pgayvallet ? This would be really nice to augment the MVP PR for our initial release.

Tasks

• Add bulk assign from tag management - Add bulk assign action to tag management #84177
• Add bulk assign from SO management
• Add APIs to allow bulk assign from application listing pages

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[pgayvallet]

This is definitely something we want.

Still waiting on elastic/eui#4095 to be integrated to Kibana to be able to implement the design-compliant bulk action menu. @chandlerprall, can you tell us when the next EUI update is planned for Kibana?

Just a technical remark:

Open fly out with a similar experience as the add panel view in a dashboard that allows you to filter on supported types (in this case SO's that support tags)

The dashboard panel selector (that used the SavedObjectFinder component) is a single-selection widget. We probably gonna need a brand new component to allow multi-selection from this flyout.

Also,

The second, (complementary) option to this proposal would be to have a new bulk assign tag action available from the SO management section.

• select objects
• assign tags
• opens a modal/flyout
• select tags
• validate
• tags are assigned to the selected objects

@MichaelMarcialis I think we do, but could you confirm we got mockups for both worflows (and share them here to continue the discussion?)

[MichaelMarcialis]

@MichaelMarcialis I think we do, but could you confirm we got mockups for both worflows (and share them here to continue the discussion?)

@pgayvallet: We do have mockups and prototypes for assigning one or more tags to multiple saved objects on the saved objects page, as shown here: https://www.figma.com/proto/kh7Gm1iM0zJPj504BeDQC4/Mockups-Version-3-Awaiting-Dev?node-id=445%3A0&viewport=13425%2C-7073%2C0.5&scaling=min-zoom

I would like to expand this further by also providing a row-level action on the saved objects page table that allows users to assign one or more tags to a single saved object.

After that is implemented, I feel the next highest priority should be to incorporate those flows for assigning one or more tags to saved objects and apply the same interface to the Kibana applications' main pages. I think asking users to manage the meta details of their saved objects from the saved objects page makes sense in the short term, but longer term I believe users will wish to make such bulk tag assignments directly from the Kibana applications they are working within.

@alexfrancoeur, regarding your thoughts on having users go to the tag management page instead (to pick a tag they would like to assign to one or more saved objects), I agree that this could be a viable use case. However, I do worry that may end up being more of an edge case that comes secondary to users wishing to make such tag changes directly from the applications they're using. Thoughts?

[alexfrancoeur]

The second, (complementary) option to this proposal would be to have a new bulk assign tag action available from the SO management section.

++ and that's what was originally proposed in the mocks I believe. This is probably more of an edge case, but I could see potentially having write permissions for tag management and none for saved objects. That is why I was leaning to having one option for bulk tag assignment to be done through the tag management UI.

agree that this could be a viable use case. However, I do worry that may end up being more of an edge case that comes secondary to users wishing to make such tag changes directly from the applications they're using. Thoughts?

I agree that most users would prefer to assign from the application themselves. That was where my head was at with this comment #79096 (comment). I also think we probably want a more administrative way to do this as well. Both use cases seem valid to me. At this point, I'd lean towards whatever can ship with the first release if it's possible. My concern is that adoption (#81847) may not be as impactful with clusters that need this functionality most. I'm happy to iterate, but whatever can get us this type of functionality in MVP would be my preferred approach 😉 If that's from the SO management UI, that works for me. In which case, we simply lean into the app first route.

[MichaelMarcialis]

I'm happy to iterate, but whatever can get us this type of functionality in MVP would be my preferred approach

Yeah, good point. Once we know which direction we'd be able to implement first, let me know and I'll be happy to mock it up.

[pgayvallet]

This is probably more of an edge case, but I could see potentially having write permissions for tag management and none for saved objects. That is why I was leaning to having one option for bulk tag assignment to be done through the tag management UI.

You're right, this is probably an edge case, but I guess if we were to only have one initial way to assign tags, it probably makes more sense to do so from the tags management instead of SO management, so it is probably better to start with that. (even if we should be able to implement both for 7.11)

@MichaelMarcialis could you start working on mockups for this workflow then?

Bonus question to @alexfrancoeur: Do we want a bulk unassign tag action (in which case we gonna need the mockups for that too)

[MichaelMarcialis]

@MichaelMarcialis could you start working on mockups for this workflow then?

Yeah, I'll plan to work up some mockups for this.

[pgayvallet]

(extracted from #81980 (comment))

Regarding the bulk assign action:

A user can have write or read permission to SO tagging (therefor being allowed to assign tags), while still only having read permission to other SOs. That can make the bulk assign object-searching logic difficult, as we gonna want to only display objects the user has write permission to (else it will cause a permission error when trying to update the object to add the tag reference). I think that's kinda the first time we have this need to only return from a read operation objects that the active user has write permission to. @legrego @kobelb are you aware of any precedence for that? How should we achieve that ? We may be retrieve the list of SO type the user have write permission to and restrict the find operation to them? I don't think the SO permissions are directly accessible from core's Capabilities or the features plugin though, so how can I retrieve that? Another easy workaround would be to only display the bulk assign action if the user got SO management write permission, even if ideally, we would avoid such restriction.

(depending on previous point) the 'assign tag' permission is available for users having read permission to the SO tagging feature. These users should still be able to have the bulk action menu and should be able to bulk assign tags to objects they have write permission to right?

Note that this permission issue is only present for the bulk assign from the tag management section. From the SO section, we know that if the user got write permission to the SO management section, he got write permission to all types of SOs.