The data in the Voluntari.ly system must have integrity, security, privacy.

Access to the data through the service api must implement the following access rules

Access is controlled by the identity and Role of the user

User Roles

Role	Means
anon	person is not signed in. They can view various parts of the site but cannot change anything. Most clicks will prompt them to register and sign in.
all	all signed in users, they can browse more of the site create opportunties and manage their personal profile.
vp	volunteer time provider - i.e a volunteer, person who is interested in an opportunity. They can view opportunities in summary and detail form, show interest and communicate with the op-provider. by default everyone is a vp
op	Opportunity provider - e.g a teacher. person who creates and manages an opportunity.
ap	Activity provider / content provider, can create and manage activities.
tester	can see debug and analytics pages
admin	operational admin, can do almost everything through the UI
org-admin	Can manage an organisation, its members and can set an approval process for listings
owner	The specific person responsible for a record e.g a personal profile, opportuntity etc.

Archived Opportunities

Role	Action	Permissions	Fields	Method + Route
anon	list	View all archived opportunities with status "Completed"	id, name, subtitle, img_url, duration	GET /api/archivedOpportunities
anon	read	View individual archived opportunity records with status "Completed"	all	GET /api/archivedOpportunities/:id
anon	create	No access	n/a	n/a
anon	update	No access	n/a	n/a
anon	delete	No access	n/a	n/a
all	list	View all archived opportunities with status "Completed"	id, name, subtitle, img_url, duration	GET /api/archivedOpportunities
all	read	View individual archived opportunity records with status "Completed"	all	GET /api/archivedOpportunities/:id
all	create	No access	n/a	n/a
all	update	No access	n/a	n/a
all	delete	No access	n/a	n/a
admin	list	View all archived opportunities	id, name, subtitle, img_url, duration	GET /api/archivedOpportunities
admin	read	View individual archived opportunity records	all	GET /api/archivedOpportunities/:id
admin	create	Can create records	all	POST /api/archivedOpportunities
admin	update	Can update records	all	PUT /api/archivedOpportunities/:id
admin	delete	Can delete records	all	DELETE /api/archivedOpportunities/:id

Interests

Role	Action	Permissions	Fields	Method + Route
anon	list	No access	n/a	GET /api/interests
anon	read	No access	n/a	GET /api/interests/:id
anon	create	No access	n/a	POST /api/interests
anon	update	No access	n/a	PUT /api/interests/:id
anon	delete	No access	n/a	DELETE /api/interests/:id
volunteer	list	Can list own interest records	All	GET /api/interests
volunteer	read	Can read own interest records	All	GET /api/interests/:id
volunteer	create	Can create own interest records	opportunity, comment (all other fields set by default)	POST /api/interests
volunteer	update	No access	n/a	PUT /api/interests/:id
volunteer	delete	Can delete own interest records	n/a	DELETE /api/interests/:id
op	list	Can list interest records for their opportunities	All	GET /api/interests
op	read	Can read interest records for their opportunities	All	GET /api/interests/:id
op	create	No access	n/a	POST /api/interests
op	update	Can update status field of interest records for their opportunities	status	PUT /api/interests/:id
op	delete	No access	n/a	DELETE /api/interests/:id
org admin	list	Can list interest records for the opportunities provided by their organisation	All	GET /api/interests
org admin	read	Can read interest records for the opportunities provided by their organisation	All	GET /api/interests/:id
org admin	create	No access	n/a	POST /api/interests
org admin	update	Can update the status field of interest records for the opportunities provided by their organisation	status	PUT /api/interests/:id
org admin	delete	No access	n/a	DELETE /api/interests/:id
admin	list	Can list all interest records on the platform	n/a	GET /api/interests
admin	read	Can read all interest records on the platform	n/a	GET /api/interests/:id
admin	create	Can create interest records	n/a	POST /api/interests
admin	update	Can update all interest records on the platform	n/a	PUT /api/interests/:id
admin	delete	Can delete all interest records on the platform	n/a	DELETE /api/interests/:id

People

List

GET /api/people

Role	Can
anon	cannot list people
all	can list people matching criteria and get limited info back. ( name, avatar and skills/interest ) but not contact details.
admin	can list all people
org-admin	can list people in their organisation

Create (new person)

Post /api/people/

Role	Can
anon	Can create one person by registering with a valid identity
all	cannot create people
tester	Can create new people
admin	Can create new people
org-admin	Can create a list of new people from an uploaded data set.

Read (single person)

GET /api/people/:id

Role	Can
anon	No
all	Can browse a person's profile page but with contact details removed
vp	can be indirectly provided with contact details for a vp via an interested record in invited state
op	Can browse a person's full profile page if they are in the same organisation
ap	Can browse a person's full profile page if they are in the same organisation
admin	full access
org-admin	Can browse a person's full profile page if they are in the same organisation
owner	The person matching the person ID can see all their profile details.

Update

PUT /api/people/:id

Role	Can
anon	no access
all	no access to change people records
admin	can update person's record
org-admin	can update person's record
owner	can update their own record

Delete

DELETE /api/people/:id

Usually delete will not delete the record from the database but will mark it as unavailable.

