Purpose
=======
Always show the sum of a property column if its type is integer or float.
When we group records we don't show the sum, because it will require
to be able to aggregate properties (`properties.xxxxx:sum`) and the
technical cost is too big for the feature it gives.
Task-3468750
closesodoo/odoo#133700
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit fixes the signature in the export by:
- Changing the signature template to remove unnecessary transforms.
- Replacing SigningCertificateV2 with the correct tag. According to https://www.facturae.gob.es/formato/Paginas/politicas-firma-electronica.aspx the signature follows the XAdES ETSI TS 101 903 format which contains the tag SigningCertificate instead.
- Correcting the way the signature node was removed in the _get_uri_function.
closesodoo/odoo#137321
X-original-commit: e4d92f37da41e7e5efaeb82b4adfff669083fb23
Signed-off-by: William André (wan) <wan@odoo.com>
Using freezetime to decorate a TestCase can have strange effects.
It looks like an override but monkeypatching the
setUpClass/tearDownClass. It started breaking between python 3.10.6 and
3.10.12. See pr message for more details.
closesodoo/odoo#137215
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The goal of this commit is to fix two problems in the Many2one field:
1. At setup, the field is considered to be isFloating when its value is false.
2. When "xxx" is encoded and "Create xxx" is selected, the field is still
considered to be isFloating even the selection.
isFloating should only be true when the user is performing a search, when
they have made their choice isFloating should be set to false.
These problems should result in the external button not being displayed
in these two cases. Currently, the button is displayed correctly due to
a bug in owl. The bug in owl causes all Components that have executed
evaluateExpr with record.evalContext will be render each time record.update
is called. For example, for Many2oneField, it is the call to dynamic.context
in extractProps that will cause the rendering of the Component Field
containing Many2oneField. This will trigger a call to onWillUpdateProps
each time record.update is called, and will modify isFloating to make it correct.
In order to fix OWL without introducing any bugs, we're going to fix these problems.
How to reproduce after OWL is fixed:
====================================
Case 1:
------
- Go to a form view with an field "x" (with an onchange) and a many2one field
- Create a new record (the many2one field is empty)
- Edit field "x"
- The onChange returns a value for the many2one
Before this commit:
The external button is not displayed
After this commit
The external button is displayed.
Case 2:
------
- Go to a form view with a many2one field
- Insert "blabla" in the many2one
- Click on "Create blabla".
Before this commit:
The external button is not displayed
After this commit
The external button is displayed.
closesodoo/odoo#137212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, Even if the user doesn't have access to the timesheet still
user was able to see the "Allocated Hours" in Project tasks. which is part of
the timesheet.
After this commit, if the user doesn't have access to the timesheet then
the user won't be able to see the "Allocated Hours" in Project tasks.
task:3472646
closesodoo/odoo#137135
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Decorator 5 changed the default decoration method from a transparent
exec-ing to wrapper functions. This makes the decorators visible to
the profiler, and breaks one of the profiler tests as the stack traces
now differ between using decorator 4 and decorator 5. Amongst other
concerns, this is an issue because debian bookworm has updated
decorator to 5 (.1.1), and the next ubuntu LTS (which should be 24.04
hopefully codenamed Nefarious Nematode) will do the same (Ubuntu has
been providing decorator 5 since 23.04).
5.1 added a `decoratorx` function which corresponds to the old
exec-based `decorator`, however it doesn't have a `decorate`
version. So we have to flag the wrappers, instead of decorate-ing the
original method with them. This seems to have the same semantics so
why we were using `decorate` is not entirely clear why we were not
doing that previously (neither
b1e83fd7b8 nor #25383 really provide
explanations). Possibly because pylint is a dum-dum and requires
ignoring one of its rules?
Implement in 14 since it doesn't hurt even though the test in question
does not exist yet.
closesodoo/odoo#137323
X-original-commit: 52e92904eca3cdeaee734b0a83e2d3fb463e8b56
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The initial motivation of this commit was to ensure that the qunit
test suite doesn't stop when an error is thrown in a test, which
could happen if the error was thrown "sufficiently close to the
end of the test". Indeed, the "unhandledrejection" event being
async, it was sometimes triggered after the end of the test, when
the service registry was already reset, and the check of the
presence of the error service was wrong, so the error event wasn't
default prevented (e.g. await makeView(...) and the view crashes
at render time).
This led us to rework in more depth the way we deal with errors in
tests. Here are a few behaviors we want (probably not exhaustive):
- an error in a test must never end the suite (executed in py)
- an error in a test must always make the test fail, except if the
error is expected in the scenario, which one must be able to
state
- a test must always wait for potential unhandledrejection events
to be triggered before ending.
- ideally, we don't want to have to deal with unhandledrejection
in each test throwing an error (in order to prevent the suite to
stop)
To achieve this, we come with the following solution. We introduce
a new assertion method, "expectToThrow" which allows to state that
during the test, we expect errors to be thrown. It takes a list of
error messages that will be compared at the end of the test with
the errors that have been thrown during the test. If they differ,
a qunit failure is pushed and the test fails. If an error occurs
in a test and "expectToThrow" hasn't been called, qunit is directly
informed of the error and a failing assertion is done, make the
test fail as well.
If the error service isn't available in the test environment, we
apply the logic above when an "error" or and "unhandledrejection"
event is thrown. If the error service is available, we wrap the
default handler (typically the one that handles everything that
hasn't been handled by specific handlers, like tracebacks) and if
we get to it, we apply the logic above. This means that one must
call "expectToThrow" if
- the error service isn't deployed, or
- the thrown error is handled by the default handler, because
it is something like a traceback (errors like UserError,
ValidationError are graciously handled by the RPCErrorHandler)
and thus never reach the default handler.
In all cases, we prevent default the event such that the error
doesn't make the python test end.
Finally, to ensure that "undhandledrejection" events are handled
before the test ends, we wait, in the qunit lib, for a setTimeout
before ending the test, which ensures that all such events have
been dispatched.
closesodoo/odoo#137120
Related: odoo/enterprise#48211
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This traceback arises when the user tries to activate
'l10n_it_edi_sdicoop_register' without 'l10n_it_edi_sdicoop_demo_mode'.
To reproduce this issue:
1) Install 'l10n_it_edi' without demo data
2) Open 'Invoice/Customers/Customers'
3) Set the value of 'Codice Fiscale' field for all customers
4) Go to the 'Configuration/Settings/Electronic Document Invoicing' block
5) Now activate 'Allow Odoo to process invoices' twice
Error:- "KeyError: False"
[1] On the '_set_l10n_it_edi_sdicoop_register_demo_mode' method,
'edi_mode' variable is getting value through 'l10n_it_edi_sdicoop_demo_mode'.
When the user is not activated 'l10n_it_edi_sdicoop_demo_mode', 'edi_mode'
value will be 'False'.
Here 'edi_mode' is used in '_create_proxy_user' method and in that
'_create_proxy_user' the '_register_proxy_user' method is used, in
which the 'response' variable is getting value with the help of
'_get_server_url'method.
[2] But '_get_server_url' method returns 'proxy_urls[proxy_type][edi_mode]'.
Because the user did not selected'l10n_it_edi_sdicoop_demo_mode',
the 'edi_mode' value will be 'False', Which leads to the above traceback.
This commit will resolve the above issue by selecting default value 'demo',
if no 'l10n_it_edi_sdicoop_demo_mode'.
See:-
[1]
https://github.com/odoo/odoo/blob/8a13ca14d3fd251bbf85b1d8949b9d3c6ea76119/addons/l10n_it_edi/models/res_config_settings.py#L81-L92
[2]
https://github.com/odoo/odoo/blob/8a13ca14d3fd251bbf85b1d8949b9d3c6ea76119/addons/account_edi_proxy_client/models/account_edi_proxy_user.py#L84-L89
Sentry-4457787457
closesodoo/odoo#136771
X-original-commit: d6f9a0015c9f82fd7719883f604ad4d808332485
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
Before this commit
==================
Currently, when we try to modify the BoM Overview report from the studio then
it's return traceback.
Steps to produce
================
- Install Manufacturing(`mrp`) and Studio(`web_studio`)
- Now open Manufacturing and click on the studio icon
- click on the reports button and select BoM Overview report
- Now you can see the traceback
After this commit
=================
With this commit, no more errors occur when we try to modify reports from the studio.
closesodoo/odoo#137175
X-original-commit: 00785e729ab3aaf650102c0ca8b14f9855744574
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Bhavin Patel (bat) <bat@odoo.com>
On update/upgrade we should keep current password policy if its
already set
closesodoo/odoo#137326
X-original-commit: c27257914b47b6fda6d4349f9e553abbbfa53347
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Issue:
If the user does not pass hide_label options then the tooltip appears twice.
Fix:
In this commit we have removed the null tooltip.
Example:
<field name="kanban_state" widget="state_selection" />
task-3475416
closesodoo/odoo#137281
X-original-commit: d39cfca349d5b623eb87f71f9996b3794de24378
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Prakash Prajapati (ppr) <ppr@odoo.com>
Steps:
- In ``stock.production.lot`` list view, use the filter 'Expiration Alerts'
Issue:
Every lots with ``product_expiration_alert`` set to True are returned but also the ones
with ``product_qty`` set to 0.0.
Reason:
The ``StockProductionLot.product_expiration_alert`` represents lots with expiration before or equal to the current date
but don't consider the quantity of product on hand.
Solution:
After discussing with Thomas (THD), and Tiffany (TIC) the solution is to add a new custom search function on the compute
field ``product_qty`` that will be used with the 'Expiration Alerts' filter to solve the problem.
opw-3474622
closesodoo/odoo#137251
X-original-commit: 09f1a45ccbb8b463e7d9326a25c2b0b18173b133
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
The error is caused by this commit: https://github.com/odoo/odoo/commit/e21c17fae8a29c8ee04883b27d761b8ce13cf5b7
Steps to reproduce the bug:
- Enable Storage location in inventory setting
- Create a storable product “P1”:
- Tracked: SN
- Create a purchase order with 1 unit of P1
- Receive product:
- location: WH/stock/shelf 1
- SN: S1
- Valide the delivery
- Go to the product form
- update the quantity:
- new quant:
- Location: WH/stock/shelf 2
- SN: use the same as shelf 1 (S1)
- You will receive a warning informing you that S1 is already used in
another location (this is expected), but the quant is still created
with this SN.
- Now try to clear the quant or refresh the page.
Problem:
You will always get a user error: "Quant's editing is restricted, you
can't do this operation." This occurs because the field "sn_duplicated"
is computed, and the write function is called to set it as True.
However, since this field is not included in the allowed fields,
the user error will always be triggered.
opw-3511463
closesodoo/odoo#137206
X-original-commit: 3a7b781dc1fad41ca0120c48f7587edb6d7adafe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Co-authored-by: William Henrotin (whe) <whe@odoo.com>
Previously, the custom value of an attribute was not saved in the
database when selected via the point of sale or Self Order. The only way
to see this value was via the product name.
Now, this custom value is saved via the `product.attribute.custom.value`
template, in order to follow the behavior of the Sale module.
Others fix in this PR:
- Prevent to pass to payment page when we are in mobile mode. Only kiosk
mode is allowed to do so.
- Hide "Modify" button in the cart page when the line is already sent to
the server.
- Make the language popup behaviour available in mobile mode too.
closesodoo/odoo#136612
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit introduces a new feature to the domain selector that allows
to toggle a new "include archived" option that alters the domain in a way
such that archived records are included or not. This domain part is naive
and may overlap with custom parts of the domain. The special domain part
which includes archived records (['&', <previous_domain>, '|', ('active'
, '=', True), ('active', '=', False)]) is invisible inside the domain
tree but remains visible in the domain code editor.
Also rename the "Match records with xxx of the following rules" statement
to "Match xxx of the following rules".
task-3482381
closesodoo/odoo#135861
Related: odoo/enterprise#47599
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit adds a new snippet to display an Instagram page on the
website using an iframe that embeds the Instagram page.
task-2603045
closesodoo/odoo#133905
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce the bug:
- Add a "Text-Image" snippet on the website page.
- Take an "Inner content" snippet from the right panel and drag it from
a dropzone to another. It has to be fast so that the order of the "over"
and "out" dropzone events is "over" > "over" > "out" and not "over" >
"out" > "over" as usual.
-> The exited dropzone is not correctly displayed.
The problem is that since [1], the website is inside of an iframe. Due
to that, the snippets menu does not have a direct access to the
dropzones. To solve the problem, the already defined `$dropZones`
variable is used instead of searching the dropzones inside the DOM. For
the snippet editor, the problematic line has been deleted at it is
already handled by `_outPreviousDropzone()`. This is acceptable since
the commit that introduced `_outPreviousDropzone()` ([2]) and the commit
that introduced the removed line ([3]) were both introduced to handle
the case of an "over" after an "over". In other words, as
`self.droppped` will always be `true` when
`self.dragState.currentDropzoneEl` is set and it will always be `false`
when `self.dragState.currentDropzoneEl` is not set, the problematic line
can be removed as it is already handled in `outPreviousDropzone()`.
[1]: https://github.com/odoo/odoo/commit/31cc10b
[2]: https://github.com/odoo/odoo/commit/c6886410603a16b6a3c5fe459d273dd883c110c7
[3]: https://github.com/odoo/odoo/commit/fed5854e32bcddf8b14b8311b2fe542eed990f77
task-3522552
closesodoo/odoo#137255
X-original-commit: 06fde42d3ba0e8be2128cda8e695c5def917f391
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
**Preliminary note**
The fix mentioned in this commit is already done
in another commit [1].
The below commit message stayed the same for history's sake.
**Before this commit**
A popover would close on outside mousedown event.
This is not sufficient enough, has for instance all the draggable stuff
makes use of the pointer events instead of the mouse events.
This lead to some unwanted behavior, i.e.:
- Open the DomainSelectorDialog
- Open a ModelFieldSelectorPopover
- Try to drag the modal
- The popover remain open and its position is not updated.
The dialog's dragging is fine.
**After this commit**
The popovers will close on pointerdown away events.
Now:
- Open the DomainSelectorDialog
- Open a ModelFieldSelectorPopover
- Try to drag the modal
- The popover is closed and the dragging still works as expected.
[1]: 76665eb400168a6fd6e2b5f5fe099c8c4e9c8a5e
closesodoo/odoo#137247
X-original-commit: c63dbc4ed0a04e34571c2929f43812873b62fd16
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this PR, the trade partner filter was using a boolean instead of a
selection field. This PR will change the type of the field to a selection.
closesodoo/odoo#135129
Task-id: 3499156
Related: odoo/enterprise#47288
Related: odoo/upgrade#5135
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This commits hides a function in spreadsheet that are not supposed to be
used by end users: `_t`. It can only work with static strings in the source
code.
task 3102309
closesodoo/odoo#109863
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Reproduction:
1. Install website
2. Change to edit mode and click a link on the main page, for example,
“contact us” at the bottom
3. click "Edit link" in the popover
Fix: use the variable `shouldFocusUrl` for link tool props update
task-3514360
closesodoo/odoo#137246
X-original-commit: af035687c57f8b34261beff121669ee044d9b7df
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Rodolpho Lima <rcdl@odoo.com>
if GST related tax is selected then we send E-invoice else not needed
task - 3360018
closesodoo/odoo#137187
X-original-commit: 2d59d7506ef00db0e8a1c641634179e56dc423dd
Related: odoo/enterprise#48196
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Jigar Vaghela (jva) <jva@odoo.com>
With this commit, instead of `Record.insert()` before setting
relation with records, we can immediately pass record data.
For example:
```js
message.author = { id: 3, type: "partner", name: "Admin" };
thread.messages.add({ id: 10, body: "some-text-content" })
```
This is supported on all relational fields that define a target
model.
To make this work while drastically avoiding cyclic dependencies
in code, whenever data have to be inserted in relation, they are
pre-inserted with essential data, and then they are fully inserted
after being registered in the relation.
closesodoo/odoo#136539
Related: odoo/enterprise#47854
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This simplifies managing relations on the store, and gives
incentive to define them there instead of another prop that
is a record, e.g. `discuss`.
Part-of: odoo/odoo#136539
Previously, applicants could submit job applications without providing a
resume or LinkedIn profile URL. Additionally, there was no notification
for applicants if they had recently applied for the same job or another
position, and no checks or notification were in place for malformed
LinkedIn URLs.
This commit addresses these issues by:
- Requiring at least one of Resume or LinkedIn profile for an applicant
to apply.
- Notifying applicants about prior applications for the same job or
different positions.
- Adding a LinkedIn URL an notifying the applicants that he has
probably made a mistake if the regex doesn't match his input.
task-3446696
closesodoo/odoo#131308
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
With an L10n_cl company
Create invoice
Send&Print
Issue: Invoice report does not correctly print the electronic stamp.
It is in the wrong position (on the right, it should be on the left) and
it is shrinked.
In commit
https://github.com/odoo/odoo/commit/3764914c8616bf59d299e6279cc6fc93321cdacb
the 'total' section of the invoice report has been
moved into a right column as floating element.
This commit reposition the stamp on the left column
opw-3474173
closesodoo/odoo#136987
X-original-commit: 37cce94c200f05ee66b9577b95d2eb478134148f
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Steps to reproduce the bug:
- Modify the website's menu to include only two items: a link to a page
and a dropdown menu.
- Switch to mobile preview.
- Open the "Hamburger" menu.
- Click on the dropdown toggle.
- Bug: The dropdown menu is hidden and requires scrolling the navbar to
see it.
Since commit [1], dynamic positioning of dropdowns within a navbar has
been enabled (before that, Bootstrap disabled it) but this change
introduced this bug.
To fix this, we disable dynamic positioning of the dropdowns when they
are inside a "Hamburger" menu.
[1]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
opw-3493512
closesodoo/odoo#137165
X-original-commit: 55bc21c9503bf3b319d94e10d73bf672385b455c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Not very useful to the average user, and can fill up logs during
tests (mostly 16.1 onwards for some reason but might as well square
up everything).
closesodoo/odoo#137149
X-original-commit: 4461d90e534d7568e6b676913c959d9d083f88fc
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit changes the public `parseHTML` utility function's signature,
in order to allow the use of the editor's document to create a document
fragment.
This aims to avoid mismatches in the prototype chain of HTML elements
created by such util and the ones present in the editable when the
editor is mounted in an iframe. This is of particular relevance for the
'insert' command, in which the node to be inserted is tested for
`instanceof` the editor's document global `Node` object.
task-3526134
closesodoo/odoo#136984
Related: odoo/enterprise#48108
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Introduces a hierarchical structure of some menus. Reasons:
1. Allows testing the child-parent relation of specifically those menus
that do not have `parent` or `parent_id` attribute in the source xml
using standard menus. It's likely a rare use case, but that's precisely
what we currently need in https://github.com/odoo/upgrade/pull/5163
2. Provides a unique example usage of menus written in this manner
as opposed to using the `parent` attribute
closesodoo/odoo#136069
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Before this commit:
There are some extra classes used in the mass_mailing_theme_template.Those
classes are not supported by mail clients.
After this commit:
Those extra classes has been removed.
task-3347902
closesodoo/odoo#130178
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The mail server mostly doesn't use the intrinsic features of
`PyOpenSSLContext`, instead it pretty much just uses the underlying
`OpenSSL.SSL.Context`, just through the wrapper.
The only thing it actually uses from `PyOpenSSLContext` is
`load_cert_chain`, and since we are using a keyfile and are not using
a password this is equivalent to *two* function calls. Just perform
those two calls directly, remove all the indirections, and remove the
unnecessary import.
Bonus content: since 2.0 `load_cert_chain` reraises the inner errors
as `ssl.SSLError` which we don't handle, so we avoid this extra issue.
This was discovered because from 2.0.0 to 2.0.4 the
`contrib.pyopenssl` module was marked as deprecated (it was
undeprecated in 2.0.5) but regardless its use is an unnecessary
complication here.
closesodoo/odoo#137198
X-original-commit: e534bbed78a80d1ba0c8edd22e039e5cfb50e613
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
How to reproduce:
- Create Product 'Kit': storable, avco
- Create Product 'CMP': storable, avco
- Create BoM => type: kit | product: 'Kit' | Components: 3 units of 'CMP'
- Create mock currency (or update existing one), with a rate of 'Unit per USD' = 100
- Create purchase order in Mock Currency for 1 unit of 'Kit', with a unit price of 3,000.00 MOC
- Confirm Purchase Order and receive products
=> Go to the created valuation layer: Unit price for CMP is $1.000,00 instead of $10.00
OPW-3453703
closesodoo/odoo#137183
X-original-commit: ca05e3993fd0d8bd2b7333a9be15dc042f95fe6e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
- `Response.charset` is deprecated since 2.3, `Response.set_cookie`
accesses the currently-extent internal `_charset` directly until
this too gets removed in Werkzeug 3.0. Add a `_charset` to
`FutureResponse` so this does not crash.
- Bytes response headers are deprecated since 2.3, and will get
removed in 3.0, passing bytes in websocket is completely unnecessary
happenstance which is trivially fixed.
closesodoo/odoo#137145
X-original-commit: 66e3040d4ad9e03aabefebd4799f699ad30fca45
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Fix various issues after last refactoring of base automation. Various
usability issues arose when trying to configure some server actions
and automated actions during some tests.
Fixes mainly cover model check on server action, as well as checks
and synchronization with automated rule model. Some additional checks
are added. See sub commits for more details.
Followup of odoo/odoo#114352
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
closesodoo/odoo#137133
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a computed m2m field giving allowed models for the action. It allows to
avoid choosing the wrong models when designing server actions.
Remove a test that has no use: it checks a model_id field is available on
server action view while we don't want to display it as it is imposed by
the rule itself.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
When creating new primary views you should always specify the priority to
avoid having the specific view used as default. This one is specific to
base automation usage of server actions.
Also move view in its own file to respect guideines. RIP JEM.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Effectively check that mail-specific server action types are triggered only
on mail-enabled models that are not transient.
Check that mail and sms templates models match their action model by adding
constraints.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Summary should be taken from activity types when possible.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Fix name compute method:
* correctly call super in batch;
* correctly filter records;
* remove dependency on context key (which was missing in triggers);
In this commit we also consider the name update should always be done even
outside of automated rules context. Having a whole compute method relying
on a context key does not makes sense. As server actions are technical
records, having the name always being correctly updated is better.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Following the recent server action refactoring, it seems translations have been
forgotten in the review process.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
New implementation of automated rules does not check if rule model matches
models of its children server actions. This can easily lead to updating
records of another model which have nothing in common with the automation
rule.
Also better write the reset when changing model.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Babel's named / implicit formats (short, medium, long, ...) come from
the CLDR, which can get tuned as debates get settled, cultures shift,
etc... as a result using these formats can break tests on any babel or
even CLDR release (technically nothing stops distros from updating
their bundled babel with new CLDR data).
b77eb98bbf6bc937efb7941802c0794ae3622094 previously did some
mitigation of this issue, but even if they're not yet in distros
further Babel updates (e.g. 2.12) already affect some of the patterns
we're using.
Proactively mitigate this issue more by only using explicit datetime
patterns (and time patterns, date is fine because it retrieves the
pattern from the lang rather than default to babel patterns) in the
date/time formatting tests. This means only specific terms still vary,
and those should be a lot more stable / reliable than e.g. futzing
with separators and minor formatting issues.
closesodoo/odoo#137181
X-original-commit: 3547e980428cc1dd11c8e82446e7d7f824b9f6f8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit aims to reintroduce CSS variables to handle the different
states of our navbar entries.
Recently, the way we handle the navbar entries changed. Previously, we
used to set CSS variables in Community, which would allow us to control
the color of ours nav entries at every state.
On the Enteprise side, this would allow us to use the different colors we
use for these buttons and style them differently
This approach was also very helpful because we could override these CSS
variables once again to handle the colors of the Studio navbar elements.
Recently, the approach used to control these elements changed :
- On Community, we make use of CSS variables ;
- On Enterprise, we use the Bootstrap `btn-light` class.
Using `btn-light` was a very good approach to ensure that no issues would
appears on our buttons and also to reduce the amount of code needed, but
unfortunately, using `btn-light` directly affects Studio, causing contrast
issues. It was also a bit weird to have CSS variables + Bootstrap classes
being set at the same time.
To fix these issues, we reintroduce CSS variables in Enterprise and Studio,
to fully control the color of our elements and ensure everything is
readable. Most of these variables are defined in Community, inside the
`navbar.scss` file, and we simply override them in Enterprise and Studio.
task-3418936
part of task-3326263
closesodoo/odoo#137140
X-original-commit: af6d914c379953d2deec9833579399f126076194
Related: odoo/enterprise#48174
Signed-off-by: Stefano Rigano (sri) <sri@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
std-odoo