# Applications
This document details out the options and logic for applications to communities within the Alkemio platform.

The notion of Community is key inside Alkemio, and critically that membership of a community is curated. As such Users, and potentially Organisations, need to apply to become a member of a Community.

Notes:
* Agreements: a Community can have agreements associated with it, that all members have accepted / agreed to abide to
* This is critical to having a clear set of rules for the collaboration
* Note: having specific agreements per Community is not there yet.
* a Community by design only exists around Ecoverses, Challenges and Opportunities.
* Critically it does *not* exist around an Organisation. This is the key change we are trying to bring in how parties collaborate: the Challenge has to be central.
* Communities are hierarchical, and to join a child Community you also need to be a member of the parent Community
* Critically this also means having accepted any t&cs / policies associated with each Community
* Each Community has different Users who are able to approve membership
* In particular, if a User applies to a Challenge then
* The Ecoverse Admin (or equivalent) needs to approve access to the Ecoverse Community
* The Challenge Admin (or equivalent) needs to approve access to the Challenge Admin

Aspects to consider:
- Lifecycle associated with an existing application
- Membership of the user
- Policy / setup of the community that is being applied to

## Design Paths
There are several design paths identified:
* Multiple Applications: One User action ==> two Applications, each with one approval ==> two memberships
* Multiple Approvals: One User action ==> one Application, with two approvals ==> two memberships
* Single Application with notes: One User action to apply to Ecoverse community, with a note stating Challenges they would also like to be a member of.

It may be that we simply want Users to always formally click through each level of Community application process.

### Multiple Applications
Pros
* Single action from User point of view

Cons:
* No clear path for User acceptance for membership terms / question responses at the Ecoverse level
* Note: we could force two screens to be clicked? So literally trigger two applications? But then application to Challenge should not be able to be approved before application to Ecoverse is approved.
* Introduces more complexity and is more work short term.

### Multiple Approvals:
Pros:
- Good learning re states: Implies that we start managing multiple state Lifecycles with actions / guards at each state.
- Single User approval

Cons
* It implies switching more to a set of "actions / approvals" that need to be carried out - which is more work short term even if this may be a better option longer term. So it forces us to do more regarding Lifecycle design now.
* No clear path for User acceptance for membership terms / question responses at the Ecoverse level
* Introduces more complexity and is more work short term.
* Additional logic needed on server + client to be able to reflect the multiple running processes and the interactions between the different approval processes.

Note: it could even be that we model the nested nature of the interaction via XState:
* initial state of the lifecycle creates a nested application that has to proceed first, which would then work fine in terms of existing setup.
* Also fun to try working / really pushing the boundaries of XState modeling / logic management.

Note that in the above description when "two" Applications etc are talked about that this could actually be multiple.

### Single Application to Ecoverse with request for Challenge(s)
This would allow the User when applying to join an Ecoverse to also request that they are added as a Member to the community for a particular Challenge.

This could be as simple as adding a question to the Ecoverse questions template asking Users to specify any particular Challenge(s) that they want to join.

Pro
* Single user action
* Least amount of changes / work near term

Cons:
* Functionality is less generic
* Relies on Ecoverse Admin to also do the step of adding the User to the Challenge.

## User interaction + Actions
It needs to be clear to a User what **actions** are available regarding joining a Community.

This section assumes that the option "Single Appication to Ecoverse with request for Challenge(s)" is what is being worked.

Note: The set of actions a User can carry out is separate from the notion of states that govern the Lifecycle of a particular Application.

The following actions are identified:
* **None**
* Rational: Already a member
* Rational: Application pending
* Rational: Invitation only (later)
* **Apply to join a Community**
* e.g. user applies to join an Ecoverse
* e.g. user applies to join a Challenge in an Ecoverse where they are a member
* **Apply to join parent Community**
* This is for when the User is not already a member of the parent Community. Note: this could be multiple levels up.
* e.g. to apply for a Challenge the User would need to apply to join the parent Ecoverse with a note.

Depending on the actions open to a User, there should also be feedback given, especially when there is no action possible (see later).

## Inputs for deciding the application status
The following data is relevant for deciding which actions are available to a User:
* **Community data**
* **Target Community**: Information about the Community being applied to
* Later this would include any policy related to agreements that need to be accepted as part of applying
* **Parent Community**: Is there a parent Community? If so then details about the Community
* **User data**
* **Authentication status**: If the current User is authenticated
* **Memberships**
* is the User already a Member of the Community?
* does the User have an Application pending for this Community?
* What is the Application state?
* if there is a parent Community:
* is the User already a Member of the Parent Community?
* does the User have application pending for the Parent Community?

Note that there could later be other information about the user that maybe is relevant to their application e.g. Users with certain credentials are automatically eligible to become members of a Community etc.

## Membership component
The current "Apply" button on the Ecoverse / Challenge pages is essentially about the users Membership of that Community.

This component should have the following behavior:
* **Button: "Login to Apply"**: shown when the User is not authenticated.
* Routes to the login page, and after login routes the User back to the page for the Ecoverse / Challenge.
* **Button: "Apply to join ```Challenge | Ecoverse```"**: shown when the User is applying to join a single Community.
* Routes to the Application Page.
* **Button: "Apply to join containing Ecoverse"**: shown when the User is not a member of the parent Community.
* The User should first receive a popup with an option to proceed / stop
* The popup informs the User
* That to join the Challenge they first need to be a member of the parent Ecoverse.
* The User is advised to enter the name of the Challenge(s) they wish to join in the Application form.
* That if they proceed that they will be re-directed to apply to join the parent Ecoverse.
* If proceed is chosen then routes to the Application Page for the Ecoverse.
* **Label: "Application pending"**: shown when a User has an Application pending that is in a non-final state.
* **Label: "Member"**: shown when the User is a member of the Community

## Other updates
The template for joining an Ecoverse should be updated with an optional field where the User is encouraged to enter the names of Challenge(s) they wish to join.

TBD: make this field pre-populated when redirected from a Challenge page to Ecoverse Application?!