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

[FR] Architecture improvements #516

Open
Elise17 opened this issue Jul 3, 2024 · 7 comments · Fixed by #528
Open

[FR] Architecture improvements #516

Elise17 opened this issue Jul 3, 2024 · 7 comments · Fixed by #528
Assignees
Labels
enhancement New feature or request

Comments

@Elise17
Copy link
Contributor

Elise17 commented Jul 3, 2024

This issue is about the future improvements to be made on the architecture.

  • Raise the permissions checks present in the layer business to graphql, to avoid it being executed twice in layer rest.
  • Create architecture.md at the root level and start to give import that we can execute by layer :
    - blueprints : conversion from the public API to business objects (REST, GraphQL, flask templates)
    - business : work in memory with business objects (should not have adhesion with app.model, should not have adhesion with db from app )
    - datamgmt : persistence, adhesion with the database
  • Add a new rule in coding style sheet : "Function names should be prefixed by the module name they belong to, example: iocs_create_instead of create" and apply the rule in the business layer
@Elise17 Elise17 added the enhancement New feature or request label Jul 3, 2024
@c8y3 c8y3 self-assigned this Jul 3, 2024
@c8y3
Copy link
Contributor

c8y3 commented Jul 12, 2024

I believe the business layer should be able to import from app.models (if only to type the methods arguments). The business layer should not concern itself with persistence details, but still manipulates business objects which are described in app.models.

@c8y3
Copy link
Contributor

c8y3 commented Jul 12, 2024

An alternative to moving up permissions checks from the business layer into the blueprint layer, would be to have them only in the business layer (that is remove checks that are performed in the REST endpoints annotations)
If graphQL is there to stay, then that would probably be a preferable alternative, since otherwise we are coding the same checks, but in different ways (annotations for the REST endpoints and calls for the graphQL queries)

@c8y3
Copy link
Contributor

c8y3 commented Jul 12, 2024

We should add issues to clean up the forbidden imports described in the architecture.md file and currently in violation.

@c8y3
Copy link
Contributor

c8y3 commented Jul 12, 2024

Should from app.schema.marshables imports be forbidden from the persistence layer (datamgmt)?

@c8y3
Copy link
Contributor

c8y3 commented Jul 12, 2024

We should really rename app.datamgmt into app.persistence: it clearer.

@c8y3
Copy link
Contributor

c8y3 commented Jul 12, 2024

Moving up permissions_check_current_user_has_some_case_access_stricter ended up into into endpoints /case/report/generate-activities/int:report_id and /case/report/generate-investigation/int:report_id. Shouldn't these endpoints rather be annotated with @ac_api_case_requires(CaseAccessLevel.read_only, CaseAccessLevel.full_access)?

@c8y3
Copy link
Contributor

c8y3 commented Jul 12, 2024

Should permissions and PermissionDeniedError be moved up into the blueprint namespace?

@c8y3 c8y3 linked a pull request Jul 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants