Skip to content

Conversation

@kaynnan
Copy link

@kaynnan kaynnan commented Feb 19, 2024

Hack para ignorar a condição de if, colocando um pass para que de continuidade no processo de migração

cc @marcelsavegnago

aj-fuentes and others added 16 commits February 2, 2024 07:33
Prevent an infinite loop when the cycle in the parents does not contain
the starting id: `3->2->1->2->1...`

Example:
```
>>> m=self.env['ir.module.category']
>>> c1,c2,c3 = map(m.browse,[1,2,3])
>>> c2.parent_id = False
>>> c3.parent_id = False
>>> c1.parent_id = c2
>>> (c3|c2).parent_id = c1  # this never ends
```

With current patch the call to `_check_recursion` successfully detects
the new cycle.

closes odoo#151961

X-original-commit: e7c6445
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Correct/improve the view of the point of sale configuration
by hiding certain unnecessary parts for certain user groups.

closes odoo#151305

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Context: upgrade script calling `recompute_fields(cr, "sale.subscription.line",
["price_subtotal"])`. It was noticed that this update step runs a long time and
is not limited by the DB, but CPU-limited in python. Profiling the code showed
that 94% of the execution time is spent in the `filtered()` call in `map_tax()`
of model `account.fiscal.position` during this upgrade. The profile also shows
that this whole code path effectively creates deeply nested loops, leading to
3.6 **billion** calls to the `lambda` passed to `filtered()` with only ~4k rows
on model `sale.subscription.line` (upg-1218044).

The idea of this improvement is to - by the grace of `read_group()` - build a
dict of ids that maps tax_src_id to dest_ids outside of the loop over `taxes`
and then build the result only through lookups from that dict, reducing the
loop nesting by two levels.

Using cProfile again, it shows that the average runtime of `map_tax()` is ~6x
faster with the patch (16.7ms vs. 2.8ms). For above cited upgrade, the process
is no longer CPU limited and the runtime of this step is reduced from ~8h to
~3h, which is significant enough to be relevant for upgrades. Considering this
code is unchanged on branches up to `master`, this should also reduce response
times in normal operation, when recomputations involving multiple calls to
`map_tax()` are triggered by user action.

closes odoo#151455

Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>
The version of werkzeug installed can vary from one deployment
to another, as we recommend to use the operating system package,
and the version can therefore change according to the operating
system version.

e.g. the werkzeug version installed using
`apt install python3-werkzeug` varies between
Ubuntu 18.04, 20.04, 22.04, 23.10, ...

We want to keep under control the attributes
developers use on werkzeug.wrappers.Request,
to avoid compatibility issues from one
version to another.

Therefore, this revision aims
to subclass werkzeug.wrappers.Request to limit
the attributes which can be used.

task-3734305

Part-of: odoo#78857

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since db922a6, it could happen that the
aggregated `dest_ids` array from `read_group()` in
`account.fiscal.position.map_tax()` contained `None` elements. These
None elements are added to `result_ids` by the current set
comprehension. In that case an exception is raised from
https://github.com/odoo/odoo/blob/1305e87a3873970ee5c0aa21bc749ba33375e517/odoo/models.py#L6176
after passing `result_ids` to `browse()`.

opw-3742597
opw-3742305
opw-3742596
opw-3742217

closes odoo#153879

Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>
Previously, exporting BIS3 when there is a 0% tax in the invoice will
results in the XML showing warning of UBL-CR-601. But if we do not
include any TaxExemptionReason reason at all, a fatal error BR-E-10 will
pop up.

Here is the details of those 2 rules:

```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
      <assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
        exists(cbc:TaxExemptionReasonCode)">
          [BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
          "Exempt from VAT" shall have a VAT exemption reason code (BT-121)
          or a VAT exemption reason text (BT-120). </assert>

and

(no context)
<assert id="UBL-CR-601" flag="warning" test="
  not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
       cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
          [UBL-CR-601]-A UBL invoice should not include the InvoiceLine
          Item ClassifiedTaxCategory TaxExemptionReason </assert>
```

Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax)
  in TaxTotal/TaxSubtotal/TaxCategory

Previously, the TaxExemptionReason will appear on both places.
This commit fixes that and adds a test to ensure that when a 0% tax is
present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory

closes odoo#154055

Task-id: 3703206
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants