Link collaborators with actual (dex)users if possible

[Brend-Smits]

Is your feature request related to a problem? Please describe.
Collaborators are just names at this moment and are not interactive at all. Users want be able to click on these names and be directed to their dex portfolio or profile page.

Describe the solution you'd like
When creating a project, it should be possible to link it to an existing dex user. If the collaborator has no dex account it can be just a name like it is now.

[JVerbruggen]

Questions:

1. How are we going to let users connect their accounts with a collaborator string?
2. How will such a request be validated? Or can anyone just connect a collaborator string with their own account?
3. How is the controller going to return this link? In an object between strings? Or will every string also be an object eventually?

[JVerbruggen]

Collaborators are currently fetched in the following format:

"collaborators": [
        {
          "id": 5,
          "fullName": "Wilton Weimann",
          "role": "District Tactics Liaison"
        },
        {
          "id": 6,
          "fullName": "Rosanna Mueller",
          "role": "Dynamic Infrastructure Planner"
        }
      ],

[JVerbruggen]

A returned collaborator object will return a value 'userId' when it is claimed by a user.

"collaborators": [
        {
          "id": 5,
          "fullName": "Wilton Weimann",
          "role": "District Tactics Liaison"
        },
        {
          "id": 6,
          "fullName": "Rosanna Mueller",
          "role": "Dynamic Infrastructure Planner",
          "userId": 23
        }
      ],

[JVerbruggen]

Functional Requirements

1. A project owner edits collaborators and selects a user profile that should be connected. Some sort of search bar in the frontend with typing and then selecting by clicking in a drop-down you searched in. A dex user should accept the link.
2. A dex user should be able to accept or deny a project connection, sent by a project owner.
3. A dex user requests to link his account with a collaborator string. The project owner should manually accept this request.
4. A project owner should be able to accept or deny a project connection, sent by a dex user.

Use Cases

UC01	Details
Summary	FR1 - Project owner links collaborator to dex user.
Actors	Project Owner (PO), User, Frontend, Backend
Precondition	PO is logged in, PO is creating or editing a project.
Steps	1. PO fills in a collaborator name. 2. Frontend suggests an existing dex user based on name in dropdown. 3. PO selects the appropriate user from the dropdown. 4. PO Submits project change 5. Backend marks selected user as pending. 6. Frontend notifies the user of this request.
Exceptions
Post condition

UC02	Details
Summary	FR2 - User accepts link collaborator, sent by a project owner.
Actors	Project Owner (PO), User, Frontend, Backend
Precondition	User is logged in, UC01 has happened, User noticed the notification.
Steps	1. User clicks on accept in the notification. [Exc. 1] 2. Backend marks user-collaborator link as verified. 3. The backend sends a notification to PO that the user has accepted the request.
Exceptions	1. User denies the request -> The backend sends a notification to PO that the user has denied the request.
Post condition

UC03	Details
Summary	FR3 - User requests link with a project.
Actors	Project Owner (PO), User, Frontend, Backend
Precondition	User is logged in, User is on collaborator page from a project.
Steps	1. The user clicks on an unlinked collaborator. 2. Frontend shows a confirmation pop-up. 3. The user accepts confirmation. 4. Backend marks selected user-collaborator link as pending. 6. Frontend notifies the PO of this request.
Exceptions
Post condition

UC04	Details
Summary	FR4 - Project owner accepts link collaborator, sent by a dex user.
Actors	Project Owner (PO), User, Frontend, Backend
Precondition	PO is logged in, UC03 has happened, PO noticed the notification.
Steps	1. PO clicks on accept in the notification. [Exc. 1] 2. Backend marks user-collaborator link as verified. 3. The backend sends a notification to the User that his request has been accepted.
Exceptions	1. PO denies the request -> The backend sends a notification to the User that his request was denied.
Post condition

[JVerbruggen]

@Ruby77 Could you please take a look at the work we've done above? Thanks!

[RubenFricke]

@Ruby77 Could you please take a look at the work we've done above? Thanks!

Wow, good work guys! Seems like a good starting point for this large issue.
Some questions:

• If the user did not accept it yet, will the frontend render an icon or something to clarify that the user has been invited?
• How will we implement this in the new wizard? Can we automize this process?
• Will you guys use the notification system? Or do you have something else in mind?
• Do you plan to create a software design for your implementation, might be a good idea, I suppose.
• Maybe we can fine-tune the process some more for a selection of people? Maybe the data officer or the followers from the user can have some other permissions?

Let's schedule a meeting so we can discuss this and some other topics in more detail, don't you say?

[JVerbruggen]

"collaborators": [
        {
          "id": 5,
          "fullName": "Wilton Weimann",
          "role": "District Tactics Liaison"
        },
        {
          "id": 6,
          "fullName": "Rosanna Mueller",
          "role": "Dynamic Infrastructure Planner",
          "linked": { 
            "userId": 23,
            "status": "pending"
          }
        }
      ],

[JVerbruggen]

If the user did not accept it yet, will the frontend render an icon or something to clarify that the user has been invited?

Collaborators returned will contain a 'linked' object, that the frontend can use to render something correlating to the status.

How will we implement this in the new wizard? Can we automize this process?

Issue for another time. Dex user can be derived from github users.

Will you guys use the notification system? Or do you have something else in mind?

Ruben will look for docs.

Do you plan to create a software design for your implementation, might be a good idea, I suppose.

Interaction with system components. Add design clarification.

Maybe we can fine-tune the process some more for a selection of people? Maybe the data officer or the followers from the user can have some other permissions?

Maybe Data officers can connect dex users directly for dex users that are within the institute?

[JVerbruggen]

https://docs.google.com/document/d/1-sta6a49jwnzeS60tMmOEd82tSTeyeGS1HBQv21tzaA/edit

[niraymak]

https://docs.google.com/document/d/1XstletPi8kkSa-jLuv5DCpkcMCELPYGt6of5lCqTCG4