Readonly email fields break the layout if the value is long enough
Steps to reproduce:
1. Install CRM and Studio
2. Go to CRM and open any lead
3. Change the lead email and make it too large for the field size
4. Toggle Studio, in the View tab, uncheck 'Can Edit'
5. Close Studio
6. The email overflows its expected position
Solution:
Put the email field inside a grid layout div
opw-3248361
closesodoo/odoo#121020
X-original-commit: 855e72af9907cbfdcf1a0debd8011be9934eeb8f
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
on clicking the graph view of the Partnership Analysis, currently the tree
view and form view is opened. actually the tree and form view for this model
are not defined in the code and thus the end user get the tree view with only
ID field in it.
As those view have no sense, prevent from jumping on those.
closesodoo/odoo#121007
X-original-commit: 82a9900633b2cfc98d1d96146645646f0d5d70d2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a test spawning a datetime field in an editable list
view would crash randomly based on the assertion that a datepicker
should not be in the DOM after clicking on that field.
This is wrong however since a click triggers a focus, which is the
condition for the picker to open, althouth this mostly happens after an
additional animation frame because of the way the list works (field
becomes editable on next render -> picker then opens on next render).
This commit adds a nextTick delay after clicking on the cell to restore
the intended behaviour, which is to wait for the picker to open.
closesodoo/odoo#120999
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When one customize a course by adding the 'buy now'
button. Both the 'Add to cart' and 'Buy now' button
doesn't fill the container width.
This commit fix this by changing 'btn-block' class
by 'd-block'.
See commit eee625bbb0
Task-3299234
closesodoo/odoo#120986
X-original-commit: 77d8bc4e9ed5925967294e89440cf667b26b4cbf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”
Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered
Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.
opw-3300559
closesodoo/odoo#120983
X-original-commit: a6666de7f492f9f94abc23a080134dd473d0dddc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Issue 1: before this patch it was impossible to create a manual model
marked as "Is blacklist". The reason is that a blacklist model
implicitly need an `email` field, but such field is impossible to add in
a manual model: the field must start with `x_`.
Solution: append `x_` to the implicit email field. Note, in principle
the user gets an error if `x_email` is not present. Solved by adding the
field when creating the custom model. Ideally we should show some hint
in the interface to make it more user friendly. That is out of the scope
of this patch.
Issue 2: when we have a manual model that is mail blacklist it's
impossible to create its model class. We get an error because the MRO is
not correct. The reason is that we are adding `mail.thread.blacklist`
_after_ `mail.thread` in the `_inherit` list. That list is used to
generated the `__bases__` of the model class[1]. According to Python's
MRO rules[2], since `mail.thread.blacklist` appears after `mail.thread`
as parents of the custom model class this order _must_ be respected. But
`mail.thread` must appear _before_ `mail.thread.blacklist` because the
latter inherits from the former. This is a contradiction and the MRO
algorithm cannot succeed. To put it in a simple example:
```py
class A: pass
class B(A): pass
# This fails:
# class C(A, B): pass
# The right order is:
class C(B, A): pass
# Equivalent to:
class D(B): pass
# C and D have the same MRO linearization excluding themselves
assert D.mro()[1:] == C.mro()[1:]
```
Example traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 464, in load_modules
registry.setup_models(cr)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 263, in setup_models
env['ir.model']._add_manual_models()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/ir_model.py", line 430, in _add_manual_models
Model = model_class._build_model(self.pool, cr)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 585, in _build_model
ModelClass.__bases__ = tuple(bases)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases BaseModel, mail.thread, mail.thread.blacklist, base
```
Solution: check if a model inherits from `mail.thread.blacklist` first.
There is no need to add `mail.thread` if inheriting
`mail.thread.blacklist` because the inheritance is already implicit.
This issue was observed during upgrades. We convert custom models and
fields into manual to allow upgrading without custom code. This causes
issues because the MRO error appears when a custom model inherits mail
blacklist.
[1]: https://github.com/odoo/odoo/blob/02f820fb0eaddbb3a4269a0967184c8aaf52c363/odoo/models.py#L585
[2]: https://www.python.org/download/releases/2.3/mro/closesodoo/odoo#120977
X-original-commit: 8848bb57ff7f086d801178c582d7f6371eeb8479
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
In delivery address, `country name` and in shipping method, `country name`
will be same and no zip in delivery address. While creating new sale order
along with product and clicking on "Add shipping", error will be generated.
Steps to Reproduce
-Install `sale_management' and 'delivery' modules
-Go to the settings and enable the 'Customer Address'.
-Go to the settings and enable 'Shipping Methods' and configure it.
-Select a shipping method and go to the 'Destination Availability' tab and
set to the 'Countries' and set to 'Zip Prefixes'.
-Create a new customer and add the delivery address of the customer in
res.partner.
-The delivery address and shipping method of the 'Countries" or 'Country'
name should be the same.
-Set the 'Zip Prefixes'
-Set the delivery address of zip code null.
-Create a new quotation and add to the customer and delivery address
-Add to the product in the sale order line.
-Click on the 'Add Shipping' or 'Update Shipping Cost' button.
A trace back will be generated.
Applying this commit will resolve this issue.
sentry-4147077852
closesodoo/odoo#120968
X-original-commit: 60d5c7d5668da542e251d7d6fb8774043cfddea8
Signed-off-by: Tiffany Chang <tic@odoo.com>
Partial revert of b15116179e71040ffa01bb35161e32b16aac477d .
This fix introduced a new bug: when creating an write-off with taxes from the bank reconciliation widget, signs were all inverted in the tax report, because that commit was forcing the values of tax_tax_invert in a wrong way.
The proper fix is to fix the computation of the is_refund field in community, so that negative repartition lines are taken into account ("debit" is a refund for a "sales" tax only for positive repartition lines, for example).
Community part is in https://github.com/odoo/odoo/pull/120152closesodoo/odoo#120924
X-original-commit: 67e789074cb00b9db6e3fd83ef92ed712b28edfb
Related: odoo/enterprise#40856
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Cash basis taxes use a distinct transition account on their tax lines; the tax account set on the repartition lines is only used when the payment is received, on the cash basis move.
In enterprise, the bank reconciliation widget allows setting a tax on the manual write-off done for a statement line. When doing so, we expect the tax to behave just like on an invoice. For cash basis taxes, this means the "final" tax account has to be used instead of the transition one ; it wasn't the case.
OPW 3255511
X-original-commit: 991fa46081296c3560bd7ca195996693a81a46b8
Part-of: odoo/odoo#120924
Before this commit, the Order button wasn't displayed due to an
incorrect comparison with a `LazyTranslatedString` object
(`this.props.actionName`). This commit resolves the issue by ensuring
proper comparison of `this.props.actionType` with the string "payment".
Step to reproduce:
- create a pos_config (bar)
- active a printer on it
- open the PoS bar
- select a table and add some product
- The orderline are green but there's not order button.
opw-3300533
closesodoo/odoo#120846
X-original-commit: a04f8ebdfb724c74531f38927a655e6aae86bc26
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116381
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116379
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116377
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116374
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116372
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116365
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116362
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116360
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115521
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115487
Task-id: 3052677
Related: odoo/enterprise#38285
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115478
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115272
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, if we try to change the action from a form view
a new record in an x2m and the new action fails to mount, then the new
record in the x2m will always have a virtual id even if it has already
been saved on the server side.
Why:
When you try to exit the form view, the form view will save the record
and not read the record because you leave the view (in the beforeLeave).
But in our case, we fail to mount the new action and so we will stay on
the form view without it doing a read to know the id of the record added
in the x2m. So the view thinks that the x2m still contains a virtual record.
Solution:
Going back to action should rebuild the whole compound. To cause this,
we'll restore the last controller.
How to reproduce:
- Going to a form view with an x2m field and a widget performing a doAction
- Add a line to the x2m
- Click on the widget to change the action
- New action fails to mount, it returns an error
- Close the error dialog
- Edit another field
- Save the form view
Before this commit:
The new line in the x2m is duplicated.
After this commit:
The new line in the x2m is unique
opw-3193765
closesodoo/odoo#120765
X-original-commit: 72f68e2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This pr fixes a bug where a validation error occurs in the timesheet
wizard.
Indeed, when the user enter manually a start or end date in a workorder,
the whole MO becomes "plan".
The problem here was that if the user opens the wizard of another
workorder (on the same MO) that has no start/ end date set, and then if
he saves (no matter if he changed something), it will trigger a
validation error because the start and end date of the workorder is
required in that view if the MO is planned.
closesodoo/odoo#120386
X-original-commit: c9728858aa46e6cb1a3d39cbc8da8e175007e456
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
On the manufacturing order, modifying the timer value does save it's value
in db but does not actualise it in the front.
The "rerun" condition is already checked in MrpTimer and does not need
to be checked in MrpTimerField
closesodoo/odoo#120385
X-original-commit: a8cfa1d26ef84aa6690d3cfa8b98b6cecf4f27d9
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Description of the issue/feature this PR addresses:
Before this commit assign_me button and clock icon from start button is shown in
project task , project sharing as well as helpdesk ticket.
This commit remove assign_me buttom and clock icon from start button in project
task, project sharing and helpdesk ticket.
task-3292056
closesodoo/odoo#120378
Related: odoo/enterprise#40630
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit introduces a "_is_portal" method complementary to the existing
"_is_internal" and "_is_public".
The goal is to ease usage through the code base and be able to easily
distinguish our 3 main use cases: public, portal and internal users.
Task-3056280
closesodoo/odoo#120827
Related: odoo/enterprise#38575
Related: odoo/upgrade#4575
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently the summary and description in event ics file generation
are set directly, with a condition in case the event is an appointment.
We make these two ics 'fields' use a getter so that it can be
overriden inside appointment instead.
In addition we remove the special formater for 'online events'
as it is only used for appointments, which does not use it anymore
as of this task
task-3232952
closesodoo/odoo#116211
Related: odoo/enterprise#38570
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115268
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114838
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114755
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114700
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114696
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114694
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes names so that it's more clear for users
closesodoo/odoo#114673
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we have changed the Taxes names so that it's more clear for users
closesodoo/odoo#114653
Task-id: 3052677
Related: odoo/enterprise#37914
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes names so that it's more clear for users
closesodoo/odoo#114571
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the tax name of generic taxes
closesodoo/odoo#114537
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, when the user changes the state, the followers
receive a notification about this change. Since the label of the
state is no longer customize by stage, the followers cannot know
in which stage the task is before clicking on the link to go to
the task form view. And so, if one of those followers has to
check the task in a specific, he has to click on the link in
the notification to know in which stage the task is.
This commit fixes the issue by adding the curent stage in the
notification to inform the user who received the notification
in which stage the task is when the state has been changed.
task-3284597
closesodoo/odoo#120959
X-original-commit: d78c79d9a9f8ac108251c57c732cfb5b71b53fd5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since [1] when the fuzzy search was introduced on website pages, the
filtering on most specific pages only happens at the end of the search
operation. Because of this, the search happens on pages that would be
excluded anyway, the limit might be wrongly applied and the count might
be wrong.
This commit makes the page search begin by keeping only the most
specific pages, then performing the actual search within those pages.
Steps to reproduce:
- Install `website` only and drop a search snippet.
- Search "ax".
=> No results found, but the "All results" link is displayed.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-3203794
closesodoo/odoo#120950
X-original-commit: 9725a14be22ad0f20bb6591054b60d91663ca88f
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
In the case of draft pickings/MOs, the reception_report_main
component's "Assign All" button was NOT disabled, which could result
in an IndexError if the button was pushed. Note that this issue does not
occur for the "Assign All" button within a table because the button is
correctly not shown at all when there are no assignable lines within it.
Noticed during task: 3046178
X-original-commit: 403d1ba5839d6073ee6321e77863f928336158ba
Part-of: odoo/odoo#120935
Steps to reproduce:
- activate Reception Report in settings
- create outgoing picking for a product (qty > qty in stock)
- create an incoming picking for the same product with a non-int qty
- confirm the incoming picking + click on "Allocation" smartbutton
- assign product to outgoing picking + click "Print Labels" (either at
top of report or within the table of outgoing moves)
Expected result:
Labels and created + printed
Actual result:
ValueError because int() is called on a non-int value within the label
template
Note that the the `onClickPrint` within the reception_report_line.js
already correctly did the Math.ceil rounding on the qty
Noticed during task: 3046178
X-original-commit: 69c557a5c0b407333be45cd7434448fc36de899e
Part-of: odoo/odoo#120935
Before this commit, when having a x2many field invisible in a view, and displaying
it anyway in studio, there was a crash because some variable was undefined.
This originated from commit f22961a, which did not account
for the fact that viewMode is an optional props.
After this commit, the util function used by the x2m field and where the
crash occur has been refactored.
Moreover, the x2m field template has also been slightly refactored.
closesodoo/odoo#120918
Taskid: 3305808
Related: odoo/enterprise#40852
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Current behavior:
When settling a pos order containing 2 different product, the qty of the
2 products would be modified even if you only deliver one of them
through the pos order.
Steps to reproduce:
- Create 2 product A and B
- Create a sale order with 1 product A and 1 product B
- Open a PoS session, and settle the order you just created
- Deliver only 1 product A
- Close the PoS session
- Go the the sale order delivery, you will see that the qty are not
correct
opw-3227053
closesodoo/odoo#120898
X-original-commit: c1f905111060fff6e6bdfae1849e1a633a88ae02
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
*: project, web
This commit adds the title and aria-label attributes to the activity
button. This makes the hover display the summary or an explaination
about the button, especially when there is no text displayed next to
the button (in Kanban view).
In the state selection field, a title has been added when hovering
the state in kanban, allowing to see the current value. The project
task state selection has also been adapted to have that title attribute
set on the toggler.
task-3207639
closesodoo/odoo#120871
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When generating the routing map, `Rule.add` will call
`Rule._compile_builder` twice, representing almost one third of the
routing map generation time. `_compile_builder` is actually stored
in `Rule._build` and `Rule._build_unknown` for latter use, in the
`Rule.build` method.
The `Rule.build` method is used to transform a rule, lets say
`/forum/<model("forum.forum"):forum>` in `/forum/basics-of-gardening-2`
Even if a deeper investigation could be interresting, it looks like it
is only used for `is_frontend_multilang` routes and `_enumerate_pages`,
used in the `sitemap` and `search_pages`.
The proposed solution si to make this part lazy, in order to call
_compile_builder on demand, once per rule. This will speedup the initial
routing map generation and postpone the heavy work when we need it,
only for the part we need most of the time.
On a database with all modules installed, generation of the routing map:
Before: ~600 ms
After: ~200 ms
An alternative implementation was also overriding the Rule.build method
instead of having a callable LazyCompiledBuilder, this implementation
was choosen since it is less dependant off the werkzeug implementation.
closesodoo/odoo#120542
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
`re` is using an internal cache for regexes with a default size of 512
This is correct for small apps running on small infrastructure
but as a simple example, the routing map will compile ~1100 regex in a
row. This means that generating two routing map in a row don't benefit
from this cache at all. It looks reasonnable to increase this limit
globally for odoo.
This is visible when generating two routing map in a row.
After this change:
Generating routing map for key None
Routing map web generated in 0.194s
Generating routing map for key 1
Routing map website1 generated in 0.196s
After this change:
Generating routing map for key None
Routing map web generated in 0.200s
Generating routing map for key 1
Routing map website1 generated in 0.062s
Part-of: odoo/odoo#120542
Sending invoice in emails to customers now display View Journal Entry in
v16.2 instead of view Invoice.
Steps to reproduce the error :
1- Install accounting
2- Go to accounting/customers/invoices
3- Create an invoice and send it by email to the customer
4- View The email on mailhog
The reason of the error was becayse we didn't provide model_descirption
to the function of sending the email, so it will take the one by default
whch is Journal Entry.
opw-3289880
closesodoo/odoo#120480
X-original-commit: 21cab7ffa6a71a67b64d3a7e7a62a6599127343d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
MerlinGuillaume