[UC] Sharing Access

[csarven]

As an author with authoring permission,
Guinan wants to use the sharing interface of her authoring tool to manage access permissions to her article,
so that Deanna can review, Seven of Nine can co-edit, and Torres can view the progress.

Preconditions:

What conditions must be in place or assumed before this use case can begin?

• Actors can identify themselves within the authoring tool using their personal online identities.
• Storage and hosting are set up for actors.
• The actors can receive notifications (e.g., [UC] Invitation #22 ).
• The actors have sufficient knowledge and understanding of their personal profiles, storage, notification management, access permissions, and use of authoring, publication, and annotation tools to achieve their goals.

Trigger:

What (user or system) event or action initiates this use case?

Guinan, as the "Owner" of her article, opens her address book from the authoring tool and selects Deanna, Seven of Nine, and Torres, assigning them "Commenter", "Editor", and "Viewer" permissions to the article respectively.

Actors:

Describe the primary actor, and any other relevant actors involved in this use case

Primary actor: Guinan, as an author with knowledge and experience in using an authoring tool to create and publish accessible content, is able to associate an inbox to the article to receive notifications about it (e.g., #7). She understands the distinctions between assigning different access permissions to individuals or making her article public. Guinan can select individuals from her address book and invite anyone not listed by entering their online identifier.

Distinction:

What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?

• Correctly assigning and managing different permission levels within the sharing interface, ensuring that each user receives the appropriate access without confusion.
• The system must efficiently handle updates to access permissions and determine whether changes should trigger notifications to the target users.

Scenario:

Describe an ideal or happy-case scenario where this use case would play out as intended.

Guinan logs into the authoring tool using her personal online identity. As the owner of her article - a technical specification - she authors the second draft (e.g., #7 ). She decides that it is time for some of her colleagues to have a look at the work so far. Using the sharing interface of her authoring tool, Guinan enters "Dea" in the input box, and the interface filters names that match. Guinan spots Deanna on the list, and selects her name, and assigns Deanna her "Commenter" access permission. When Seven of Nine last met with Guinan, she expressed interest in co-editing the article after reviewing the initial draft. So, Guinan updates Seven of Nine’s current "Viewer" permission and grants her "Editor" access instead. Finally, she remembers that Torres isn't in her address book yet, so she manually enter Torres' online identity, which she noted down on a napkin earlier that day. She assigns Torres "Viewer" permission. Afterward, Guinan sends a short notification to all three, explaining the current state of the work and thanking them for their time and contributions (e.g., #22 ). After this long day, Guinan takes a sip of her Earl Grey tea in the ship's lounge gazes at the stars.

Alternative case(s):

What alternative flows or variations should the system handle for this use case?

• If an actor has a higher-level permission (e.g., "Editor") for one article, the system could allow the same permission to be automatically granted across related articles within the same project. The system should check for this inheritance and provide an option to manually override.
• Guinan may want to revoke an actor's access after assigning it. The system should provide an intuitive way to remove access, ensuring that the actor receives a notification and the change is reflected immediately.
• If an actor already has permissions for the workspace (or "folder") containing the article, the system should automatically grant the same permission for the article, and this should be reflected in the application by default. It should also allow Guinan the option to override this setting.

Error scenario:

What unexpected issues or errors might arise, and how should the system handle them?

• Guinan intends to enter Torres' identifier https://torres.example.org/ but if she enters https://torrex.example.org/ that doesn't exist, the system should display an error message indicating the identifier is not found. If the identifier matches someone else, like https://torres.example.net/, the system should display the name and photo, for example, of the unintended actor to confirm the correct selection before proceeding.
• In scenarios where multiple owners attempt to modify permissions simultaneously, the system should inform the users of the conflict, or automatically resolve it, updating only the first successful change.
• If the server is taking a nap and can't process the access changes, it should let the application know about the specifics of the error so that the application can take the appropriate next steps ( e.g., Structured Error Messages solid/specification#28 , Add Inbox Discovery on Client Error solid/specification#253 (comment) )

Acceptance Criteria:

What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?

• The system should by default show the current access permissions for all actors to the owner of the article.
• The system should correctly (precisely) assign (or change) specified access permissions without errors.
• The system may automatically try to notify all actors in which their access permissions are changed.
• If an actor already has a higher-level permission for the workspace or related articles, the system should automatically inherit and reflect those permissions for the current article, with the option to override this behaviour.
• The system should handle conflicts when multiple owners are attempting to modify permissions, e.g., if the second owner can't correctly change the permissions, it should be informed as to what wasn't possible, and suggest possible actions from that point on.
• Handle server errors gracefully by providing detailed error messages to the application (e.g., [UC] Error Messages #34 ).

References:

List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.

• https://en.wikipedia.org/wiki/Access-control_list
• https://en.wikipedia.org/wiki/Word_processor

[hzbarcea]

This scenario refers the existence of a list or directory of other entities an author could share with. I think it's a good use case, the question is if this would be a 'core' lws use case or something that MUST be possible to layer on top.

[hzbarcea]

Similar to Access to stored health records.

[hzbarcea]

We may need to come up with a term for the entities an owner can share with. Would it be a good idea to user the term end-user?

[uvdsl]

I believe this may also be related to #27, Grant access to (business) data.

[renyuneyun]

I'm confused. How is this different from the normal access control?

Initially I thought this is to "share my permission to another person", but after reading it turned out to be different. The example says an "owner" "shares permission", but effectively it is "setting permission", which is exactly how currently access control in ACL functions.