Current behaviour before commit:
In website, space before the word is lost when deleting the word.
Desired behaviour after commit:
Now space is preserved when deleting the word.
task-3233352
closesodoo/odoo#148492
X-original-commit: 5f5d12dd1bbdc63a9565aa84f197c4a9bba55d7a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, the mockServer didn't respect the unity specification
for many2one fields. When you do a mockWebRead and you want to read other fields
than "id" and "display_name" for a many2one field, the mockServeur ignores
this part of the specification.
The goal of this commit is to ensure that the mockWebRead respects
the full specification for many2one fields.
closesodoo/odoo#148483
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit addresses a synchronization issue with Microsoft Calendar,
which arose after the implementation of commit d9c4043.
The mentioned commit added tracking to the pre-commit process,
inadvertently causing problems during calendar synchronization.
The issue surfaced when the `_message_track_post_template` function was
called in the pre-commit phase. If the appointment function was
installed, the `_track_template` was overridden in this module, leading
to an attempt to access the removed event, which raised an error and
prevented calendar synchronization.
With this modification, the `_track_template` will not be called for
the created event that was cancelled in the same transaction.
opw-3635261
closesodoo/odoo#148439
X-original-commit: f46276590f62bc578aab954a88e495519b46a07a
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Whenever a user's is successfully connected with l10n_in_edi* it will display
the user a notification of successfully being connected with Indian EDI
Services
closesodoo/odoo#148418
X-original-commit: 9c0e6123c4b03ca27e1855755ce2728faeb567e6
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Added buy credits button in the view which gives ease to user to directly buy
l10n_in_edi IAP credits
X-original-commit: a604e023d79c72ab2f91b063bdd592f6c03e1eac
Part-of: odoo/odoo#148418
Issue:
When printing delivery slip report the warehouse address is shown instead of the delivery address.
Steps to Reproduce:
1. Install Purchase App.
2. Install Inventory App.
3. Create Purchase Order.
4. Receive Purchase Order.
5. Return the transfer.
6. print delivery slip
Solution:
Issue was that upon creating the return stock moves that will be outgoing
we copy the attributes from the original incoming stock move which does not
have a partner assigned, So the solution was to assign the partner on the outgoing
stock moves right away from the stock picking.
opw-3623451
closesodoo/odoo#148398
X-original-commit: 5c9b8cea1a08d310363cd93bc27662f2b848ef84
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Omar Abosamaha (abom) <abom@odoo.com>
This commit ensures that elements returned by the getTabableElements
method of the ui utils does not return invisibe elements. This fixes an
issue with the trapFocus method of the ui service which could set an
invisible element as lastTabableEl therefore making it impossible to
loop back to the firstTabableEl when the actual last tabable element is
focused and the client presses tab. Also fix a side effect of these changes
in list renderer where focusCell would be called before the cell width
computations which would work by chance before since getTabableElements
took into account elements with 0 width but is now no longer the case.
This is fixed by moving down the onPatched method which calls focusCell
underneath the useEffect method which performs column style computations.
Steps to reproduce:
- Go to any dialog with mail installed
- Press tab multiple times
- At some point, the address bar should be focused instead of the dialog
buttons
Explanation: the chatter is present in the DOM but not displayed so the
last tabable element that is detected by getTabableElements is a child
node of the chatter which cannot be reached.
OPW-3584847
closesodoo/odoo#148382
X-original-commit: c631bf09b927003edc4c2b85e8790e8e2e8c044a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Commit [1] allowed restricted editor to use the optimize seo dialog:
- When they have write access on the record, they can fill the form and
save changes
- when they don't have the write access, the form is in readonly and a
warning is shown to explain it.
But a mistake was made: the restricted editor, when opening the SEO
dialog on a website.page, would receive an access error directly when
reading the SEO fields, instead of the expected readonly SEO dialog
without a save button.
Step to reproduce:
- Login with a restricted editor with no extra rights
- Go to / homepage
- Open the optimize seo dialog
- An access right error is shown
[1]: https://github.com/odoo/odoo/commit/891162574eead15cf64a4f934e5f12346cbcfbbfclosesodoo/odoo#148280
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Prior to this commit, the test test_customer_notes was failing
when run without demo data. It was due to the use of base.res_partner_2
which is a demo partner. The fix consists in creating a new partner
for the test.
closesodoo/odoo#148188
X-original-commit: 6554a40472c30056310ebd4b1143486b38de9198
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
New module that adds peruvian requirements to the website ecommerce
* Add fields to the checkout form
*Identification type
*City
*District
* Add logic to validate the new fields
* Take into account the identification type when validating the VAT in the checkout form
* Change label name for the vat field, to show "Number" instead of "VAT number".
* Add demo data to display a peruvian website and show products with taxes
* Add module translations
* Hide default city
* Refactored code to create the function
_changeOption which combines the functionality
of _changeState and _changeCity.
closesodoo/odoo#130155
Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Andrea Geraldo <myrna.andrea@vauxoo.com>
Steps to Reproduce
===================
1). Create an opportunity, and give it a new contact
2). Set Joel Willis as the reseller (needs a partner grade for that)
3). Log in as Joel, and try to open this opportunity through the portal
-> Access Error 403
Technical
==========
We are trying to show the avatar of the partner because a portal user doesn't
have access to see the avatar so 403 forbidden errors occur.
This problem occurred after this commit: https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8
After this commit
=================
Now portal user can see the opportunity.
Task-3580254
closesodoo/odoo#144113
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Instead of replacing the default taxes, the key has been duplicated
in the dict. (0870357cc4)
So, instead of assigning the new tax, it is overriden by the old keys.
So, the old tax is still the one referenced in the template.
l10n_ee: the old tax has been deactivated, and the default_tax hasn't
been changed.
Added the tag to the test so it will be seen on merge next time.
Linked to runbot error 52792
closesodoo/odoo#146652
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
When a user connects to its database that has been freshly upgraded
to 17.0 database, he gets the following JS crash:
```
TypeError: can't access property "defineLocale", moment is undefined
@http://www.odoo.test/web/webclient/locale/fr_FR:13:10
@http://www.odoo.test/web/webclient/locale/fr_FR:9:4
@http://www.odoo.test/web/webclient/locale/fr_FR:10:2
```
Before 17.0, the `/web/webclient/locale/<string:lang>` route was used
to get the appropriate `momentjs` locale and was cached for a duration
of 1 week.
So when connecting to the upgraded database we will get the cached
file, but as `momentjs` has been removed (see odoo/odoo@4327c062d8)
it will crash.
Now as `luxon` is using browser's `Intl` to get the translations, we
can safely remove the call to that endpoint (it will always return an
empty file anyway)
closesodoo/odoo#145733
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
We have added a new security group which requires an additionnal query
to verify that a user belongs to a security group.
closesodoo/odoo#146263
Related: odoo/enterprise#51731
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
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>
Adnan Saiyed