On website (with “developer” mode enabled), The “Model Pages” menu item
is accessible even when there are no created module page records, which
is not relevant in most use cases.
The code from [1] introduced a way to expose models (both manual and
existing models) publicly on the website by creating pages for them,
these records are accessible through the model pages' menu (which is
currently visible in debug mode only).
A first spec aimed to make this menu item visible only when module pages
are created for the current website, But since we need to perform async
calls for that (to check if some module page records exist), and after
further discussion, it was decided to remove it completely.
[1]: https://github.com/odoo/odoo/commit/198e226f5bd66dba6598d1ef85e5fa5fb82b38b2
task-3659626
closesodoo/odoo#148175
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since b90cae0650, the domain from
_loder_params_product_product is ignored. But the utility products that are
supposed to be loaded are declared in that method. In this commit, we now
override the _get_available_product_domain to make sure the utility products are
loaded when opening a pos session.
closesodoo/odoo#148098
Related: odoo/enterprise#53653
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracking: SN
- Update the qty: 1 unit, “SN1”
- Create a SO with and validate it
- Go to the delivery and validate it
- Create a return and validate
- Create a return of return
Problem:
error message: RecursionError: maximum recursion depth exceeded while
calling a Python object
The `_get_origin_moves` and `_get_destination_moves` functions add the
list of origin or destination moves, but the functions themselves are
called with that list, creating an infinite loop.
opw-3659818
closesodoo/odoo#148031
Related: odoo/enterprise#53695
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
How to reproduce:
- Open a PoS session
- Create an order, pay it and validate
- In the same session, find the order in `Orders` (filter on Paid) and
make a full refund
- Close the session
- Open a new session and open the "refund" order in Orders
- Click the "Invoice" button to invoice this order
Observed behavior:
- We get a UserError saying the reversal entry is unbalanced, where the
credit side equals 0.00 and the credit note is not generated.
Expected behavior:
- We are able to generate the credit note correctly.
When computing the reversal entry, it seems we inverted the sign of the
quantity field of each order line when reversing a refund. However,
that did not make sense because the actual amounts are already reversed
for a refund.
task-3611296
closesodoo/odoo#147934
X-original-commit: a6b10b65e3a04ce96519edc846801304cc47f40b
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Issue:
- When you have analytic plans but no analytic accounts you got a
traceback when you tab through the fields on a vendor bill.
Steps to reproduce:
- In accounting app create a vendor bill where analytic plans exist
without associated analytic accounts.
- Use the key 'Tab' to move through the fields on the vendor bill.
- Notice Traceback error.
Solution:
- Checking if the dropdown is not empty before proceeding with the Tab
key logic.
OPW-3648815
closesodoo/odoo#147807
Signed-off-by: William André (wan) <wan@odoo.com>
In 16.2, this commit https://github.com/odoo/odoo/commit/b0a6c525b06fabf8cf869890d8383f8304bae697
modified products' domain on a manufacturing order.
The domain added was not correct as it overrided the domain from
stock_move instead of doing the intersection of the two domains.
task_id: 3630626
closesodoo/odoo#148208
X-original-commit: aedbbae168612a8ea3a2df5cb855432cf3001d26
Signed-off-by: Steve Van Essche <svs@odoo.com>
Following odoo/odoo@2a8dd6011, if a db has `web.max_file_upload_size`
ICP set to any value, the request would have been wrongly limited to 1 byte
closesodoo/odoo#148617
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
In this commit we add a line on the receipt with the text
"Odoo Point of Sale" or "Odoo Restaurant". ( depending on the case)
This is done for marketing reasons.
closesodoo/odoo#148094
Task: 3635645
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, if a URL was contained in two or more text nodes,
e.g. <p>"link" ".com"</p>, pressing the space key after the URL failed
to convert it into a link. Such text node split can happen as a result
of backspace or delete in the middle of a text node.
This commit makes sure adjacent text nodes are merged before searching
for a URL in its content.
task-3468763
closesodoo/odoo#148362
X-original-commit: 04f9a90127eac2a403ffe77d1e90dbe659a8fa42
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit, the StaticList and its Records shared the same
reference to the activeFields. When an x2many record was opened in
form view (and that form view wasn't inline), we altered the active
fields to add the information coming from the form, and we loaded
the corresponding data for the record we open. However, by doing
so, we also altered the active fields of all the other records,
for which we didn't load the corresponding data. From that point,
a rendering of those kanban records could lead to a crash, because
we iterate over active fields and make the assumption that there's
an entry for each of them in data, which isn't the case.
For instance, this happened in a dev branch in project, in mobile:
after opening a sub task in form view, if we switched to another
notebook tab and then switched back, there was a crash.
This commit fixes the issue by creating a copy of activeFields for
each Record, s.t. when a record is opened in a dialog, only its
activeFields (and those of the StaticList) are altered.
Note that activeFields of the StaticList must be altered in this
case to ensure that the onchange spec is properly generated, with
the fields of the form view.
closesodoo/odoo#148351
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, the key for the cache of compiled templates
(in the useViewCompiler hook) only relied on the arch, i.e. we had
a cache hit if we had to compile an arch that had already been
compiled before.
However, the Compiler to use might change. When this happens, the
template must be re-compiled, obviously, as the ouput may differ.
For instance, have a kanban arch with a js_class (pointing to a
custom view with a custom compiler), and have that arch used in an
x2many (where js_class is ignored, i.e. where it is rendered with
the basic kanban renderer). This happens in project, with the task
kanban view, which is also used for the child_ids field, in the
task form view.
This could lead to traceback, as the compiled template might refer
to attributes of a the KanbanRecord that only exist on the custom
KanbanRecord, not on the basic one.
Part-of: odoo/odoo#148351
Before this commit, for a barcode rule with the UPC-A encoding, the
condition's checking if we should convert an EAN-13 to an UPC-A was
always false because the key `upc_ean_conv` was checked on the wrong
object (`this` instead of `this.nomenclature`.)
task-3472884
closesodoo/odoo#147955
X-original-commit: b3435d1b4a39032bc7e0f74b70cfda992410fd4c
Related: odoo/enterprise#53600
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit razorpay provider handle both authorized
and done event for transaction even though razorpay return
both authorized and done event at same time and there is no
need to handle authorize event if capture manual is disabled
on razorpay and because if handling both events at same time
it causing serialization issue and it might cause serious
issue if other operation are being executed on same time.
This commit handle authorized event only when capture manuallly
option is enabled on razorpay so it will not try to write on
operation at same time and avoid concurrency issues.
task-3652228
closesodoo/odoo#147534
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Since 461d311b73, the manufacture rule lead time is taken into
account in the date computation for the procurement. The issue comes
from the fact we assume there is only one warehouse related to the stock
rules chain.
closesodoo/odoo#147261
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
`res.users.company_ids` returns only active companies, while
`res.users.company_id` may be inactive. This leads to a situation where
`self.env.company` is inactive but still associated to `self.env.user`.
Since in multiple cases the default value for relational fields pointing
to `res.users` is `self.env.user`, we may get an error in this check:
`self.env.company` is not in `self.env.user.company_ids`.
See https://github.com/odoo/odoo/blob/5506ca7/odoo/addons/base/models/res_users.py#L281-L282closesodoo/odoo#147127
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this PR, I guest searching in discuss would get an access error.
This is because the search is searching in the attachments that the guest can't
access.
task-3637314
closesodoo/odoo#146110
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit fixes an issue about the last arrow button not taking the
`o_first` class in some cases.
With Odoo 17, we introduced a new behavior for our arrow buttons.
This behavior includes an invisible element placed before and after the
first arrow button on the left and right side.
While this is working fine as long as you don't have any hidden item
insie a dropdown menu, once you trigger a stage that was folded into a
dropdown menu, this invisible element appears on the right side.
Since we use the `o_first` class that sets a `border-radius` on the first
element on the right side, this invisible element was taking that
`o_first` class.
To fix the issue, we search for the first element within the scope that
does not have a `d-none` class, and we then add the class to that specific
element.
task-3628288
closesodoo/odoo#145453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
After revamping the calendar event form view, the warning that is shown when an
attendee doesn't have an email set started being rendered in a single column,
making the warning be super shrunk. This commit fixes this by forcing the
renderer to use 2 columns for the warning.
task-3613118
closesodoo/odoo#144514
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Versions:
---------
- 17.0
Steps to reproduce:
-------------------
1. Install any custom module.
Issue:
------
Odoo raises the error "Connection to %s failed; the module %s cannot be
downloaded."
Cause:
------
The "activate" button on custom modules triggers the "button_immediate_install_app"
method instead of "button_immediate_install" because the "module_type" field is
empty for custom modules.
Solution:
---------
Display the "button_immediate_install" button on the modules kanban view when
the "module_type" is empty.
closesodoo/odoo#141744
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Currently when trying to change the company in the configuration of a working times, a traceback error occurs.
Steps to reproduce:
-------------------
* Select app ´Employees´
* Select ´Configuration´ -> ´Working Times´
* Select any
* Try changing the ´Company´ field
Why the fix:
------------
Result of [False, self.env.companies.ids]:
[False, [1]]
opw-3634123
closesodoo/odoo#148344
X-original-commit: 85bc53984b97e98ab8fe2cf966e32c0146891a88
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Purpose
=======
We added a constraint to make the from filter match the login for the
Outlook mail servers, which makes sense most of the time. But in the
Outlook settings, we can allow to send email from a different email
address, and so that constraint blocks that use case.
Task-3645954
closesodoo/odoo#147246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: analytic, mass_mailing
This commit fixes the supportedOptions object in some fields. Instead of using
a 'supportedTypes' key when descbribing the type of fields that an option must use,
the 'availableTypes' key must be used. This was simply misspelled.
A help has also been added for the fold_field option, following the fix for task-3474817
closesodoo/odoo#143127
Related: odoo/enterprise#51241
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Internal attributes of our Websocket class are
not supposed to be overridden or even used by developers
in business modules.
Ensure that by name mangling these attributes,
to make the use of them harder and make understand
those attributes are meant for the internal use
within the Websocket class only.
Part-of: odoo/odoo#75510
Since the StateSelectionField component handles the hotkey registration,
it was necessary to verify that an hotkey can effectively be added, instead
of trying to register to alt+undefined.
This issue happens when having more options in the selection field. Since the
code is written in a way each listed option should have an hotkey associated,
which is not the case, because the list of supported hotkeys has a length of 3.
The command is then added, without an associated hotkey.
A simple test case has been added, using the hotkey to set a state, and asserting
the presence of more than 3 items in the dropdown.
opw-3620129
closesodoo/odoo#148343
X-original-commit: ab572de20367f67aab4092b9e600e5ebd4cce4a6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Recently, the vat validation was changed to
support 16 digits vat introduced in Indonesia
in January 2024.
This change replaced the stdnum validation,
but did not handle vat numbers written using
the standard presentation format.
This is fixed here, where we will remove the
characters used in this format and strip the
vat before doing the validation on the digit
amount.
closesodoo/odoo#148386
X-original-commit: 4c8629228f7842501d5a067451abca24d1089bf9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The existing implementation for the fiscal device applies a number of
limitations to the content of the invoice in order to ensure the invoice
can be regularised and serialised in such a way as to make it
transmissible to the device.
One of these checks was ensuring that only one tax can be applied per
line. This check was implemented as the device itself only accepts one
tax per line.
This check isn't entirely accurate, since the user should be able to add
taxes such as levies, service charges etc (non-vat taxes) to the the
line, and have them skipped when transmitting the invoice data to the
device.
As such, this commit adapts the code to alter the checks (allowing for
only one 'VAT' tax, and any number of other taxes). The way the price
total is determined is altered to use only the "VAT" tax and base amount
to get the price_total for the line from the corresponding line's tax
details.
This commit also adds a test.
closesodoo/odoo#148397
Task-id: None
X-original-commit: bb3a32c7f45ac5adb3dddf560f6af33f9bca3780
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate Lock Confirmed Sales from Sales settings
3- Create a new order as a Public user and make the payment
4- Check the state of this order in backend
Current behavior before PR:
Upon creating and confirming an order as a public user the order does not get locked even if the 'Lock Confirmed Sales' setting is turned on. This is happening because when checking if the 'Lock Confirmed Sales' group is on or not we check if it is there for the current user which if he is a public user by default will not have this group.
Desired behavior after PR is merged:
Before we had this condition checking if self.env.user has the 'Lock Confirmed Sales' but this won't work if the SO is coming from eCommerce with public user env So now we are checking the creator of the SO that in the eCommerce scenario will be OdooBot and if the SO is created from the backend it will be one of the users who already has the group.
opw-3595964
closesodoo/odoo#148363
X-original-commit: 4cfd125837858f70d63d14f41265b9b9f47a933b
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Issue Description:
==================
The system currently resets the expected duration in the Work Order tab of a Manufacturing Order (MO) to the default Bill of Materials (BOM) value after 'Produce All' is used. This occurs despite any manual duration adjustments. This issue can be traced back to the dependencies of the compute method involved in this process. Specifically:
1. The `qty_production` field in `mrp_workorder.py` is a related field (see [here](https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L44)).
2. When marking the MO as done, we write on this related field (refer to [this code](https://github.com/odoo/odoo/blob/780dded71cc725d75a0739e6c7bf4ceab5850581/addons/mrp/models/mrp_production.py#L1886)).
3. This action triggers a call to the compute method (defined [here](https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L324)), leading to the unexpected change in the expected duration value.
Steps to Reproduce:
===================
1. Create a Manufacturing Order (MO) with a product that has a BOM.
2. In the Work Order tab of the MO, input a custom expected duration different from the BOM's default duration.
3. Сomplete all product validation steps.
3. Click 'Produce All' on the MO.
4. Observe the reset of the expected duration to the default BOM value in the Work Order tab.
Proposed Solution:
==================
Implement a change to prevent the re-calculation of `duration_expected` in the Work Order tab once the work order's state is set to 'done' or 'cancel', ensuring that any custom duration set prior to executing 'Produce All' is maintained.
opw-3608185
closesodoo/odoo#148269
X-original-commit: 00876107734c2d5bcf3f057ead55e345493bb6e2
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Ilya Rudy (ilru) <ilru@odoo.com>
After #38518, there are cases in which people uninstall l10n_it_edi so the following traceback is given when importing a PDF invoice (OCR):
```
File "/home/odoo/src/enterprise/saas-16.4/l10n_it_reports/models/account_move.py", line 9, in <lambda>
lambda rec: self.env['account.edi.format']._check_filename_is_fattura_pa(rec.name)
AttributeError: 'account.edi.format' object has no attribute '_check_filename_is_fattura_pa'
```
We move everything back to l10n_it_edi, but the test will be excised.
Enterprise PR: odoo/enterprise#53452closesodoo/odoo#147676
X-original-commit: 0f897c6dd9f89c1e262dd6420829c0466dae398b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Version:
--------
- 16.0+
Steps to reproduce:
-------------------
1. Go to Timesheets / Configuration / Settings;
2. set encoding method to Days / Half-Days;
3. go to sales and create a sales order;
4. sell a service that will create project on sale;
5. confirm and go to the generated project's settings.
Issue:
------
The Allocated Days displayed is one eight of what's expected.
Cause:
------
On project creation, it was using `timesheet_encode_uom_id` to calculate
`allocated_hours`. Hence, if timesheets are being encoded in days, it
also tries to encode the project's `allocated_hours` as days, dividing
the quantity by eight.
Solution:
---------
It should use `project_time_mode_id` as UoM instead,
which is hardcoded to hours.
opw-3614995
closesodoo/odoo#148313
X-original-commit: 6817bb76b9f2cdb3a73489280efa7f73e7c8dacd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Issue:
======
The auto signature has hidden overflow part in y axis when having long
characters in bottom like (y, j, g)
Steps to reproduce the issue:
=============================
- Use any sign template that have at least one name_and_signature sign
item.
- Enter a name that have at least one of the characters (y,j,g)
- Click on auto
- The signature doesn't show fully
Solution:
=========
Update the hardcoded values for the y-axis for the name and the line of
signature and the font size to make sure it fits perfectly inside the
canvas.
opw-3639171
closesodoo/odoo#148299
X-original-commit: c9653d5649a35640cc461c9baa0b73e8c6c1cace
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the link preview in the Link Dialog would not be
updated after changes on the label input field, depending on other
actions to be updated (e.g. picking a different type of link/button or
changing the URL input field).
This commit makes sure the link preview reacts to changes on the label
input field.
task-3580621
closesodoo/odoo#148202
X-original-commit: c7954225e8680821a46c9628e5e05df2ae575da7
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
*: website
When the user uploads an image and remove the original image, some
image options continue to work thanks to a backend fallback on another
image. Unfortunately, this fallback is not available for images coming
from unsplash. This commit fixes this issue by preventing the UI to be
blocked when the original image is not found.
Steps to reproduce the bug:
- Activate the developer mode
- Configure Unsplash in the settings
- Add a Cover block on a page
- Replace the background image with an unsplash image
- Save
- Edit the page and via the media dialog, remove the original image
=> The options on the image cannot start anymore.
opw-3636499
opw-3474103
closesodoo/odoo#148197
X-original-commit: 3b0ac160a800f70ae965b60110e83e41655bca5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit, the pager hook use useChildSubEnv to patch the
config with the pagerProps. We used useChlidSubEnv because this
information only targets one of its children (the ControlPanel),
not the components using the hook themselves (e.g. the controllers).
However, this has an infortunate side-effect. If a component using
the pager hook also wants to patch the env (e.g. with useSubEnv),
and does it after calling usePager, it will erase the sub env
created by the pager hook for the children by its own.
This happens with the TimesheetTimerListView:
```js
setup() {
super.setup(); // super will call usePager
useSubEnv({
config: {
// this config doesn't contain the pagerProps
// generated by usePager, as it's the config of
// the component itself
...this.env.config,
disableSearchBarAutofocus: true,
},
});
}
```
Since using useChildSubEnv in this case isn't necessary, we simply
replace it by useSubEnv.
Note that we don't add a framework test for this issue, as it
would be totally artificial. Instead, the enterprise PR adds a
test for the TimesheetTimerListView.
opw 3636182
closesodoo/odoo#147393
X-original-commit: 8dbf8021842b94b9b067e2582f3aa92d31ef62e5
Related: odoo/enterprise#53342
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When we copy a sales order we were taking margins from the past which
have a high probability of not being valid anymore.
Now, once we copy a sales order, no past value is copied and the
purchase price is computed as new so we get the current margin values.
TT46721
closesodoo/odoo#148244
X-original-commit: 6da8aec93f1e66feaea16b12e245a229001cec21
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
1) Install and enable the "Onsite" payment provider;
2) As a public user, add product(s) to your cart;
3) Try to pay with the "Onsite" provider.
-> Internal Server Error
Cause of the issue:
In the log, the cause of the issue is an AccessError,
specifying that we tried to read the field `transaction_ids`
on a `sale.order` without having the necessary access rights.
This shouldn't happen, since the payment & ecommerce flows
are executed in sudo mode, after making sure that the cart
belongs to the customer.
After investigation, pending payment transactions trigger
1) the sending of a mail to the customer
2) the first mail generation will request the report assets
3) the generation of the report assets will create an
attachment and commit the transaction
4) committing the transaction will trigger a global
flush of the environment, forcing the computation
of pending mail wizard fields, with a different
environment than the sudoed one initiating the sending
of the mail.
This will lead to security errors as we try to access
`sale.order` fields content without having the rights
for it.
Standard fields being already in the cache, it will
be noticed when trying to read the `transaction_ids`
field.
Solution:
Manually prefetch the `transaction_ids` content with
the sudoed environment, since the records cache is
shared between the environments (until a more global
fix is found and deployed).
Introduced by #121376
opw-3628753
closesodoo/odoo#148199
X-original-commit: 511fe642b9860bd9d2f6b7ed728e7d3e6af48748
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When using safe_eval on this dict, "true" raises a NameError while "True"
is interpreted properly.
At the same time, this is more consistent with the rest of the code.
closesodoo/odoo#148203
X-original-commit: 0e91bf8b3956c1403e638421a91af3275b9e6489
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When replenishing a product with a route buy selected on the product form but no vendor
added, we fall into an endless loop because the default_get sets the route,
which triggers the onchange that return a warning.
This will again call the default_get and the loop never ends.
The onchange is useless as it's only goal is to display the warning, and as the field is
required on the form, the user will not be able to submit it.
opw-3653714
closesodoo/odoo#148201
X-original-commit: e7fca1c849652920388526f4797397aa18247204
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit:
When inserting a star rating element, pressing 'Enter' would move the cursor
to the next line, and hitting 'Backspace' would delete the star rating element.
After this commit:
After inserting a star rating element and moving to the next line with 'Enter,'
pressing 'Backspace' now causes the cursor to move to the previous <p> tag
where star element is located. If 'Backspace' is pressed again, the star
element is deleted.
task-3555394
closesodoo/odoo#148198
X-original-commit: 64a1b38450e15162f89d370fbe30abda9e5f7fe7
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Purpose
=======
When an email is opened and is from the default notification mechanism,
i.e: coming from something like "notifications@mail.odoo.com", we don't
want to try to match the email address to an existing contact partner.
Instead, we now display a custom message on the mail addon side
mentioning to search the contact manually.
Task-3557545
closesodoo/odoo#148073
X-original-commit: 9ff0815e258160f0eca595e0c3cce4b005e79eea
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This fix is to solve a bug that appears in the demo data od the l10n_be specifically in the cash journal using an income tyoe account for the negative cash difference which should be en expense type.
opw-3642586
closesodoo/odoo#146936
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Incorporate German Loredo (xmglord) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-prclosesodoo/odoo#148245
X-original-commit: c3f1be0d418b06d9dff97e44538a53f52d8ae496
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since the commit odoo/odoo@0d99f4b9d9, the header buttons with display="always"
can't be invisible. The invisible attribute is ignored for this type of
button in list view and kanban view.
This commit fixes this issue by adding t-if that will evaluate the invisible attribute.
closesodoo/odoo#148092
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit simply replaces the shortcut for the action_done_schedule_next
buttons from alt+q to alt+z in the activity view dialog because the
alt+q shortcut is already used for the Save/Schedule buttons. This was
already done in https://github.com/odoo/odoo/pull/145738 but the wizard
which appeared in 17.0 hadn't been corrected.
opw-3565747
closesodoo/odoo#148160
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Mehdi Outagant (MOU)