Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EC-002: Working on data layer schema updates #6

Merged
merged 12 commits into from
Feb 10, 2024
Merged

Conversation

angeloreale
Copy link
Contributor

@angeloreale angeloreale commented Feb 10, 2024

PLEASE REVIEW YOUR OWN PR BEFORE OPENING/UN-DRAFTING IT

EC-002

(add link to ticket later)

As the final back end step for this ticket, we need to be able to:

  • define the authorization model
  • define the authorization flow

This PR updates the types and schemas to ensure that:

  • we have a data model that serves the flow we have architected.
  • we have this model enforced in the default org (default service, default feature)
  • we have this model mapped to a schema that is enforced by default when a new user signs up (gets added to default org with default role and abilities)

Here is the full flow model:
image

Here is the model we're aiming to achieve with this PR (skipping some view actions, but using the same model):

image

Screenshots/Videocasts/Preview Links

Have you?

  • Reviewed your own PR?
  • Tested your own feature/fix meets Acceptance Criteria?
  • Made sure it passes all checks? (lint, build, integrations, scripts, etc)?
  • Added screenshots? (if relevant)
  • Added unit tests? (if necessary)
  • Added documentation? (if necessary)

If so, THANKS! You can pop a beer/soda.

Please open your PR and ping your colleagues to review it on #web-devs channel.

Also, make sure to remind them on a daily basis during stand-up.

lib/types/billing.d.ts Outdated Show resolved Hide resolved
lib/types/actions.d.ts Outdated Show resolved Hide resolved
Comment on lines +65 to +79
export const defaultServices = {
[EServiceNames.SERV_RM]: RMServiceSchema,
};

export const defaultProjects = {
[EServiceNames.SERV_RM]: {
name: 'myorg-default-rm-index',
status: 'active',
/*
to-finish: walk the default services
service: defaultServices.get(‘rickmorty’).name,
sid: unknown (NEEDS DEFINE RELATIONS)
*/
},
};
Copy link
Contributor Author

@angeloreale angeloreale Feb 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's finish the walk

lib/model/schemas/org.ts Outdated Show resolved Hide resolved
lib/types/services.d.ts Outdated Show resolved Hide resolved
tsconfig.json Outdated Show resolved Hide resolved
@angeloreale
Copy link
Contributor Author

angeloreale commented Feb 10, 2024

can we default org to community? also, does it makes sense to have different orgs / services / features / abilities adapters/filters (toggling on/off) based on geo location for compliance / regulation?

@angeloreale
Copy link
Contributor Author

certain org/local communities;
certain services for different common orgs;
certain features for certain services/projects;
certain abilities for all above.

@angeloreale
Copy link
Contributor Author

angeloreale commented Feb 10, 2024

The Universal Fuzzy Ability algorithm (in lack of a better name), can factor in:

  • geo location;
  • age;
  • roles;
  • delegations;
  • id verified;
  • address verified;
  • income verified;
  • ... what else?

I don't think gender should be relevant, but then if we have a period tracker service/feature, could that be useful?

But then, it's PII, and it's easier to just reduce the cardinality.

What else matters for regulation?

ID verified?
Address verified?
Income verified?

...

@angeloreale
Copy link
Contributor Author

angeloreale commented Feb 10, 2024

e.g. The Vibe Modulator can have different features.
But maybe it's better to filter most on the minimum cardinality, and allow users to enable what they need from what's available.

@angeloreale
Copy link
Contributor Author

The Fuzzy Ability rules can live in the IAbility interface and we need their corresponding factor in Users and Orgs.

Copy link
Contributor Author

@angeloreale angeloreale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Since from a data layer perspective this is backwards compatible (unless we enable the schema enforcement, which is not yet tested), I think we should merge this PR and follow up with the missing bit, which is updating the relationship schema definition function in the DB interface singleton.

@angeloreale
Copy link
Contributor Author

angeloreale commented Feb 10, 2024

This is to reduce the size of PRs and review/revert overhead.

@angeloreale angeloreale merged commit 60dccb6 into dev Feb 10, 2024
3 checks passed
@angeloreale angeloreale deleted the ar/auth-hyd-flow branch February 12, 2024 21:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant