-
-
Notifications
You must be signed in to change notification settings - Fork 310
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
[mis_builder] generalize auto expands #397
base: 14.0
Are you sure you want to change the base?
Conversation
@TeoGoddet I don't have much time to look closely but this sounds promising!
This is probably the key thing to address as minimizing the number of db queries is a core design goal of MIS Builder (and what makes it complex - if we leave the many historical reason asides). |
Another big thing that need to be discussed is expanding by many2many fields |
Yes, expanding by m2m is impossible in the general case. Expanding on many2one is the only thing that can be made generic, and, as you, say, users can use analytic dimensions to fallback on m2o. |
89ed20c
to
08d07d0
Compare
I just pushed a new version that is closer to the goal.
|
6344a72
to
695c16c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you are making good progress :) Let me know when you think it's ready for a first review.
account = self.env["account.account"].browse(row.account_id) | ||
self.assertEqual(row.label, "{} {}".format(account.code, account.name)) | ||
if row.row_detail_identifier: | ||
account = self.env["account.account"].browse(row.row_detail_identifier) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this specific change, it might read better with something like this:
account = self.env["account.account"].browse(row.row_detail_identifier) | |
account = self.env[row.row_detail_model].browse(row.row_detail_res_id) |
Not sure.
Hi ! Thanks for the review, sorry for the noise on the CI, i could not get a working local CI.
I'm unsure about the name of the variables introduced, they are not the result of a good reflection but of the long dev process. |
42d10c9
to
91546b5
Compare
In another MR, i could propose to have the expand field to be choosen dynamicaly using a many2one to ir.field |
3e21d12
to
61095b8
Compare
Ok, got the dev tools working better so the diff should be minimal Another thing have still in mind is to rewrite the expand field selection to be dynamic (maybe another MR) |
7004841
to
4e087c1
Compare
@sbidoul the tests are now fixed, I think it's ready for review |
Thanks a lot @TeoGoddet. I'll try to review and test this in depth soon. |
Note that I tried this in a branch mentioned in #115, but it's good to have this being considered finally. One of the problems I faced was the variables everywhere are mentioning |
Tested with budgets by account. This works well. |
mis_builder/models/aep.py
Outdated
@@ -401,11 +432,11 @@ def f(mo): | |||
return self._ACC_RE.sub(f, expr) | |||
|
|||
def replace_exprs_by_account_id(self, exprs): | |||
"""Replace accounting variables in a list of expression | |||
by their amount, iterating by accounts involved in the expression. | |||
"""This method is depreciated and replaced by replace_exprs_by_row_detail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it is not used inside mis_builder anymore, let's remove it. It is unlikely that anyone is using that, and we'll do a major version bump anyway.
A few minor comments, but overall, this looks very good to me 👍 Thanks a ton for this contrib. |
def get_rdi_name(self, rdi_id): | ||
if rdi_id not in self._rdi_names: | ||
self._load_rdi_names() | ||
return self._rdi_names[rdi_id] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have done a local test and with this change we avoid possible errors.
return self._rdi_names[rdi_id] | |
return self._rdi_names.get(rdi_id, _("Other")) |
EDIT: This is necessary due to archived records, because apparently when the record is archived we don't get the id and name right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@FernandoRomera can you provide an scenario to reproduce the problem ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A possible scenario is when you add the option to group by "product_id" and you are looking at a previous year and as you don't use it anymore you have archived the product to avoid problems, but you still have to be able to see it in previous years' reports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the rest it works great, we have done a couple of tests and it makes it very easy to generate reports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so maybe it's better to search for inactive records too in _load_rdi_names()
?
rdi_id = UNCLASSIFIED_ROW_DETAIL | ||
if not self._data[key].get(rdi_id, False): | ||
self._data[key][rdi_id] = defaultdict(dict) | ||
self._data[key][rdi_id][acc["account_id"][0]] = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: understand why we group by rdi_id and then account_id and not the contrary.
|
||
def _get_rdi_name(self, rdi): | ||
result = rdi.name_get()[0][1] | ||
if self._multi_company and rdi.company_id: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if rdi
does not have a company_id
field?
mis_builder/models/kpimatrix.py
Outdated
rdi_ids = list(rdi_ids) | ||
if UNCLASSIFIED_ROW_DETAIL in rdi_ids: | ||
rdi_ids.remove(UNCLASSIFIED_ROW_DETAIL) | ||
rdis = self._rdi_model.search([("id", "in", rdi_ids)]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
search with active_test = False ?
@sbidoul I'm not forgetting about this but need some time to fix everything, thanks a lot for the review ! |
No worries. Will you be at OCA days? |
Normally Yes :) |
@TeoGoddet If you agree, I can help you and make a PR in your repo with the proposed changes. |
@AntoniRomera would be very appreciated !! |
@sbidoul @TeoGoddet Is this at a standstill? Do you plan to do the merge? |
Could be great to have this merged in 14 to port for 15 . @TeoGoddet did you got @sbidoul in OCA Days? Do you agree to get this merged? Thank you! |
@sbidoul @pedrobaeza @rafaelbn This PR has been ready for months, I still don't see why it can't be integrated, if it is to keep the history, can it be done in version 16.0 or how do you see it? |
@AntoniRomera I was waiting for answers to the questions I asked above. |
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
Hi @sbidoul, |
@AntoniRomera @FernandoRomera i wont be able to work on this for at leat another 6 months, feel free to taleover the PR |
This is very far form mergability,
it's purpose is to discuss an implementation of #115 (#392)
To do / to discuss :
how to choose which details lines to show (typicically for accounts, we need only the accounts included in the kpi expression)
We may have a domain field here :
fix the drilldown (should not be a problem)
optimisation issues
Now the PR multiply the query number by the number of details line, to solve this we would need to add a group_by clause here :
mis-builder/mis_builder/models/aep.py
Line 355 in 90702af
but that would mean a details kind could not provide a domain for each line but a field for all line
that would also automatically solve the problem of wich details line we display
(We could get back wich lines to show from aep here instead having them from the report model here :
mis-builder/mis_builder/models/mis_report.py
Line 771 in 90702af
!! TEST !!
genericity of the details line model
in the PR, i make account_account and account_analytic_account extends RowDetailIdentifierInterface
it prevent it to be compatible with account_move_line compatible model (budget, actuals, ..)
the right approach would be to encapsulate the right aml fields in the RowDetailIdentifierInterface
make it easy to extend :
split the _get_row_detail_identifiers in many get_row_detail_identifiers_for{}