# Approach to spec out OrgService

What should the Orgservice do apart from storing users and group memberships? What level of "basic", non-compromisable access control should it enforce? How should OrgService act like the last line of defense as a keeper of metadata for Users and Groups (and now Products..). What exactly is this "metadata" that other teams would like the orgService to manage, and not themselves?

The answers to these questions would hopefully make itself clear via an exercise to consume the services provided by Orgservice — By building a dummy Bridge.

# Requirements for Dummy Bridge

Dummy Bridge is a one stop console to consume API products.

**Who are the _users_ of Dummy Bridge?**
- ( A ) members of partner_Organizations
- ( B ) members of partner_Aggregators (Aggregator of Organizations)
- ( C ) members of organizations under (B) . *Indirect relationship*

( A ),( B ) and ( C ) should be able to login to the platform and _create product instances_.

**What are _product instances_?**

API products fall under many **categories** and to consume one such API product, you must create a _product instance_ in that category. With a _product instance_ you get an API Key and Secret. ( you can create more than one product instances in a given category )

Now to share these credentials with **developers** in your organisation, you simply invite them to your org, and they login using the invite link.

Different levels of access control are defined as follows

- **New User** should be able to _signup_.
- The company he provided during signup will become a **New Org**.
- If a company already exists whose name is within an edit distance of 1 (after taking care of all lowercase/uppercase/whitespace), User will be prompted to NOT sign up, and instead request invite from the associated organisation. However, the user can ignore this warning and proceed to sign up, thereby creating a new org.
- Even if an org already exists with the given name, a new org will be created with the same name.
- This user automatically becomes the **admin** of this new org
- A user can have the following roles

# OrgService

Entities modelled in RDBMS
- **Users**
- **Organisations**
- **Products**

Constraints
- **users** can belong to <u>one or more **organisations**.</u>
- An **Organisation** can have one or more **owners**
- A **Product** can have one or more **users** as **owners**. Furthermore, it can also have one or more **organisations** as owners.
- New **users** can be added to existing **organisation** ONLY via an _invite_ from a **owner** of the said **organisation**.
- If a person out in the wild _signs-up_, a new **organisation** will be created whether or not the name already exists. This user will become the **owner** of the **organisation** by default.
- Any **user** can _create_ **products**. The creator becomes the **owner** of the product by default. All the **organisations** that the **user** belongs to, also become the **owner** of the product by default. However, this can be overridden to restrict visibility.
- Any **owner** of the **product** can _perform CRUD_ on it.

### Users

- `POST /users`
- Unauthenticated API, needs no access_token
- Called during Sign-up
- REQUEST

- ```json
{
"email": "[e-mail]",
"mobile": "9999999999",
"companyName": "kompany",
"password": "hashed-passwd"
}

  - **Note:** A new will **Org** will be created as a part of this API
- `GET /users/:id`
    - details omitted

### Orgs

- `POST /orgs`
    - This API would probably be rendered useless by POST /users API
- `GET /orgs/:id`
    - details omitted

### Products
These are **authenticated** APIs and access_token must be supplied. Also the **user** who triggered these requests is _inferred_ from the "sub" claim in the access_token. This is why these APIs <u>don't</u> look like `/users/:id/products`

- `POST /products`
    - REQUEST
        - 

{
"name":"name of the product",
"category": "BBPS",
"orgs": [ "orgID", "orgID", "orgID" ], //optional field
"users": [ "[e-mail]" ] //optional field
}

        - If the `orgs` field is not supplied, the ownership of the product is given to all the organisation the user belongs to.
        - `users` field can be used to invite users from the wild, regardless of their belonging to any organisation. If the user does not exist, he will be automatically invited by mail.
- 
- `GET /products/:id`
    - omitted



# Existing Bridge Painpoints
### 1
Org name while signing up. Any typo ends up creating multiple orgs for the same company
### 2
Distinction between aggregators and non aggregators