Access

This is the centralized system for handling all access across the entire BackBone ecosystem, from projects, client and user to every part of every endpoint avalible though our Services. This feature handles both, our internal access as well as offered as a access handling endpoint to Clients

Task Chat Launch

---

Status & Details

Description

Add a detailed description

Status

warning

These details are only updated with each release, for more acurate updates and keeping track of progress, see the task in GitHub.

Owner	Lead	Doc Status	Product Status	Last Update	Version	Release	Phase
Mendy	Esti	In Progress	Up Next	04.03.2024	0.01	Internal	Alpha

Reminders

• Keep code lean and clear
• follow the outlined arcetecture
• write commetes in your code
• update the staus in the docs and in GitHub
• try not to recreate functions we alredy have, rather update exsiting functions to support your needs
• Be sure to follow the release guidelines
• Update Documentation
• keep API docs up to date each time you update or add endpoints

Links & Resources

• Task
• Chat
• [Main Branch]
• [Alpha]
• [Beta]
• [Production]

Research

Research

Question - How do we handle access managment for clients when their data is not on BackBone? Answer -

Question - Do we have two systems for internal and enternal access or one that works for both? Answer -

Question - what do we need to consider in terms of securaty? Answer -

Question - how do we handle permissions, is it built in, a seperate feature, do we need features to support it? Answer -

Question - are there open source solutions we can use and will it be faster to use or build Answer \

Question - What is the best way to build this Answer - Gemini Answer

User Stories, Flows & Personas

User Stories

Persona One

Update Coming Soon

User Flows

Personas

Features & Functions

Features

Below is a list of features that will be utilized in order to deliver the best account features and functionalities. The details bellow are not comprehensive feature details but rather, describe how the features will be utilized within the account, for further details, please see the individual feature documentation.

• [Permissions]

  permissions are a a spesifict fuunction like users, projects, etc. esencaliy every action that can be taken has a related permission.

  • [Levels]

    each permission has a permission level (e.g. view, comment, edit, admin, owner)

• Access

  Access give the user or client a set of permitions

• Groups

  A group

• Teams

  should the client have created a team with multiple clients, permissions or access can be set for the full team at once.

Data

note

You can find the Data Structure.

On the document we want to keep all the important data, the first fetch and fast to access.

• who (user/client id)
• what (object id e.g. project, aseet, etc)

Access

If the account type is not "indiviual" the account will not have an auth method and thefore will reqesre access. This will be a sub-collection within the account document that will hold the account, group, etc IDs of anyone who has access to this account.

    - access
    - - account 1
    - - - account id
    - - - level
    - - - inhrited (id)
    - - - expries

API

This page describes all supported access, how to manage them, and how they can be grouped using sets.

Permission Format

Each permission is an action on a resource.

permission_id	resource	action	description
view_project	project	view	Can view project details
comment_project	project	comment	Can comment on project
edit_project	project	edit	Can update project info
delete_project	project	delete	Can delete project
manage_users	system	manage	Can manage users
create_payment	payment	create	Can create new payment
view_payment	payment	view	Can view payment details
edit_payment	payment	edit	Can modify payment info
admin_all	"*"	"*"	Full access to all operations

All access are string-based and should be passed as array of strings in assignment.

---

Get All access

Returns a list of all defined access in the system.

GET

https://api.myapp.com/v1/access

Response

[
  "view_project",
  "edit_project",
  "comment_project",
  "manage_users",
  "create_payment",
  "edit_payment"
]

---

Permission Sets

A Set is a predefined group of access.

Each user can be assigned to one set, or use "custom" to define their own.

set_id	label	included_access
viewer	Viewer	view_project, view_payment
commenter	Commenter	view_project, comment_project
editor	Editor	view_project, edit_project, edit_payment
manager	Manager	all project + payment access
admin	Admin	all except system-level
owner	Owner	all including manage_users

Each permission set can be queried and customized by Admin or Owner.

---

GET set details

GET

https://api.myapp.com/v1/access/sets/:setId

Example: https://api.myapp.com/v1/access/sets/editor

Response

{
  "setId": "editor",
  "access": [
    "view_project",
    "edit_project",
    "edit_payment"
  ]
}

---

POST: assign a set to a user

POST

https://api.myapp.com/v1/users/:userId/set

Body

{
  "setId": "editor"
}

---

Custom access per User

POST

https://api.myapp.com/v1/users/:userId/access

Body

{
  "access": [
    "view_project",
    "edit_payment",
    "create_payment"
  ]
}

Response:

{
  "message": "User access updated successfully"
}

GET

https://api.myapp.com/v1/users/:userId/access

Response

{
  "userId": "abc123",
  "access": [
    "view_project",
    "edit_payment",
    "create_payment"
  ]
}

---

Future Features

Groups

group_id	name	description
g-dev	Developers	Shared access to all dev resources
g-marketing	Marketing	Read-only + Comment on public items

Assign access or sets to entire group, then assign users to that group.

GET

https://api.myapp.com/v1/groups/:groupId/access

Teams (Structured Groups)

Teams are groups with context.

team_id	team_name	auto_assigned_set
team-dev	Developers	editor
team-admin	Admin Team	admin

---