[Epic] Sharing Modal Architecture [Slip to Next Q❓]

[tsullivan]

ℹ️ Context

In the Sharing Modal redesign work, we have lost the ability for applications to control their own sharing capabilities. Previously, applications could call share.register to add their own sharing items to the sharing menu, as seen in this screenshot from 8.13.

After the redesign, the Sharing plugin is "aware" of everything that needs to be presented in the modal, and controls the tab where things are placed and the order in which they are rendered.

The unfortunate effect of this:

• The demo list items registered by the share_example app are broken.
• New sharing capabilities that are registered can not be shown without updating the Share plugin.

This issue is to create an architecture for the registration of sharing items, so that the tab and the order in which things are placed is controlled by the application that registers the item.

🔭 Intent

We will explore the unquantified behavior of the API with the new Modal. We will show custom share plugins on a new tab of the modal, and allow them to be accessed by a click, same as they were on the old menu. We will demo this POC to design, and tidy from there.

🔎 Status & Risks

Has risk of being retargeted to a later release, due to conflicting priorities with 9.0 work.

💬 Discussion: #ux-spaces-and-roles

🗃️ Design Documents & Links

RFC: https://docs.google.com/document/d/1-EgHsNXeXfR9JcHCpZKCtGN9iWOC_SRrqphnDU7w_aU/edit?usp=sharing

---

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[petrklapka]

@tsullivan and @eokoneyo - This is on the planning board as an epic/KTLO for Q3. Can you give it a sizing estimate this week please?

[tsullivan]

@petrklapka @eokoneyo I put down 2-3 weeks for this, thinking that is how much time we need to make the Sharing plugin agnostic of how the registered content is rendered.

[tsullivan]

@petrklapka Something should be noted about the priority for this. It is probably a bit low, or maybe just vague. There is a chance that 3rd party plugins register custom content into the sharing modal, but we really don't know how much of that exists in the field. However, folks that depend on those plugins would be blocked from upgrading if they were affected by this issue.

We do need a way for plugin authors to register their content into the sharing modal, but for custom/3rd party content, let's not be too concerned with the aesthetics of the outcome.

[eokoneyo]

@petrklapka @eokoneyo I put down 2-3 weeks for this, thinking that is how much time we need to make the Sharing plugin agnostic of how the registered content is rendered.

I do agree 2-3 weeks might cut it, I'd love an extra week buffer especially that like you'd said @tsullivan we don't know what's out there in the field. @petrklapka do we also want to batch this alongside couple of other issues we've discovered that relates to the share modal?

[tsullivan]

cc @nickofthyme, I thought you might like to be aware of this since you are working on some improvements in this area.

[tsullivan]

Another, relatively more minor issue: we have lost the ability for sharing options to be agnostic of each other. Example: the CSV Download button in Lens currently has two configurations that are based on license type, to customize how it looks when it is the single option vs when there are multiple options.

It would be nice if the sharing modal architecture had the logic to show the export options correctly whether there is one registered option vs multiple. The registered options ideally wouldn't have to customize themselves based on the presence of other options.