If you use electronic terminal, electronic ticket is not save in database.
I you want reprint the ticket, electronic ticket is not present in the reprint ticket.
closesodoo/odoo#73919
X-original-commit: 08583840604e71f18f3b98b6dc8d4fa04f502689
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When installing some modules, if an other action is undertaken around
the same time it is possible for the two to deadlock, leading to the
two workers being killed by the wallclock limit watcher. This should
only be an issue on the *threaded* server, workers should not be
affected, meaning the issue is not reproducible on runbot.
A relatively reliable way to trigger this issue manually is to create
an empty database, on the "apps" kanban view install the "sales"
application, and as soon as the UI gets unblocked install the "CRM"
application. An other method (also reliable but not really doable by
hand) is to simultanously log in and install the sales
application (`sale_management` module).
The core of the issue seems to be in `_button_immediate_function`:
1. `Other` has an env ready for use and has accessed various
models (so has pretty shallow locks on the tables e.g.
ACCESS SHARE).
2. `Install` takes the registry lock to create the new registry.
3. `Install` needs to update one of the tables `other` has touched,
starts waiting on the `ACCESS EXCLUSIVE` lock (the only one
`ACCESS SHARE` conflicts with) in order to execute DDL (most `ALTER
TABLE` forms require exclusive access to the table).
4. `Other` needs a new environment (e.g. `sudo()`, `with_user`,
`with_context`, ...), starts waiting on the registry lock.
At this point the two threads are deadlocked, `other` waits on the
registry lock which `install` holds, while `install` waits on a table
lock which `other` holds. Since one of the waits is on the application
side, Postgres' deadlock detector can not notice the issue. That one
of the locks is on the Python side is why only the threaded
server *should* be affected.
An initial seemingly promising mitigation attempt was to
LOCK res_partner IN ACCESS EXCLUSIVE MODE
in the prelude of `_button_immediate_function` as `res.partner` is one
of the most commonly modified models, this would force
`_button_immediate_function` to wait until all existing requests have
completed and prevent later requests from progressing.
This turns out to be unreliable, as later requests could already have
acquired an environment and would race ahead as soon as the
transaction is committed if the scheduler lets them. Trying to lock
the registries earlier doesn't work as the locking is interleaved in
normal operation and we'd just deadlock there. The commit is because
`load_modules` does not take an externally provided cursor and instead
creates its own (thus its own connection and transaction). And because
of its lack of atomicity the issue might occur regardless.
An alternate mitigation is instead to set (or drastically reduce) the
lock wait delay during module installation, installation should
normally be entirely uncontended (or infeasible in production with
large traffic) so there is limited reason it'd be waiting several
seconds on a lock. Conveniently, this means instead of the thread
being killed entirely, the install request gets aborted *and retried*,
so it can succeed a little more slowly if that allows the other
request to complete and no other concurrent request causes the same
issue.
Other alternate mitigation which got discarded: reusing registries
when creating new environments (from existing ones) if the database is
the same, that works for some case of switching environments, it
doesn't work for other where we actually fetch a registry e.g. assets
generation calls `get_modules_order` which calls `module_boot` which
calls `module_installed_bypass_session` which gets a
registry. `get_modules_order` is the last place we know we have an
existing registry. Though maybe we could strip out the entire thing
and call `module_installed(self.env)` directly?
Issue 2581648
closesodoo/odoo#73906
X-original-commit: ab84d970dcf1a9dbd5697b6600930cd1bcba3634
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Install "Sales" module (for test purpose)
- Active `External Email Servers` email feature and set an alias
- Go to any Sale Team, and set an Email Alias
- Send an email (from outside Odoo) to the sale team email alias
- Write the body text in hebrew
- !must ensure that the mail is encoded in iso-8859-8-i.
- Go to Settings -> Technical -> Messages and open the receveid mail
Issue:
Hebrew character are replaced by `�`.
Cause:
Python does not have -e and -i codecs.
More info here: https://bugs.python.org/issue18624
Solution:
Create an alias for iso-8859-8-i == iso-8859-8.
opw-2482579
closesodoo/odoo#73934
X-original-commit: 632ed24936000cfb4cb3296a25ff6195a89109a0
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Currently, pricelists can be deleted even if a pricelist rule uses this pricelist as base.
This leads to an error when the rule is used because it tries to access a deleted record.
This commit restricts the deletion of such pricelists, avoiding later tracebacks.
closesodoo/odoo#73907
X-original-commit: 8c3c7d9e85ca4353d3b8501cc5c484a3bd955754
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: vfe-odoo <Feyensv@users.noreply.github.com>
Currently, contactus page is dynamic (Google map snippet, Company Data, Contact Form), in order to make it static :
- Company data snippet has been removed and replace by static data
- Google map snippet has been removed
- Website_form module has been merged into website (before, the module needed to add data into contact us page which was not static)
- Pre-fill option has been added to s_website_form snippet and all website_form dependencies have been updated to add "fillWith" attribute during form model registry.
- Finally, contactus-thanks has also become static !
Enterprise: https://github.com/odoo/enterprise/pull/18242
Upgrade: https://github.com/odoo/upgrade/pull/2452
task-2462993
closesodoo/odoo#69888
Related: odoo/upgrade#2452
Related: odoo/enterprise#18242
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
- fixed xml data files order, otherwise form field would not be whitelisted,
including `email_to`, so the mail would not be send.
- add the same data-for behavior from website_crm to website, to be able to
prefill a field with an URL param
- removed the fallback data-for in website_crm, the JS in now in charge of
doing that. Plus it was creating a misheavior -> you could have prefill set
to false but still, it would prefill the user info
- fixed the form option so the field.name is not used as field.string if there
is already an explicitely set field.string..
- adapt field name in /contactus form (xml view), form snippet (registry) and
crm form (registry) for more consistence
- added the prefill option set to true by default on /contactus (to fit what
we had before). This came with a change in the test as we don't need to
enable it anymore.
- added also the prefill option to true by default on form snippet
Part of #69888
task-2462993
Before this commit (and the previous ones that prepare it), the contact
us page was largely editable but not entirely. The automatic address
field on the right column prevented the page to be considered like any
other page and only the left column was editable. That led to less
possibilities and difficulties to make a modern contact page.
Now, the whole page is static, like a page the user would have created
himself. Same for the thank you page. This comes with the disadvantage
of having to handle the address by yourself (but that's not a field that
would normally change a lot anyway) and the website_crm app now needs to
be enabled on the form via edit mode after install to change the form
action to lead creations.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
*: website_crm, website_form_project, website_hr_recruitment,
website_sale
Replace website_crm specific behavior by another option for all website
forms.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
*: crm_iap_lead_website, website_crm, website_form_project,
website_hr_recruitment, website_sale
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
If the buyer is Italian, it must have a zip code of length 5.
If the buyer is not Italian, the zip code is optional
closesodoo/odoo#73883
X-original-commit: 86aa7507b0d86bd13dba303c75821048d420f647
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
When using another language than English, the UID of a POS order may be
incorrect
To reproduce the error:
1. Open a POS's configuration and enable "Manage Orders"
2. In Settings > Languages, add ans switch to:
- French (BE) / Français (BE)
3. Start a POS session
4. Process an order
5. Open the orders managers
Error: the processed order is named "Commande de 00001-001-0001", the
"de" in the middle shouldn't be present
This is the combination of "Commande" and the UID of the order. The
latter is extract from the POS reference, which looks like "Commande
00001-001-0001" by removing the first 6 characters. It's ok in English:
from "Order 00001-001-0001", we have "00001-001-0001". But this won't
work in all other languages (specially for RTL languages)
The unique identifier of an order is a sequence of 12 digits:
https://github.com/odoo/odoo/blob/3e8d921318e86631b73c8c92c2e462fd0d761582/addons/point_of_sale/static/src/js/models.js#L2865-L2868
Knowing this, we can easily extract the UID from a POS reference
OPW-2538645
closes#71181closes#71182closesodoo/odoo#73876
X-original-commit: f5b23781cdf8a9e50c9a1fcd38ec704d4a4513fb
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Previously, loading the login page with no modules installed would
result in a crash, because the translation service assumed that there
was always a cache_hashes key in the session info. This is not the case
when the http_routing module is not installed.
This module fixes that by adding a fallback for those cache_hashes in
the translation service.
closesodoo/odoo#73874
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Currently we can write a review in the slide fullscreen view.
But if we click on the button "review", we are redirected to the reviews
page. Instead, we want to open the rating composer and to stay in the
page.
Technical
=========
Add the dependency "portal_chatter.xml" from portal rating on the portal
composer Widget. It already has the dependency "portal_chatter.xml"
from the simple portal module, but because the second file was not in
the dependency, the view was not inherited and we were not able to rate
the review.
Add a new option on the portal rating composer, "hide_rating_avg" in
order to hide the global rating on the button and allow to fully
customize the button to have the same look as other buttons in the same
view.
Task-2322583
closesodoo/odoo#62872
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Remove the flicker of the "portal rating" widget when we load the page.
Specifications
==============
Currently, the portal rating widget is composed of 2 parts
- A Python template
- A JS template
There's also 2 widget, one widget who is linked to the Python template
and which instantiate another widget (which will render the JS template).
That's why we have a flicker, the button of the widget is rendered in
Javascript.
The purpose of this commit is to simplify that, to have only 1 widget
and to have as munch as possible in the Python template.
Technical
=========
We still need 2 different template (Python / JS) because in the
non-fullscreen view, after editing our review, we do not want to refresh
the page, but we want the average rating to be updated.
Task 2322583
Fetching all the groups from the DB causes MemoryError on some DBs
Example Accounting > Accounting > Journals > Miscellaneous menu:
```
Traceback (most recent call last):
File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 176, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 267, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 380, in mock_view_tree
self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 425, in mock_web_read_group
data = model.web_read_group(domain, fields_list, group_by, limit=limit)["groups"]
File "/home/odoo/src/odoo/14.0/addons/web/models/models.py", line 96, in web_read_group
all_groups = self.read_group(domain, ['display_name'], groupby, lazy=True)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 2248, in read_group
result = self._read_group_raw(domain, fields, groupby, offset=offset, limit=limit, orderby=orderby, lazy=lazy)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 2387, in _read_group_raw
result = [self._read_group_format_result(d, annotated_groupbys, groupby, domain) for d in data]
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 2387, in <listcomp>
result = [self._read_group_format_result(d, annotated_groupbys, groupby, domain) for d in data]
MemoryError
```
This issue was observed during the upgrade requests upg-18830, target
14.0; and upg-61934 (legacy), target 13.0
The issue can be reproduced on a clean DB with just account_accountant
installed and ~2 millions account moves on a Misc journal.
closesodoo/odoo#73855
X-original-commit: a9b3d9cf9bfd2bf4c9b0904059f1606ad6e04ee4
Signed-off-by: Christophe Simonis <chs@odoo.com>
Purpose
=======
Currently we can write a review in the slide fullscreen view.
But if we click on the button "review", we are redirected to the reviews
page. Instead, we want to open the rating composer and to stay in the
page.
Task-2322583
When the user is not in en_US language, unit_name is always different of Unit
opw:2581462
closesodoo/odoo#73847
X-original-commit: 2da20136988afaa93f472da4726091452c61cd37
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Purpose
=======
Add a new option on the portal rating composer, "hide_rating_avg" in
order to hide the global rating on the button and allow to fully
customize the button. Also allow to customize the text style and to
add an icon on the button.
Add the dependency "portal_chatter.xml" from portal rating on the portal
composer Widget. It already has the dependency "portal_chatter.xml"
from the simple portal module, but because the second file was not in
the dependency, the view was not inherited if we add the widget in a
fullscreen view.
Task 2322583
The view is broken because read_progress_bar() calls read_group() with
two groupbys in eager mode. The method read_group() is overridden for
model `note.note` and does not handle that case: the returned result is
incorrect. We modify the override to call the default read_group() in
that case, which eventually fails and makes read_progress_bar() fall
back on its naive implementation.
closesodoo/odoo#73839
X-original-commit: 6443e22feea914639f143a94a802b52a74a8ce19
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit fixes the performance issue in getting statistics for
``activity_state`` (colored clock icon for overdue/today/planned) in
CRM. The query has been tested for several years on a large database
(Odoo's own production database).
Performance test on 29 K crm.lead records (activity_state):
With a filter for 10 records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 25 | 5 |
| query time, ms | 12 | 95 | (*)
| remaining time, ms | 32 | 7 |
```
All records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 1326 | 5 |
| query time, ms | 1739 | 129 |
| remaining time, ms | 47934 | 17 |
```
As we can see in the last results, the time went from almost 50 seconds
(not responsive at all) to 150 milliseconds (responsive). The time
increase in (*) may be caused by imperfect measurements, which are raw
and not averaged measures.
---
opw-2346901
task-1915411
X-original-commit: 1088e73c9a897902f9d2d70df980fe2a5ed23492
Co-authored-by: Nicolas Seinlet <nse@odoo.com>
The method is used to get progress per column in kanban view
(green-yellow-red-red lines in Project, CRM etc). There are two main
usages:
1. get statistics for ``kanban_state`` (red/green circles)
2. get statistics for ``activity_state`` (colored clock icon for overdue/today/planned)
Before this commit all cases were handled by calling search_read and then
counting records per group in a python script. This is very inefficient,
especially for ``activity_state``.
This new implementation relies on ``read_group`` when possible, i.e.,
when both grouping fields (kanban column and progressbar field) are
stored (case 1). It then falls back on a naive implementation inside
``_read_progress_bar``. Cases like 2 above can be addressed by
overriding ``_read_progress_bar``.
We also added some minimal test to ensure that we don't break anything.
1. Performance test on 60 K project.task records (kanban_state):
With a filter for 6 records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 8 | 5 |
| query time, ms | 11 | 7 |
| remaining time, ms | 21 | 9 |
```
All records:
```
| measurement | before | after |
|--------------------+--------+-------|
| number of queries | 67 | 5 |
| query time, ms | 300 | 55 |
| remaining time, ms | 1780 | 12 |
```
---
opw-2346901
task-1915411
X-original-commit: 153621bdbab94a2a94a5bbfcabb4111cbc5970d8
Co-authored-by: Raphael Collet <rco@odoo.com>
PURPOSE
This commit aims to apply some cosmetic changes on the mass mailing
tree view to improve its usability.
SPECS
- New precedence order for the mass mailing views: With the kanban view,
mailings tend to pile up. When there are a lot of mailings, it can become
tricky to find a specific mailing given that the names of the mailing are
often generic and redondant (e.g. "Don't Miss Out", "Special Offer", ...)
For this reason, we will encourage people to use the list view by giving
the list view a higher precedence over the kanban view.
- Add progress bars for the delivered rate and the open rate (in the tree view).
- New column order for the tree view.
- Remove the unused and invisible field 'mailing_type' from the tree view.
- Set the fields 'mailing_model_id' and 'campaign_id' as optional.
- Minor decorator update.
LINKS
Task id: 2588188
closesodoo/odoo#73276
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds placeholder for the event name, and 'daterange' widget
on 'date_begin' and 'date_end' fields on the quick create kanban view
for the events.
TaskID-2584118
closesodoo/odoo#72906
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a task is created from the website form, if the user is logged in, add it
as the partner on the task.
task-2366706
closesodoo/odoo#71794
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Inserting text that contain multiline does not work.
One "\n" is removed.
Two "\n" become only one.
Task ID: 2602881
closesodoo/odoo#73835
X-original-commit: 89450137653526d9947bc21410cc4163e8b9b440
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Purpose
=======
If the counters are enabled, this could lead to inconsistent counts,
as the session context (with allowed_company_ids) is not passed, and the
multi-company rules are not applied properly if we fall back on another
company that the ones on which the user is logged.
Florent de Labarre