Credit management (backend)

[clostao]

Implemented backend changes described in #8:

Admin users management:

• Admin privileges are implemented adding a field named "role" to users table
• An admin could update a user's role
• Admins could see a list of all the user's

Credit management:

• Added two more columns to user table: download_credits and upload_credits for limit user's activity.
• Users with AdminRole could increment upload and download credits.

Api Keys:

• Added a new table that keeps track of the ApiKeys and the userId. An apikey is a user itself and is not related with a certain oauth account.
• Since api keys are user's they have a usage limit too

[netlify]

✅ Deploy Preview for auto-drive-demo canceled.

Name	Link
🔨 Latest commit	90dcbc5
🔍 Latest deploy log	https://app.netlify.com/sites/auto-drive-demo/deploys/671234e538f7f30008f3d9fd

[marc-aurele-besner]

This seems very cater to individual use and not organization use at all.
Even if it's maybe out of spec, I feel we should at least design the db and structure to support both.

I'll suggest (if out of spec) also creating a org table, and automatically creating a org for each users and tied the api to the org+user, this way we will be able to extend functionality more easily in the future

[clostao]

This seems very cater to individual use and not organization use at all. Even if it's maybe out of spec, I feel we should at least design the db and structure to support both.

I'll suggest (if out of spec) also creating a org table, and automatically creating a org for each users and tied the api to the org+user, this way we will be able to extend functionality more easily in the future

The credit management is true that is too coupled to the individual. For solving this we could have a subscriptions table that controls a subscription either being from an org or an individual. An individual can spend credits from their individual subscription or from the organization subscription with the rules that we consider (e.g Having a X role at the org).

The link between an organization and its members I think is straightforward to implement from this point so there's no need to implement yet:

• There will be an organization and organization_members table through which users could belong from 0 to N orgs.
• Then, orgs will have google drive's "Shared drives" that would be in database organization_shared_objects.

I don't see desirable to merge object_ownership and organization_shared_objects tables through some level of abstraction because I see them as two different things.

[clostao]

Btw, I misunderstood sth in the issue #8 the limits are intended to be monthly limit instead of a fixed limit, I have to update that aswell. The prev comment still applies

[clostao]

Updates:

As we discussed internally, a single-member organization is created when a user "onboards" (signs up). Each organization has a subscription that has passed from having a counter of downloadLimit and uploadLimit to have a limit and a granularity (the frequency with which that limit is renewed).

For accounting the uploads and downloads there is the table interactions that it's used for calculating the remaining credits.

[marc-aurele-besner]

LGTM