Role	Can
anon	no access
all	no access
admin	Can delete a person, this will maintain the person_id record but replace all the PID information (email, name, avatar) with anonymised placeholders so that historical records still work.
org-admin	can mark person as no longer in the organisation but not remove them.
owner	A person can resign from the site and this will delete them as above for an admin.

## Create
Person - Created when new person signs in - All
Opportunity - all - but only into draft mode. May require org-admin approval to set active state
Activity - ap,
Organisation - Admin
Interest - vp
tag - all

## Read
Person - All
Opportunity - All+anon except in Draft mode - then only op-provider (op) and org-admin
Activity - All+anon except in Draft mode - then only activity-provider (ap) and org-admin

## Update
## Delete
In most cases Delete paths should be only available to Admin ( and some API keyholders)
Also in most cases Delete should not remove a document but move it into a new state, or collection.

Opportunities

List

GET /api/opportunities

Role	Can
anon	can list ops with restrictions - (active, near future, and returns Card level info, no details). To see more they have to sign in.
all	can list published ops and see full details ( published includes active and completed )
admin	can list ops in all states
org-admin	can list published and draft ops created by people in their org

Create

POST /api/opportunities

Role	Can
anon	cannot list people
all	can list people matching criteria and get limited info back. ( name, avatar and skills/interest ) but not contact details.
vp	can create opportunities of the 'offer' type
op	can create opportunities of the 'request' type into draft state but may require org-admin permission to move to active. org is fixed to org of owner
admin	can create anything
org-admin	can create ops and move draft ops to published.

Read

GET /api/opportunities/:id

Role	Can
anon	can see full details of the op, (must be active state) need to sign in to express interest
all	can see full details of the active and completed ops
admin	can see full details of ops in all states
org-admin	can see full details of ops in all states for ops created by people in their org.
owner	can see full details of ops they own

Update

PUT /api/opportunities/:id

Role	Can
anon	no access
all	can list people matching criteria and get limited info back. ( name, avatar and skills/interest ) but not contact details.
admin	can update ops including state change
org-admin	can update ops including state change for ops created by people in their org
owner	can update their own ops. cannot change org,

Delete

DELETE /api/opportunities/:id

Role	Can
anon	no access
all	no access
admin	can remove a record by putting it into archived collection
org-admin	can remove a record by putting it into archived collection for their org
owner	can change state to 'closed'

Activities

List

GET /api/activities

Role	Can
anon	can list if active
all	can list if active
admin	can list all
org-admin	can list all where ap is in org
ap (owner)	can list all they are owner for

Create

POST api/activity

Role	Can
anon	no access
vp	no access
op	no access
ap	can create new activity record
admin	can create new activity record
org-admin	can act as ap for person in their org

Read

GET api/activity/:id

Role	Can
anon	can view details if state is active
all	can view details if state is active
admin	can see all
org-admin	can emulate ap for people in their org, can see draft acts.
ap (owner)	can view details in all states.

Update

PUT api/activity/:id

Role	Can
anon	no access
all	no access
vp	no access
op	no access
ap (owner)	can update acts they are owner for
admin	can update
org-admin	can act as ap for acts in their org

Delete

DELETE api/activity/:id

Role	Can
anon	no access
all	no access
admin	can delete
org-admin (owner org)	no access, can put into closed state (via Update)
ap (owner)	no access, can put into closed state (via Update)

Organisations

Organisation information is essentially public, everyone can read except for the info section which depends on membership status.

Note - in the medium term we do not need to block info fields from the API. We will communicate to orgAdmins that the content is not strictly private and should only contain summary information and links to internal web pages.

List

GET /api/organisations

Role	Can
anon	List all organisations, all fields
vp	List all organisations, all fields
op	List all organisations, all fields
ap	List all organisations, all fields
resource provider	List all organisations, all fields
admin	List all organisations, all fields
org-admin	List all organisations, all fields

Read

GET /api/organisations/:id

Role	Can
anon	Read the entity and all fields
vp	Read the entity and all fields
op	Read the entity and all fields
ap	Read the entity and all fields
resource provider	Read the entity and all fields
admin	Read the entity and all fields
org-admin	Read the entity and all fields

Create

POST /api/organisations

Role	Can
anon	No access
vp	No access
op	No access
ap	No access
resource provider	No access
admin	Can create new organisation
org-admin	No access

Update

PUT /api/organisations/:id

Role	Can
anon	No access
vp	No access
op	No access
ap	No access
admin	Can update all fields
org-admin	Can update all fields for the organisation they administer except category No access to other organisations

Delete

Only system admins can delete an organisation. This should be a rare event as it will leave all the assets linked to the organisation dangling. i.e Ops.offerOrg, Member.organisation etc.

DELETE /api/organisations/:id

Role	Can
anon	No access
vp	No access
op	No access
ap	No access
admin	Can delete
org-admin	No access

API Access Security Rules

User Roles

Archived Opportunities

Interests

People

List

Create (new person)

Read (single person)

Update

Delete

Opportunities

List

Create

Read

Update

Delete

Activities

List

Create

Read

Update

Delete

Organisations

List

Read

Create

Update

Delete