Description

User Stories

• As a user I want to share with external people using their email addresses to collaborate with them.

Value

• enable worldwide collaboration
• meet compliance requirements
• controll which email adresses have access

Acceptance Criteria

• A good name for the exists (@tbsbdr)
• Users can share with external email addresses
  • Sharing with external users is resticted to users with the appropriate rights
  • It is possible to share with one or many email adresses at once (eg. comma separated)
  • available roles are at least:
    • can view
    • can edit
    • nice to have "secret file drop", "secure view" etc.
• the email adress gets a mail with a link
  • That link is a one-time link giving direct access to the shared resource. It needs to be used within a configurable time (e.g 30min)
  • If the link has already been used, or is expired, the system sends out an email with a new link, that gives direct access to the shared resource. The email also contains a one-time PIN that can be entered to access the resource.
  • click on the link grants access to the resource for eg. 24h (can be configured via config variable)
  • if 24h are exceeded, click on the link sends a new mail with a valid link
  • the link expires after 30 days (the default expiration date can be adjusted via config variable and is enforced by default) Configurable default maxium exipriation time for public links and "magiclinks" #2515
• external email addresses can access files only via the web ui (no desktop or mobile clients)
• if an email address has access to multiple links, these links are accessible within the current session
• Admins can list all external email addresses who have access to active (non-expired) links
  • Admins can remove any email adress from accessing existing links
• while editing in apps like collabora, the email address is visible as username
• logging contains the email address and is reflected in the end-user ui

(detailed email flows, ui representation, mail honeypot etc. needs to be refindes as well)

Definition of ready

• Everybody needs to understand the value written in the user story
• Acceptance criteria have to be defined
• All dependencies of the user story need to be identified
• Feature should be seen from an end user perspective
• Story has to be estimated
• Story points need to be less than 20

Definition of done

• Functional requirements
  • Functionality described in the user story works
  • Acceptance criteria are fulfilled
• Quality
  • Code review happened
  • CI is green (that includes new and existing automated tests)
  • Critical code received unit tests by the developer
• Non-functional requirements
  • No sonar cloud issues
• Configuration changes
  • The next branch of the OpenCloud charts is compatible