Sharing Pane: Developers Notes for redesign (code in solid-ui now)

Wanted to document my findings and some ideas/notes on redesign work and how we could go about it, what we might be able to reuse etc.

Current Design Structure

Overview

Currently the sharingPane in solid-panes is only a wrapper for the function ACLControlBox5 this as well is basically a wrapper for the AccessControler. The groups such as Viewers, Editors, etc are defined and rendered by the AccessGroups render function. There is then the 'Add + Button' where you can select access recipients/agents. These are dragged/dropped onto the access groups and automatically saved.

Data

• The save happens in the Access controller here.

Set and Remove default permissions
The following are used for the buttons that appear at the bottom under the Add + button and/or the agent list. It's based on whether the using default acl flag is true or false. If true then you get the button to set the acl for the resource, if false you get the button to remove the acl for the resource.

• add ACLs which creates a specific ACL for the current resource by copying the inherited default ACL into the target ACL document.
• remove ACLs which deletes the custom ACL file for this resource and go back to inherited default sharing

Using the Add button

• add a new URI which adds this new agent as a Viewer, then saves the ACL. Not drag and drop.
• dropped handlers when the user drags and drops on a group.
• delete Agent which removes one existing recipient/agent from one specific access combo, then saves the ACL.

New Design Potential Structure

Based on the review of the current sharingPane implementation, it does not look practical to reuse the existing ACL code directly in a new dialog.

The main issue is that the current read/write ACL logic is tightly coupled to the existing UI classes in solid-ui, in the ACL UI components the access controller and access groups. Because of that, the current code is not structured as a reusable data layer that a new dialog could call cleanly.

The best path is likely to use the existing code as reference and extract a new ACL data module that handles loading, mutating, and saving permissions independently from the UI.

Potential Options

Keep the new dialog near sharingPane, extract the data layer into solid-ui

• Create the new dialog UI under the existing sharing area so it stays close to the current feature surface.
• Keep the current sharingPane in place as-is for now, or optionally move it into a legacy location later if we want to make the old implementation status more explicit.
• At the same time, build a reusable ACL data module in solid-ui.

Put both the new dialog and the data module in solid-ui

• place the dialog UI under the existing widgets area
• place the reusable ACL data module under the existing acl area

Futher acl permission api research

• solid-contrib there is just an archived solid-permissions and it says to use solid/acl-check which only checks the resource not read and write. Both are very old and solid-permissions is archived.