Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request to join groups / Approval process #894

Closed
tiltec opened this issue Feb 24, 2018 · 4 comments · Fixed by #1082
Closed

Request to join groups / Approval process #894

tiltec opened this issue Feb 24, 2018 · 4 comments · Fixed by #1082

Comments

@tiltec
Copy link
Member

@tiltec tiltec commented Feb 24, 2018

Currently karrot either allows groups to be open or password-protected. I usually recommend groups to set a password to protect themselves from vandalism. I think this won't be enough in future and a "group join approval process" should be implemented.

The downsides of the current situation are:

  • once a user knows the password, they can join the group with many accounts
  • a group member can change the password without other members being aware of it
  • there's no built-in way to get in contact with a group to receive the password (but have to use a separate channel such as e-mail or facebook)

These downsides might become more important when we implement voting features such as #853. Then a person who has more accounts in a group can affect the vote.

I'd propose a process where

  • a user can get in contact with the group without joining it
  • they can request to join
  • group members can vote if they want the person in or not

Related is #878, which could add web of trust features to allow people giving their agreement to a person being member of the group: "I trust this person to become a member of the group".

Further details of this proposal have yet to be hashed out, so I'll leave it for discussion.

@NerdyProjects

This comment has been minimized.

Copy link
Member

@NerdyProjects NerdyProjects commented Feb 26, 2018

Outcome of a discussion:

  • Use the existing roles relationship to model the approval status of a member
  • Already with the request to join a group, a person becomes a "member"
    • Just without the approval status no permissions are granted
  • The most easy approval method can be implemented first: A single approval leads to the approval status
  • An approval, as well as the non-approval (reject) should be recorded and shown
@tiltec

This comment has been minimized.

Copy link
Member Author

@tiltec tiltec commented Mar 16, 2018

Further questions:

  • How do members get approved? Can they also get rejected?
  • What happens when they don't get approved? (maybe people in the group don't care or group is inactive)
@tiltec

This comment has been minimized.

Copy link
Member Author

@tiltec tiltec commented Jul 11, 2018

Based on the high-level planning of #1062, we had a planning and design session today with @nicksellen @djahnie @taistadam and me. The goal was to design a simple application process that can be implemented by us in the next weeks.

After some hours of thinking and drawing, we ended up with a feature that includes an application form, a conversation between the group and the new user and an application list for the group.
We decided to leave away voting capabilities for now, so a single "accept" or "deny" is enough to decide the application.

The user flow for the applicant should be:

  1. Applicant chooses group on karrot's group gallery page and clicks on "Login or signup to apply for this group"
  2. Applicant fills out signup form and clicks on submit
  3. Karrot redirects back to group preview page, button shows "Verify your email to continue"
  4. When the Applicant clicks on the verification link in the email, karrot opens group preview page and shows button "Apply to join"
  5. Applicant clicks apply button, karrot shows application form
  6. Applicant reads group-specific questions and fills out answers
  7. Applicant clicks on submit, then gets redirected to the applicant chat (possibly with a message "The group received your application. You will receive a notification email when group members reply to your application.")

After an application has been sent, the group gallery shows pending applications on top, possibly with a different header and/or a different background color.

The user flow for group members should be:

  1. A group member sets the questions to the applicant in the "Edit group" form
  2. Each group member can enable "New application" notification emails in the group settings page.
  3. When a new application is sent:
    • group members with enabled notifications receives a notification email containing the name and answers that the applicant wrote. It contains a link to the application chat.
    • the group wall shows a notification "There is one pending application", which links to the application list.
  4. The application list shows name and picture of the applicant, the application date, a button to open the application chat and accept/decline buttons.
  5. The application chat shows question and answer by the applicant and includes every member of the group. Group members can now ask the application further questions, for example invite them to a meeting.

When the application is accepted or declined, chat messages are getting deleted from the database. A history entry with details about the application will get created.

We were yet unsure how to display the group's questions and the applicant's answers in the conversation chat. One possibility is to have both as messages, but then the questions would either by a different message type or would need to be included into the answers. Another possibility is to have them as text outside of the conversation, but that needs special handling for displaying them and sending notification emails

@tiltec tiltec assigned nicksellen, tiltec and djahnie and unassigned NerdyProjects Jul 11, 2018
@tiltec tiltec mentioned this issue Jul 11, 2018
30 of 39 tasks complete
@djahnie

This comment has been minimized.

Copy link
Member

@djahnie djahnie commented Jul 11, 2018

Thanks for the writeup, @tiltec!
So apart from graphical design details open questions are the following, I'd say:

  • Can an application be submitted with empty text field(s)?
  • Is there a time limit for a pending application?

And most importantly of course:

  • Shall we have the initial questions and answers posted inside or outside the conversation and how does it work in detail?

Next meeting on Friday, right? 😊

@djahnie djahnie mentioned this issue Jul 13, 2018
50 of 51 tasks complete
nicksellen added a commit to yunity/karrot-backend that referenced this issue Jul 15, 2018
Related to yunity/karrot-frontend#894 (comment)

Adds endpoints 
- `POST /api/group-applications/` with body `{ "group": id, "message": string }` to create a new application
- `GET /api/group-applications/` to list applications with response body:
    ```
    {
      "id": 7,
      "user": 12,
      "group": 3,
      "conversation": 262
    },
    ```
- `POST /api/group-applications/:id/accept/` for group members
- `POST /api/group-applications/:id/decline/` for group members
- `POST /api/group-applications/:id/withdraw/` for the applicant
- `GET /api/users-info/` to retrieve public user profiles (currently only contains `display_name` and `id`)
    - can be filtered by conversation id: `/api/users-info/?conversation=262`
    - is paginated

Other changes:
- add group notification setting `new_application`
- add emoji to some email notification subjects
- remove password login feature and make all groups use the application process (except for playground group)
- switch to `@action` decorator to resolve deprecation warnings
tiltec added a commit that referenced this issue Aug 6, 2018
Related to #894
@tiltec tiltec mentioned this issue Aug 17, 2018
6 of 9 tasks complete
@tiltec tiltec closed this in #1082 Aug 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants
You can’t perform that action at this time.