Before this commit, the default value for `filter_hierarchy`
was set to `never`. So each report had to explicitly set the value
to `by_default` or `optional` in order to make it available.
Instead, we should use the `optional` value by default and let
reports that do not want it explicitly set it to `never`.
task-3041037
closesodoo/odoo#107263
X-original-commit: a1147d91729a5eb75565f04ec10b52ed28d93c42
Related: odoo/enterprise#34675
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since BS5 integration in v16.0, the pdf of the invoices has changed. Borders would be present in the body of the invoice and the total detail.
Came back to v15 display by using the table-borderless class on those elements.
closesodoo/odoo#107257
X-original-commit: 1a46b6f9231c5d49d70bfa9eb8d434c1f092c1c7
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
The test `test_employee_create_from_signup` was failing when the module
`auth_signup` was installed because of the missing partner.
closesodoo/odoo#107243
X-original-commit: 2688f9bb00f9cb049ff11bbe4443adc66ee05941
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Bug
===
Currently, we try to enrich the domains even if they are in the
`_MAIL_DOMAIN_BLACKLIST`. IAP always return a "missing data" error
because it can't enrich "gmail.com", etc except for "odoo.com". In that
case the enrichment is successful, but because the domain is
blacklisted, we use the entire email to find the company (and so it
will create a company for each odoo.com email addresses).
The test that was removed was wrong. It works because we mocked the
enrichment response, but in practice it will always return a missing
data error.
Task-3050230
closesodoo/odoo#107235
X-original-commit: 37503108cd878412474b5486877a861dad2efc1d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Warn user and alias responsible when model creation fails on incoming
message due to alias mis-configuration.
Alias custom default values that references archived or deleted records can
prevent the record to be created when receiving an email.
Unfortunately, correcting values on the fly has too many downsides:
- as the value cannot come from nowhere, we would probably end up with
corrupted record like a task without a project
- as errors are silent, lots of suboptimal record could be created before it
is corrected
- as the code would have to deal with different kind of updates, it would be
heavily depend on the framework meaning additional maintenance cost
- the attempt made had also a performance cost by using savepoint which we
want to avoid
For all those reasons, we have decided to warm the user rather than trying to
solve the problem automatically.
The users are warned:
- through a bounce email sent to the sender and alias responsible
- in the alias interface through an alias status present in the list and the
form view
Technical notes:
- They are multiple kind of errors: error in the message (ex.: user not
authorized to send to a specific alias), error in the alias (ex.: dangling
reference in alias_defaults), other error (ex: technical error like a
service unavailable when receiving the message). Here, we want only to detect
alias error and skip other errors. So rather than doing a big try except around
_message_route_process, we have selected the spot where we should detect alias
error:
-- in _alias_get_error_message where we distinct a message error from an alias
error
-- in inside _message_route_process where record are created using
alias_defaults (custom values with reference to record that might have been
deleted since the alias creation)
- In test, we call mail.thread message_process with sudo as it is the case in
real use case (processed when fetching mail). It is needed as in some test
alias status are modified.
Task-2675209
closesodoo/odoo#101019
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, when a date field with the remaining_days widget did not have a value
typically on a new record form view, the props validation crashed because the datePicker widget
received the wrong type for its value.
After this commit, this is corrected and there is no crash.
closesodoo/odoo#107233
Related: odoo/enterprise#34668
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the X2ManyField did not have a display name and its supported
types only mentioned one2many.
After this commit, those fields have a display name and the type many2many
is rightfully put has beng handled by the fields.
Part-of: odoo/odoo#107233
documentation link for drop shipping feature is missing as the documentation tag was added along with the field rather than the settings tag.
closesodoo/odoo#107192
Signed-off-by: Tiffany Chang <tic@odoo.com>
with canary islands taxes
Steps to reproduce:
1. Go to Apps, and Install the module `l10n_es`
2. Go to Accounting App > Customer invoices
3. Create a new Invoice with fake comany, fake address with state set as
`Santa Cruz de Tenerife (ES)` and the ZIP set as 38400.
4. Add any line to the invoice and confirm.
5. Try to Send & Print the invoice, you may need to select the template
before.
Issue:
We won't be able to either print or send the Invoice getting a traceback
containing `KeyError: 'tax_details_per_record'`.
Solution:
Keys for `vals` have change so we need to adapt it to match new keys
naming and sorting for accesing the same values.
FW - port: master
opw-3067491
closesodoo/odoo#107176
X-original-commit: accb722d12e76d178ba70b884a020e162e73634f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
currently the table_id, customer_count fields are editable from the pos order form in the backend and all the other fields are readonly
closesodoo/odoo#107135
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The routing-map is a mapping that maps HTTP verbs and paths to python
controller methods (endpoints), e.g. it maps `GET /web/health/` to
`/web:Home.health`. The `_generate_routing_map` function is the function
responsible to generating the werkzeug routing-map in regard to the
controller inheritance mechanism. The mechanism makes it possible to
override an endpoint is various odoo modules to enrich it with new
features, e.g. `/web/login` is overriden in website to change the visual
of the page.
Implementation-wise, the informations from each `@route` decorator must
be merged with the other `@route` info for each endpoint override. When
a method is not overriden in a controller, there is not new info and
that controller should be skipped for that method.
The previous implementation attempted to skip such method using the
following idiom:
if not hasattr(controller, method_name):
continue
That idiom doesn't work as `hasattr` will perform a lookup on the full
controller's MRO instead of a lookup only on controller's own methods
and attributes. The controller's own methods and attributes are
actually found in `controller.__dict__`.
closesodoo/odoo#107064
X-original-commit: 42f52d26b6a81a68f1fe28e28971f0e7f4c97d11
Signed-off-by: Julien Castiaux <juc@odoo.com>
This PR add a new page "Accounting Documents" with the journal entry, the list view asset_id and the statement_line_id. This make the first page more concise and allow the related asset to be more visible and simple to work with.
closesodoo/odoo#107205
Task-id: 3075466
Related: odoo/enterprise#34642
Signed-off-by: John Laterre (jol) <jol@odoo.com>
*: website
Commit [1] introduced the possibility to configure "website filters"
used in the website to display some records dynamically via the "dynamic
snippet" and its variants. One of their field is `limit` which is a max
number of records the filter allows to show (so that the client side
cannot ask for thousands of records). Users can configure the limit used
by a snippet via the editor: they are allowed to choose up to 16, still
safe-guarded by the internal limit configured on the website filter on
the python side.
The problem here was that [2] introduced website filters for the blog
posts but set up a max limit of 6. Thus breaking the editor option if
the user choose a limit between 7 and 16. This commit fixes the issue,
for newly configured snippets (as a stable fix) or for users who would
-u their blog application. EDIT: as the master version of this fix, all
blocks will now use their set limit. We consider that is an acceptable
change after migration that the user can change by himself if he wants
to.
Steps to reproduce:
- Install blog application
- Add a "Blog Posts" snippet
- Set "Fetched Elements" to 10 (there are 7 records in demo data)
=> Only 6 are still shown
[1]: https://github.com/odoo/odoo/commit/0e7640b5f22d2bea04bbe22d3189cff7e03af545
[2]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
opw-2885948
closesodoo/odoo#107179
X-original-commit: 3a3dc8729aa2beec49602fe4c141043f60effdf1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Define the following controller:
@route('/get-context', auth='public', type='json', website=True):
return request.env.context
Access that route via JSON-RPC providing a context:
this._rpc({
route: '/get-context',
params: {
context: {"a": 1}
}
})
Since httpocalypse, it replaces the context entirely instead of updating
it. i.e. before you would get along those lines:
{"a": 1, "lang": "en_US", "tz": "Europe/Brussels", "uid": 2}
but since you get instead (and that's wrong):
{"a": 1}
Note that after this commit, this merging-context behavior will be the
same whether or not website=True is defined (while it was only there for
website=True before).
Discovered via opw-2885948
X-original-commit: 7887cfc3f177d9e64f008aabb8bd710f54024dea
Part-of: odoo/odoo#107179
A MissingError traceback that occurs in `_build_bus_channel_list` was
caught by Sentry. This error has been seen 1.3k times in the last 30
days from several customers.
The fix simply consists in checking if the document exists before
checking the rights on it.
Traceback:
```
MissingError: Record does not exist or has been deleted.
(Record: project.task(83,), User: 6)
File "addons/bus/websocket.py", line 879, in _serve_forever
req.serve_websocket_message(message)
File "addons/bus/websocket.py", line 752, in serve_websocket_message
service_model.retrying(
File "odoo/service/model.py", line 134, in retrying
result = func()
File "addons/bus/websocket.py", line 767, in _serve_ir_websocket
ir_websocket._subscribe(data)
File "addons/bus/models/ir_websocket.py", line 38, in _subscribe
channels = set(self._build_bus_channel_list(data['channels']))
File "home/odoo/src/enterprise/16.0/spreadsheet_edition/models/ir_websocket.py", line 13, in _build_bus_channel_list
return super()._build_bus_channel_list(channels)
File "addons/web_editor/models/ir_websocket.py", line 33, in _build_bus_channel_list
document.check_access_rule('read')
```
SAAS-K22 (sentry code)
opw-3086292
closesodoo/odoo#106982
X-original-commit: 9e4c5e427285b76000398476e9d923e7ea036a65
Signed-off-by: Achraf <abz@odoo.com>
After a payment is processed by SIPS, a data object is posted back
to Odoo. The data has a `ScoreInfo` element that has more than one
`=` characters (e.g. `scoreInfo=A3;N;N#SC;N;TRANS=3:2;CUMUL=4500:250000`)
This causes the method `_sips_data_to_object` to break, because there
will be too many values to unpack.
To fix this, we should limit the data split to 2 values. This is the
same method used by SIPS to process data as well.
(See: https://github.com/worldline/Sips-International-non-FR-PHPlibrary/blob/master/lib/Sips/PaymentResponse.php#L73)
opw-3071315
closesodoo/odoo#107143
X-original-commit: 3dce793ad00b1c0b9f06c705f40e31666db74a06
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Ideally, we develop in English any localization (then translate to the domestic language, in this case Serbian) All the module has been translated in english and then a .po file has been create to translate back in Serbian
Added more info on the description of the module and activate storno by default.
closesodoo/odoo#107101
Task-id: 3086250
Related: odoo/enterprise#34608
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
In a view, in the case of a field node combining
- a `groups` attribute on the field node in the view architecture
- a `groups` attribute on the field in the Python model
e.g.
```py
name = fields.Char(groups='base.group_system')
```
```xml
<field name="name" groups="base.group_multi_company"/>
```
The view post-processing adds a temporary `<t groups` block.
e.g.
```xml
<t groups="base.group_system">
<field name="base.group_multi_company"/>
</t>
```
This is to make an `AND` connection with the two groups:
the user is required to have both groups in order to see the field.
Currently, there is no way to make that `AND` combination on the same
node. The below:
```xml
<field name="name" groups="base.group_system,base.group_multi_company"/>
```
would be an `OR` connection, not an `AND.`
Hence this temporary added `<t groups=""`.
Before this revision, in such a case,
the stack post-processing was interrupted by an unexpected side-effect:
The field node changes of parent (the parent becomes that `t` block),
and a condition attempting to check that the node wasn't deleted from
the view actually checked that the parent changed, to decide to
interrupt the rest of the stack post-processing, including the modifiers
post-processing for that node.
This revision changes this behavior,
to check the field node no longer has a parent,
instead of a change of parent,
to decide that the node is indeed no longer in the view,
and to interrupt the stack post-processing or not.
This allow the field modifiers (e.g. `attrs=""`) to be post-processed
as expected.
opw-3072910
closesodoo/odoo#107173
X-original-commit: c163cbb6a9b3679067606868e325d9842ea66aa8
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
If you try to get show_reset_to_draft_button for more than one account.move, it can raise.
closesodoo/odoo#107169
X-original-commit: a5b985e8449a1e858c3fb9a0a90a6d203e16f739
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The problem is that when you archive a company and then install
subcontracting, you get a traceback.
Step to reproduce (in a multi-company environment):
-install 'stock'
-archive a company
-install 'mrp_subcontracting'
-->traceback
Explanation:
When installing the 'mrp_subcontracting', there's a search on all
(active) companies in order to add a subcontracting location for each
of them (this is is triggered by
'/odoo/addons/mrp_subcontracting/data/mrp_subcontracting_data.xml').
But there is still a warehouse linked to the archived company.
So when adding routes to all warehouses and looking for the
subcontracting location of the archived company, it is set to
False. Which is not intended and causes the traceback.
Solution:
Add '.with_context(active_test=False)' to the search for the companies
in '_create_missing_subcontracting_location(self)', so the missing
subcontracting location will be created for the archived companies too.
Discussion:
-The ability to archive companies is new to Odoo16 (implemented due to
the new pricing).
-Here I considered that we want to create a subcontracting location for
an archived company instead of taking action on the warehouse linked to
the archived company (like not considering it when creating routes).
I did this because a company can be unarchived and with this fix, it
will not cause issues.
-I think other problems similar to this one (in any app), should appear
in the future.
opw-3039495
closesodoo/odoo#107168
X-original-commit: 1dcdbe9e3cc21af50ed580c032b1927e21c3c24b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The `align` command applies the alignment to the closest block of the
selected node. Bootstrap sets the default alignment of `.btn` to
`center` but we don't support links with a width that is larger than
their contents so that alignment is not visible. For these two reasons,
we want the toolbar to show the alignment of a link's closest block
rather than that of the link itself.
closesodoo/odoo#107155
X-original-commit: a3bb5b0c4b010b7583af1440cb65e889586636c8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the selection was in a link, the alignment buttons didn't work.
That is because they are supposed to align the parent paragraph, which
is temporarily in a contenteditable=false context when the selection is
in a link. This restores the context before applying an editor command,
and restores it afterwards.
task-3083748
X-original-commit: 0a4eb266b198e5e02a3325d063d07c0dd8af0148
Part-of: odoo/odoo#107155
When confirming a bill with a price diff, if the UoM of the bill
line is not the default UoM of the product, the values will be incorrect
To reproduce the issue:
(Need account_accountant)
1. In Settings, enable 'Units of Measure'
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 Dozen x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Set the bill line price to $60
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $670
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on the UoM
of the line while the price unit of the layer is based on the
default UoM of the product. We need to convert the PU of the bill line
OPW-3081449
OPW-3062433
OPW-3075917
OPW-3048587
OPW-3078429
OPW-3075627
closesodoo/odoo#107145
X-original-commit: a1906f0b5e22f03937389d47e6ce5a650f9269e6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When confirming a bill, if its currency is not the one of the
company, and if there is a price diff, the value of the generated
SVL will be incorrect
To reproduce the issue:
(Need account_accountant)
1. Edit the currency of EUR:
- Rate: 2.0
2. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
3. Create a product P
- Type: Storable
- Category: PC
4. Create and confirm a PO with
- 1 x P at $50
5. Process the receipt R01
6. Create and process the return RT01 of R01
7. Create and process the return RT02 of RT01
8. Create the bill related to PO
9. Edit the bill:
- Currency: EUR
- Price unit: 120
10. Confirm
11. Open the valuation of P
Error: a stock valuation layer has been created because of the price
diff, which is correct, however the value is not the good one: $70
instead of $10 ($60 - $50)
When confirming the bill, we check if there is a price difference.
To do so, we compare the price unit of the bill line with the one of
the incoming layer:
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L304
But, currently, the price unit of the bill line is based on currency
of the account move wile the price unit of the layer is based in the
currency of the company.
Related to OPW-3040171
X-original-commit: 86ca91c3684fe5ea5dac1326278b5d4cce0cecda
Part-of: odoo/odoo#107145
When confirming a bill with a price diff, if the user received, returned
and received again the products, some unexpected valuation layers will
be generated
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 3 x P at $50
4. Process the receipt R01
5. Create and process the return RT01 of R01
6. Create and process the return RT02 of RT01
7. Create and confirm a SO with
- 1 X P
8. Process the delivery
9. Create the bill related to PO
10. Set the bill line unit price to $60
11. Confirm
12. Open the valuation of P
Error: There are two lines for the price difference, there should be
one line only. Moreover, the value is incorrect: 30 instead of 10 (i.e.
we should generate the price diff layer for the quantities in
stock only)
When confirming the bill, we check if we have to generate some
additional SVL (in case of price diff)
https://github.com/odoo/odoo/blob/d3d41c7679f9068a7b986925b15d0d7670233bfc/addons/stock_account/models/account_move.py#L288-L305
But, we get all ingoing SVL and process them, we don't consider that the
quantity of a SVL might actually be returned and should be ignored.
This is the reason why a SVL is created for the first receipt. This
also explains why the value is incorrect (we use the quantity of the
SVL instead of its remaining quantity)
OPW-3040171
X-original-commit: 18912b05239e6fc5dab26ec4c930f9080882d127
Part-of: odoo/odoo#107145
The current behaviour does not filter the cancelled moves when
evaluating if the product of the purchase order line is a kit.
This causes that, in cases where you have a cancelled wrong receipt
where the product was being received as a kit, if a new receipt is
created without receiving as a kit Odoo will always expect it as a kit.
After the fix, the cancelled moves will not be considered, as this is what
should be expected from cancelled operations.
closesodoo/odoo#107144
X-original-commit: 9659683d1f09c49a3ba3df8770eb7256660d0033
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit fix the issue where the slide content records,
crm team records and crm team members records were
overlapping on other group.
This was introduced by odoo/odoo#105531
Task-3086887
closesodoo/odoo#107159
X-original-commit: f7a2928afc4bc6f3ce4622f28f7cd9672b8a7b6f
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit ensures that when searching on a `inherits` field of
a model (like `name` of `website.page`), it works properly when
`pg_trgm` is activated.
Indeed, `name` is a field of `website.page` record but only at the ORM
level, not in SQL, due to how `inherits` works.
So, when the `pg_trgm` extension is enabled, it will switch from ORM
queries to raw SQL query (to use the native SQL similarity feature and
not our custom python/orm one, as obviously the SQL one is better, more
powerfull/accurate and faster).
But this will actually make the code fail when searching on fields from
a model which has `inherits` and that you search on that `inherits`
model fields.
Note that in 15.2, the `pg_trgm` extension is auto installed when
possible thanks to [1] and [2].
[1]: https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff
[2]: https://github.com/odoo/odoo/commit/75e6b645acdc95aece506ce0249fd0760838281c
opw-3063592
closesodoo/odoo#107178
X-original-commit: 3d978caad9de2010603581687ee39a5240b74074
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
New features to manage checks and managed them Odoo in latam countries
where they are widely use.
Own Checks Management
---------------------
Extends 'Check Printing Base' module to manage own checks with more features:
* allow using own checks that are not printed but filled manually by the user
* allow to use deferred or electronic checks
* printing is disabled
* check number is set manually by the user
* add an optional "Check Cash-In Date" for post-dated checks (deferred payments)
* add a menu to track own checks
Third Party Checks Management
-----------------------------
Add new "Third party check Management" feature.
There are 2 main Payment Methods additions:
* New Third Party Checks:
* allow the user create a check on the fly from a payment
* create a third party check from a customer payment
* Existing Third party check:
* allow the user to reuse a Third party check already created
* pay a vendor bill using an existing Third party check
* move an existing checks between journals (i.e. move to Rejected)
* Send/Receive again a check already used in a Vendor Bill/Customer INV
* allow the user to do mass check transfers
closesodoo/odoo#107163
X-original-commit: cbec68b414f5b87fe6e146487c532c9a174f40a3
Signed-off-by: William André (wan) <wan@odoo.com>
In order to make this modules to also match new module l10n_latam_check.
* refactory of some methods to make it more heritable
* check number now is showed only when is defined and is related to
check_printing payment method.
X-original-commit: 9394903813947cd4bfbad87f077cdf67233907d8
Part-of: odoo/odoo#107163
Currently in Sale/Orders/Sales Teams menu , The Sales Analysis dashboard
have text overflow bug for large numbers in USD/EUR this bug might be
rare but in currency like Yuan or VND its common
closesodoo/odoo#106822
X-original-commit: 5cebb129860616d80f8f6db6e261818f4ab54e05
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
If an aml has no product, it should not trigger a model that has a product.
So, we now define the fields that have to be checked on the model, instead of just being the ones given as parameters.
The way the field `company_id` impacts the model has also been changed.
The idea is that a model with a company specified should be better than a model without one.
But we also want that a model with 1 valid rule and no company is better than one with only a good selected company.
closesodoo/odoo#107165
X-original-commit: feff1a8a056f1fbbc852f7cf164e73abf83c4cc9
Signed-off-by: William André (wan) <wan@odoo.com>
This fixes the performance of the search panel of `account.move.line`
Menu > Accounting > Accounting > Journal Items
The control panel based on the accounts' roots was the issue (call to
`search_panel_select_range`)
Before this fix, the entire table was read through the use of a
`read_group`.
Since the data returned by the `read_group` is not interresting in our
case, we can simply do a lateral join on an indexed column with a limit
in order to improve the performances.
closesodoo/odoo#107164
X-original-commit: 26dd1d9627cdd04e12c3187f0f53c0e11892a345
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This reverts 0e958ccd85
Using the id instead of the previous xpath makes it less natural.
It was also conflicting with `l10n_au` which was replacing that part
with something else, removing the id.
closesodoo/odoo#107186
Related: odoo/enterprise#34635
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In order to pass the validation of the snailmail provider, the margins
are required to have nothing but white pixels. To avoid letters being
stuck until their layout is fixed, we fill the margins with white.
closesodoo/odoo#107180
X-original-commit: 206eb42468997d23b9b998530d246aa0bc69607d
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
Since mail.thread was removed from the account.bank.statement, the message_post code was causing a crash when attempting to import duplicate transactions.
This commit retrieves the messages from the returned action and displays them using the notification service
task-3044636
closesodoo/odoo#107167
X-original-commit: 6b5dd2399ccb2a7f533cdf7e2d00d0161a037c1a
Related: odoo/enterprise#34626
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Kartik Chavda