So the logs contain some indication as to what was exceeding the limits.
closesodoo/odoo#37303
X-original-commit: 0a266f444a0abda026d09ad88024dca1c50c92b9
Signed-off-by: Denis Vermylen <Icallhimtest@users.noreply.github.com>
Go to Configuration > General Settings.
Before this commit:
if a setting is None, a stack trace appears.
After this commit:
a warning message is logged in this case, but there is no crash.
closesodoo/odoo#37271
Opw: 2075047
X-original-commit: ed64477d0a9fc58a577d9174a347268186eff70f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
omission in d26e253edd
kill -3 (SIGQUIT) is not processed like the other signals so it doesn't
go through this bit of code, but leaving the AttributeError lurking
there is not a good idea.
closesodoo/odoo#37221
X-original-commit: ac65ef0208a5ec814d263aeb44a98b47a5ee3947
Signed-off-by: Denis Vermylen <Icallhimtest@users.noreply.github.com>
Initial bug report, full of red herrings:
receive two support requests by email while on Odoo.sh, the first creates a
ticket, while the second replies to the server with the error:
550 Requested action not taken: mailbox unavailable
When a request is done, the service check function tries each request multiple
times when getting Operational errors.
When two email are received within a 'short' amount of time (e.g .1 second)
the two requests are initiated with a new cursor.
When both mails generate the creation of a new record of the same model,
the second cursor is going to fail because of an:
ERROR: could not serialize access due to concurrent update
However, the record we used in the computations needed in the creation of the
second record have been added to the environment.
When that second creation is retried, it will operate on the same records,
and find them in the todo, with the environment that was obtained for the first
trial. Since the cursor is closed, this crashes.
To explain the bug report, Odoo.sh transfers the mail through an xmlrpc
to process the mail.
Because of this crash, the server interprets the lack of well-formed response
by a generic 'mailbox unavailable'.
opw 2060476
closesodoo/odoo#37165
X-original-commit: 845eecdfa7b27d84862e94f4b63d40a851e0c410
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Commit c3717f3018 added a (5, 0, 0) command when modifying groups_id of any
non-internal user, to avoid the situation where the various implications would
end up giving the portal user group_user rights.
This risk is avoided by commit f206714af0, which added a constraint
check_one_user_type, which would raise in that specific case.
The last missing piece was 9badedcd98f; when groups are added through settings,
they are added through the implied_groups of the group model.
The (5,) command has the unfortunate side-effect to remove the portal group
from a user if a write is triggered programmatically.
If that happens, then the 'signing up' process end-destination is a 500 error.
Now we simplify the logic that keeping the same behaviour for implied_ids for
internal (group_user) and non-internal users.
We keep the (5,) command in one case: if a user is demoted to portal or public,
he may have groups should be reserved to internal users, but that do not imply
group_user (which would raise).
To avoid that, we remove all its groups, since there is no clear distinction
between technical display groups and actual privilege-granting groups.
opw 2041606
closesodoo/odoo#37144
X-original-commit: 29723e351d5dc5e5ea055c80da86f4e871909de9
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In some cases, after installing a new language in rte_translator tour,
some query using ir_translation table will become very slow.
Identified query:
SELECT res_groups_users_rel.uid, res_groups_users_rel.gid
FROM res_groups_users_rel, "res_groups" LEFT JOIN "ir_translation" as "res_groups__name"
ON ("res_groups"."id" = "res_groups__name"."res_id"
AND "res_groups__name"."type" = 'model'
AND "res_groups__name"."name" = 'res.groups,name'
AND "res_groups__name"."lang" = 'en_US'
AND "res_groups__name"."value" ! '')
WHERE 1=1 AND res_groups_users_rel.uid IN (2) AND res_groups_users_rel.gid = res_groups.id
ORDER BY COALESE("res_groups__name"."value", "res_groups"."name") OFFSET 0´
During post_install this query will become slower (between 0.7 and 2 seconds) ~50%
of the time, when this usually take less than 0.1 second.
For some tour step, this query is executed several times, making a simple
/web loading going from less than one second to more than 10 second, breaking the tour.
The main intuition behind that would be that the query plan completely fails,
mainly because postgress is to busy and doesn't have time to launch an analyse
when runbot load is high.
This commit proposes to execute a manual ANALYZE on ir_translation table
after a new language is installed. Tested with 40 builds, rte_translator never failed
with this fix.
cherry-pick of fc5934dc45closesodoo/odoo#37013
X-original-commit: 57f91453cb567d8a7a29137b321a630fe0dbb9a6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit 5f12e244f6, the write of implied groups is done directly in SQL,
bypassing the ORM writes, and thus bypassing the python constraints checks.
In particular such a constraint was added in f206714af0.
We add back an explicit check of this constraint;
however we rewrite it in SQL to be fast.
closesodoo/odoo#35411closesodoo/odoo#36769
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
For contract of type 'Company' which have no image set, we should display a
specific default 'company' placeholder image instead of default placeholder.
This allows to easily identify which records are companies.
This was already the case up to commit 6153d65664
OPW-2067475
closesodoo/odoo#36783
X-original-commit: 42c08846296d86fb3196f430eec45dd39cf1a8f5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When .with_context() is called with a dictionary as 1st positional
argument, it will replace context (and not modify the referenced keys)
It may create bugs when losing the content of the context (e.g. remove
partner's language)
This is a partial merge of #36164 without the inventory part as
discussed.
closesodoo/odoo#36729
X-forward: 4717ccfa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Simple typo; instead of a logger message, an exception is output in the logs.
closesodoo/odoo#36686
X-original-commit: 83030b6ae20bc9d32b2c7a83ea5a1dca33e5f9cf
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The name and address printed on any PDF report (e.g. SO or RFQ) is very
likely to be split on 2 lines once it is long enough. For example,
'My Company (Chicago)' will be displayed on 2 lines.
This is due to 0c6e0d660e and 064eb0a4f4.
opw-2061553
closesodoo/odoo#36498
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the barcode Qweb Field had a
option called "type", which meant what is the mapping between
numbers and barcode, that mapping is called a symbology
https://www.barcoding.com/resources/barcoding-basics/barcode-symbologies/
This option "type" collided with what the qweb engine does
at
```
qweb > _compile_directive_field
that calls
ir_qweb > _get_field
```
It resulted in a crash where type = "barcode" was not a valid symbology
to pass to the barcode lib
It is safe to say that this barcode widget was never user, otherwise it would have crashed
This commit changes that non-functioning API, and the barcode renders well
OPW 2066870
forward-port of #36499 (330d862513dba5bbc4716fe9c8694fd0db696934)
closesodoo/odoo#36499closesodoo/odoo#36658
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Some model can have really complex _order, which can induce unnecessary slow
queries; here as we don't need the right business order we force ordering by
'id' instead
OPW-2007478
closesodoo/odoo#36660
X-original-commit: a1fe8976156a7b6e14aa2d68650176a0e64ba73f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Determine `model._rec_name` before the dependencies of the fields. The
compute method of the automatic field `display_name` uses a callable
depends that retrieves `model._rec_name`.
closesodoo/odoo#36480
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
studio
opw2062025
In some cases, when there is no attachment (on an invoice for example)
and reports have been modified with studio, the self.attachement value
is false and an error appears
closesodoo/odoo#36291
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Display your website in Right To Left
Go see the phone number of the company
Make that number in the form
```
123[space]456[space]789
```
Before this commit, the blocks of that number were inverted
(intra-group order did not change)
Leaving us with
```
789[space]456[space]123
```
After this commit, we introduce a little class to force Left To Right
display
OPW 2059917
closesodoo/odoo#36115
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
A sanitize fields by default remove all attributes outside of a
whitelist (if sanitize_attributes on field is not set to false).
This prevent to use parallax widget in Html sanitized field since
attribute "data-scroll-background-ratio" define parallax effect speed
but was not in whitelist.
note: also keep data-interval for gallery widget
opw-2053983
closes#35961
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Fix missing js_class attribute on the calendar xml validation file
Make possible to create new custom views based on the calendar view
Was already done in master at 496920a8f5 but was not present in 11.0
Closesodoo/odoo#26750Closesodoo/odoo#31679Closesodoo/odoo#36156
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Same cause, error, rationale and fix than 0ec0a4a32e
#OneCharacterPatch, reloaded
opw-2056251
closesodoo/odoo#35857
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
If partner.vat is an empty string, python evaluates it as falsy and doesn't check the remaining of the line. This makes the framework to send ["", ""] as values for the many2one to the browser instead of false.
By forcing to have True or False, this is not a problem anymore as bool() will be False, and False will result in the correct value in the read.
closesodoo/odoo#35807
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>