Update Multi-Stakeholder Management Permissions to Match DAODAO Behavior

[S4mmyb]

The current design creates a permission dependency where:

• Org Editors automatically get edit permissions on ALL projects
• Project Admins cannot remove Org Editors from their projects

The issue with this is that each organization and project is instantiated as a DAO, people can technically add or remove editors at the project level without going through our UI. This creates a mismatch UI accurately reflects the underlying permission model and could result in conflicts between the Regen App and DAODAO contract, and eventual interface.

Some thoughts on how to address this:

Project Member Management for Existing Projects

Behavior:

• Project roles should be managed at the project level, not inherited from org level
• Project Admins should be able to add/remove any members from any org
• When creating a new org and migrating over projects, the org admin should be added as a project admin for all their projects (this doesn't require any changes to our UI, just something to note)

Changes Needed:

• Remove the "organization member settings" restriction shown in the current UI
• Replace the locked dropdown that says roles must be changed at org level
• Make all role dropdowns editable for Project Admins

Potential Additions Needed:

• Potentially add a tooltip to the Org member view indicating that Org Editors aren't necessarily guaranteed access to all projects.
• Add a safeguard for removing project admins. This is an edge case I don't think we designed for, but if there is only one admin they shouldn't be able to remove themselves as the Project needs to have at least one member with admin permissions. This should be the same for orgs.

Creation of New Off-Chain Projects

Behavior:

• Org Admins/Editors have the ability to create new projects on behalf of the org (no changes needed, just the behavior).
• All off-chain projects are editable for org admins/editors

Creation of New On-Chain Projects

Behavior:

• On-Chain Projects: When a new project is created an issuer, they should to it through the UI if they want to have support for the multi-stakeholder management. As such, they are responsible for adding other admins from the appropriate orgs until we develop new features to support this (below in potential additions).

Note: The issuer must add org admins as project admins if we want to support that org admin in automatically adding new org editors to have access to edit projects (see edge case below).

Changes Needed:

• (Backend) Since the create-project msg automatically designates the issuer as the admin we will need to have to sign two transactions. The first to create the project, the second will instantiate with them as an Admin.

Potential Additions:

• On the "Create New Project" flow for on-chain projects, add a step to add members or an org (depending on how we do this it could create edge cases.

Display of Project on Org Profiles

Behavior:

• Projects should appear on an org's public profile if ANY org member has a role (Admin, Editor, or Author) in that project. In the future we can change this to allow them to select if that's the case, but for now this is the best way to associate projects with multiple orgs.

Organization Member Removal

Behavior:

• If a new org admin is added, they should be added as an admin to all projects that org admin is an admin
• If an org admin is downgraded to an editor, their project permissions should be downgraded to editor (as long as they are not the only admin on that project).
• When an org member is removed as an editor, we need to handle their existing project roles. We could either, provide option to cascade removal to all org projects where the admin also has project admin privileges, or allow selective retention for specific projects if needed. For now I think we do the former to not add anything else to our plate. In the future, I think we want to support the latter.

Note: Since projects are separate DAOs, this will require multiple transactions.

Potential Additions:

• (Future feature) Allow the user to select which projects the editor is removed from in removing them as an org editor.

Edge Case: Incomplete Project Access When Adding Org Editors

Scenario:

• An Org Admin adds a new Org Editor, expecting them to get edit access to all org projects. However, the Org Admin isn't a Project admin either because they have been has been removed as Project Admin from some projects by other Project Admins, or the project project is shared between multiple organizations and they are only and editor along with other members of their org.

Behavior:

• When an admin adds an org editor, they should add the editor to all the project they are an admin on.

Potential Additions:

• When adding an editor we should show a summary saying "Editor added to 7/10 projects. You lack admin rights for 3 projects associated with your org." Alternatively we could just show a tool tip saying that editors might not be added to everything.

[blushi]

When creating a new org and migrating over projects, the org admin should be added as a project admin for all their projects (this doesn't require any changes to our UI, just something to note)

What about other members that are added as part of this org creation screen? The copy under the title should be updated in that case.
https://www.figma.com/design/L3VpDxt1PXTATPbSY0Z7DV/Organizations--org-member-permissions--and-project-collaborator-permissions?node-id=5980-93972&m=dev

Creation of New Off-Chain Projects

Behavior:

• Org Admins/Editors have the ability to create new projects on behalf of the org (no changes needed, just the behavior).
• All off-chain projects are editable for org admins/editors

Creation of New On-Chain Projects

Behavior:

• On-Chain Projects: When a new project is created an issuer, they should to it through the UI if they want to have support for the multi-stakeholder management. As such, they are responsible for adding other admins from the appropriate orgs until we develop new features to support this (below in potential additions).

Note: The issuer must add org admins as project admins if we want to support that org admin in automatically adding new org editors to have access to edit projects (see edge case below).

Changes Needed:

• (Backend) Since the create-project msg automatically designates the issuer as the admin we will need to have to sign two transactions. The first to create the project, the second will instantiate with them as an Admin.

Potential Additions:

• On the "Create New Project" flow for on-chain projects, add a step to add members or an org (depending on how we do this it could create edge cases.

• This might be a bit confusing to have different behaviors for off/on chain projects
• re: backend for creating on-chain projects: I'm not sure I totally understand what you mean by "the second will instantiate with them as an Admin". I see 2 options for creating new on-chain projects as org admin:

1. this is relevant for both option: we need to create a DAO for the project with current user with an admin role

2.a. (1st option) add project DAO as issuer
3.a. create project on chain with the project DAO as project admin

or 2.b. (2nd option) create on chain project with the org DAO as project admin (the org DAO being an issuer)
3.b. update the project admin to be the project DAO

I don't think the changes you're proposing (Project roles should be managed at the project level, not inherited from org level) affect any of those options.

If a new org admin is added, they should be added as an admin to all projects that org admin is an admin

could you clarify "to all projects that org admin is an admin"

[S4mmyb]

Organizations

Org Membership Requirements

• Creator of the org must have a wallet address
• Editors / Admins added to the org must have a wallet address, as the org could have credits / projects; This holds true for off-chain projects as well.
• Viewers of the org do not need an address, but will if their permissions are upgraded

Org Creation

• Creator of the org becomes the "owner"

Member Management

• In adding new members to the orgs, editors and admins inherit edit/admin rights to the projects
• Removing an admin / editor from an org removes them from any projects
• If an org admin is downgraded to an editor, their project permissions should be downgraded to editor (as long as they are not the owner on that project).

Projects

Project Creation

• If a project is created from within an organization, it should be instantiated using a DAO;
  • Any Admins/Editors in that org should be added to that project with the respective roles
• If an issuer is instantiating on-chain projects, the issuer will need to sign two transactions: one to create the DAO (which returns the DAO address), and one to transfer the on-chain admin to the DAO address and initialize the creator as the "owner"
• If a project DAO exists, and you want to link an on-chain instance we don't want to create a new DAO the on-chain project. Rather, we should just register the project under the Credit Class and transfer admin to the existing project. This is something that we have a design for, but might not want to implement yet. In this scenario we should create the project via the CLI and transfer admin.
  • In this scenario, the project would keep it's permissions and the issuer who registered the project and transferred admin privileges would not be added to that DAO

Display of Project on Org Profiles

Behavior:

• Projects should appear on an org's public profile if ANY org member has a role (Admin, Editor, or Author) in that project. In the future we can change this to allow them to select if that's the case, but for now this is the best way to associate projects with multiple orgs.

cc @erikalogie @r41ph @alexander-astrand