Jarbas must accept federal senate suspicions

[jtemporal]

For a while now Rosie is capable of generating suspicions for the Federal Senate. But that suspicions are not reflected on Jarbas.

Talking with @cuducos we agree that the following might be a roadmap for the update:

• create a new app called chamber_of_deputies
• move jarbas.core.models to jarbas.chamber_of_deputies.models
• move the api to the new chamber_of_deputies app
• change APIs URLs ⚠️
• change jarbas.core.management.commands to jarbas.chamber_of_deputies.management.commands
• create app federal_senate
• add a ReimbursementModelAdmin in the dashboard/admin.py With Federal Senate models to show it on the dashboard

TLDR move everything from core and api to a new app and create a new app for the Federal Senate and add it to the admin ; )

[giovanisleite]

I can help 😬

[giovanisleite]

Following this roadmap,
First PR first (the first five points)

1. Core dies, right?
2. the api urls changes from e.g. reimbursements/lalalala to chamber_of_deputies/reimbursements/lalalala

These questions sound dumb, but its good be sure about it hahaha

[cuducos]

Hi @giovanisleite,

Core dies, right?

I don't think so… we still have stuff unrelated to any application (e.g. chamber_of_deputies and/or federal_senate) that could live in core: importing company data, mapping URLs from the root to whatver_app/urls.py etc…

the api urls changes from e.g. reimbursements/lalalala to chamber_of_deputies/reimbursements/lalalala

That woks pretty well I guess. This way later might add, for example, we could have amendments. So I would fo for:

• /api/chamber_of_deputies/reimbursements/
• Later we might have /api/chamber_of_deputies/amendments/
• Or /api/federal_senate/reimbursements
• Or /api/federal_senate/amendments
• And so on…

Does that make sense?

[giovanisleite]

I don't think so… we still have stuff unrelated to any application (e.g. chamber_of_deputies and/or federal_senate) that could live in core: importing company data, mapping URLs from the root to whatver_app/urls.py etc…

Oh, sure.

Does that make sense?

Yes, it seems pretty good.

I don't know the federal_senate structure yet, but I will look into it to do something/ask about his model.

[cuducos]

I don't know the federal_senate structure yet, but I will look into it to do something/ask about his model.

That'd be awesome but TBH I don't think worrying about it is helpful anyhow to this PR. If we isolate Chamber of Deputies reimbursements logic to dedicated apps, Jarbas would be flexible enough to embrace any structure of data Federal Senate might have ; )

[giovanisleite]

move the api to the new chamber_of_deputies app

The api will keep accessing company data (core models).

So, the api structure for company, activity and future stuff unrelated to any application must be on core? what do you think, @jtemporal and/or @cuducos? -> jarbas urls maps from root to the core/api, chamber_of_deputies/api or etc..

or keep it on jarbas (the way that it is today) -> jarbas urls maps from root to api/ and api handles with it (company etc) or maps for the right app, chamber or federal etc.

I'm not sure about the best option. Maybe, there is a third one. Maintain api where it is and create the others inside it. So, jarbas maps from root to api and api maps to api/chamber_of_deputies, etc.. (This structure is more like the urls).

[cuducos]

Hi @giovanisleite,

I'm really not sure but I'd try something like:

• /api/companies/<cnpj>/
• /api/chamber_of_deputies/reimbursements/
• /api/federal_senate/reimbursements/

Although this do not have to reflect the app and modules structure. What do you think?

[giovanisleite]

What do you think?

I agree on these urls.
But i'm not sure about the app and modules structure.
Who is responsible for mapping /api/...? jarbas.core.api or jarbas.api or just jarbas?
If the first option, jarbas.core.api handles api/companies and maps for /api/whatver_app. Like in:

core: importing company data, mapping URLs from the root to whatver_app/urls.py etc…

If the second, jarbas.api handles api/companies or it has no views and maps for jarbas.core.api handles with it?

I agree on "api doesn't have to reflect struture", but the structure roots/api seems more intuitive. Although it is just an impression.

I didn't find much content about it, but applying this strategy, the struture can be:
jarbas.urls mapping requests at /api/ to jarbas.core.api and /api/other_app to jarbas.other_app.api or jarvas.urls mapping requests at /api/ to jarbas.core and jarbas.core.urls maintain all about apis urls.

[cuducos]

I'd go for each app (core for companies, chamber_of_deputies, federal_senate) with its own serializers.py and the API views in their views.py. Then another app api that imported from them and actually serves from there. Does it sound like a good idea? TBH this is only in a brainstorm phase and I haven't tested a line yet.