Community Membership

--- tags: Product --- # Community Membership The Alkemio platform is intended to make it much easier for contributors (users and organizations) to work together on shared goals. The set of contributors around a Challenge / Hub / Opportunity is called a Community. In this document the term "user" can be taken to refer to both organizations as well as users. The primary focus is on users, but most if not all of the requirements also directly apply to organizations as the platform allows organizations to join Challenges similar to how a user does. ## Members of a Community A Community thus has members. Being a member of a Community allows users to carry out certain actions e.g. start an Aspect, join a Discussion etc. They are also able to turn on notifications for certain events in that Community e.g. receive Community Updates, get notified of new Discussions etc. Each member of a Community will have their membership of that Community visible on their profile. ## Accepting Membership Obligations Community membership also implies accepting and agreeing to be bound by the rules of that community. This is a key design for Alkemio, even if not currently enabled. This means the the flow for joining a community **must** include the user explicitly accepting the rules of the Community being joined. ## Why do users join a community? As part of designing the expanded version of community membership, the following are the key benefits we believe users would be after: * To contribute to the goals of the community * To be updated as to developments in that community * To connect and interact with other users in that community * To have their contributions visible, both in terms of profile and to make a statement * To see what is happening within a private Hub / Challenge * To be inspired by what is happening # Becoming a Community Member The key question then arises of "how" a User joins a Community? Currently there are two options: * **Applications**: The User applies to join a Community, and their application is then approved / rejected by an admin of that Community * *Why not enough?* This works well for highly curated communities, but is too high a threshold for a situation where you want users to much easier engage with a Challenge / Hub. * **Direct addition**: The Community admin directly adds the User * This option **should** be removed, as the User does not get a Chance to accept the conditions for joining that Community. ## Additional routes to Membership The following two additional routes to Community membership should be supported: * **Directly Join**: allowing users based on held credentials to directly join a community. So without an application + approve / reject flow. * Example 1: all Users associated with a particular organization * This is for example the case with UWV where they would like to grant all users with an email address (verified!) matching the UWV domain to be member of the UWV organization, and thus to be able to directly join the UWV hub (private) * Example 2: Members of another community * This would be the case whereby once someone is a member of a Hub that they can then join Challenge communities hosted within that Hub. * **Invitation**: Allowing Community admins to invite Users to join a Community. Again no approval / rejection would be needed. * In this scenario a Community admin could "invite" via email or a special link Users to join a Community. Similar to invitations in GitHub or a link in Discord. * **Subscriptions**: one can also envision in the future that users pay a subscription to become members of a Challenge / Hub, especially for Organizations. ## Leaving a Community Users also need to be able to leave a community. This is currently only available to Community admins; it should also be exposed to Users. ## Administering Community Membership The Community Admin should be able to control how membership of that Community happens. For example: * Allowing all Users from a particular Organization to be able to Join the Community * Allowing members of a Hub to join child Challenges directly or that they should apply / be invited * Not allowing any applications # Design There is currently some quite complex logic on the client that determines which message / options are provided to users on joining a community. This logic should be replaced with use of privileges, so that this logic can be enforced by the server. ## Server ### Privileges The following privileges are needed: * **COMMUNITY_APPLY**: user is allowed to apply to join a Community * **COMMUNITY_JOIN**: user is allowed to directly join a community * **COMMUNITY_LEAVE**: user is allowed to directly leave a community ### Authorization Policy It is the combination of the credentials held by the user togethr with the AUthorization Policy Rules that determine the privileges that are granted to a user. For more details please see the [credential based authorization design](https://github.com/alkem-io/alkemio/blob/develop/docs/credential-based-authorization.md). The above design is very powerful, but also is not "familiar" to most users - so it is not exposed via the api. Instead the domain model maintains a number of "settings" to administrators that then get translated by the server into the authorization policy rules to be applied. ### Settings The following would be the set of options that would be available on a Hub: * *Applications allowed* * Type: boolean, defaults to true * This is basically the only option supported at the moment * Privileges granted: * If true, grant the COMMUNITY_APPLY privilege to users with RegisteredUser credential. It is not inherited. * Grant the COMMUNITY_APPLY privilege to users with HubMember credential. It is inherited. * *Allow members from the following organizations* * Type: Organization, which by default is empty * UI to expose a single option * The api itself should store this as an array, as it could easily later be multiple organizations allowed * Privileges granted: * Grant the COMMUNITY_JOIN privilege to all users that have the OrganizationMember credential for the specified organization(s). It is not inherited. * *Allow Hub members to directly join Challenges* * Type: boolean, defaults to false * Privileges granted: * Grant the COMMUNITY_JOIN privilege to users with the HubMember credential for the particular Hub. It is inherited. In addition the following rules would need to be added independent of the settings: * A privilege rule would need to be added so that any user with the "GRANT" privilege on a Community would also have the COMMUNITY_JOIN / COMMUNITY_LEAVE privileges. This then allows administrators, which have the GRANT privilege, to also assign users to a Community. * Grant all users having the CommunityMember credential for that community to have the COMMUNITY_LEAVE privilege ## Storing of Preferences For a maintainable design, we need to think through where we store the Hub preferences. The suggestion for now is that we do the following: * Replicate the pattern we have for UserPreferences and create new entities for HubPreference, HubPreferenceDefinition and enums for HubPreferenceType and HubPreferenceValueTypes * Add a migration to store the above preferences on all Hubs * Migrate the current "allow anonymous read access" flag to be a HubPreference The following initial groups of HubPreferences would be supported: * HubMembership * HubVisibility ### Mutations The following mutations would need to be adjusted: * assingMemberToCommunity: to check for the COMMUNITY_JOIN privilege * removeMemberFromCommunity: to check for the COMMUNITY_LEAVE privilege * updateHubPreference: to allow updating of the preferences for community membership on a Hub and contained Challenges * TBD depends on design choice re where they are stored. * updateHub: to no longer support the UpdateAuthorizationPolicyInput field to be set as that would now be a preference * createApplication: to check for the COMMUNITY_APPLY privilege TBD: remove the option for admins to directly add Users to a Community? This should be replaced by "invite". ## Client updates The client currently has some fairly complex logic that determines when users can apply, what message is shown to them. That needs to be adapted / extended to deal with the above. Key changes: * If the user is not a member of a Community: * Retrieve the myPrivileges for the current user * If the user has the COMMUNITY_JOIN privilege, then display the option to "Join" (instead of Apply) for users with the * Clicking on this button presents the user with a popup (similar to Application) whereby they can confirm that they are joining the specified community. Later this popup would also be where the user can accept any T&Cs specific to that Hub * Apply functionality / rules for now are further left as they are. * On a user profile settings page, offer the user the option to "Leave" a community that they are a member of. * The "allow non-Hub members to see Challenges" flag on a Hub settings page to be migrated to be a HubPreference * Hub settings page to have a tab for "membership / visibility" which then displays the two HubPreference groups defined above Note the above is not using yet the COMMUNITY_APPLY privilege. To be discussed when we get to reviewing the implementation on the client + see if using it would simplify the client logic or not.