dwyl / dwyl/auth

EPIC: `groups`: how to collaborate with one or more `people`

Open
#220 10 comments 0 reactions 1 assignee Claimed by @nelsonic View on GitHub
discuss enhancement help wanted priority-1 T1d technical
Dominant language
Elixir
Stars
141
Forks
8
PR merge metrics
No merged PRs in 30d

Description

# Story

As a `person` wanting to ***collaborate*** with others,
I want a way to create a **`group`**
that I can add `people` to
and then share a `list` of `items` with
**So _that_** I can keep track of **who sees, can edit and work on what** `items`.

> **Note**: the _initial_ "**MVP**" version of this feature is just a basic **`group`** that has 1 or more **`people`**.
No permissions, complex **`RBAC`**, **`LDAP`** or other "Enterprise" features, yet!
We can _iterate_ from our simple version and add more advanced/complex features _later_.
For now we just need _something_ we can start using _internally_ and collect feedback from _ourselves_.

# Todo

+ [ ] When a `person` first tries to _share_ an `item` or `list` (of `items`) in the `App`,
+ [ ] _Automatically_ and _transparently_ create a new `group` for them with their name as the `group.name`
+ [ ] Inviting someone to _collaborate_ on an `item` will automatically add them to the `group`
+ [ ] Once the initial share has occurred, we can inform the `person`:
🤖 "_By the way I created this group for you and you can add more `people` to it by visiting_: `/groups/:id`"
+ [ ] Create endpoint to _manage_ `groups`.
+ [ ] Create an interface to allow `people` to _manually_ create a **new `group`**

# Proposed Schema (please comment/discuss!)

## `group`

+ [ ] `name`: `Fields.Encrypted` - the name of the group.
+ [ ] `description`: `Fields.Encrypted` - the description
+ [ ] `kind`: `String` - e.g. `family`, `friends`, `personal`, `sports`, `work`, etc. - we will have `default` kinds that can help the `person` to _categorise_ their `group`; we could _consider_ making this a free-text field in the future ***or*** adding more kinds via Pull Request (so they are hard-coded) because, let's be fair, there are't _that_ many kinds of `group` we will need.

## `group_members`

The lookup table that lists the `people` who are `members` of a `group`

+ [ ] `group_id` `Int` `fk`: the `id` of the `group`
+ [ ] `person_id` `Int`: the `person.id` of the person in the `group`
+ [ ] `inserted_at` `DateTime`: default `Phoenix` field for the insertion of a record.
+ [ ] `admin` `Bool`: if the person can administer (add/remove others from) the `group`
+ [ ] `added_by` `Int`: the `person.id` of the `person` who added the `member` to the `group`
+ [ ] `removed` `DateTime`: `default:null` the date when a person is removed from a `group` (it happens ...)
+ [ ] `removed_by` `Int`: `default:null` the `person.id` that removed this `person` from the `group`

## Features

+ [ ] Build mini SPA for creating/managing `groups` using `LivView`:

@SimonLab thoughts? Am I missing anything? Am I over-complicating it? or is this "just enough" to get started? Thanks! 🙏

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.