I can better control who access my releases and have a consistent interface to manage the people who can write

• Replace the current global FRS permission (Admin/None in "User permissions" matrix) by a service based definition of Read and Write (based on groups instead of users).
  • For WRITE (admins), during conversion a user group will be automatically created (probably re-use already placeholder file_manager_admins) for all existing projects to group all users that were "FRS admin".
  • For READ (consumers), during the conversion, we should take into account platform & project visibility. For instance in a public project all registererd users can access the FRS but in a private project it's only project_members. For "public incl. restricted", it's authenticated users by default.
• In FRS admin, there is a new section to define permissions for Read & Write (as for mediawiki)
  • By default, Read is granted to project_members
  • Write is granted to
    • "frs_administrators" for existing projects
    • for new projects, the group defined in the template project (if any, otherwise project_admins)

Special notes

• A special attention should be taken to not break all the elements that rely on FRS
  • Soap & CLI
  • REST
  • Webdav
• If relevant/possible during development, a dedicated table to store permissions should be used to avoid clutter the existing permissions table.