* Current Status
- when remove attachment or message, The system will perform deletion on
the interface before performing deletion in the DB. However, in some
situations, exceptions will occur during the deletion process. So it
will happen that the attachment or message has been deleted on the
interface but still exists under the database. From a function that
helps optimize user experience, it will cause a worse situation with
user experience
* Solution
- Make rpc calls before deleting messages or attachments on the
interface
closesodoo/odoo#161023
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this PR, the error displayed in the public page was quite
cryptic. It was hard for the user to understand that error and even
harder to report it if needed. This PR makes the error more user
friendly.
task-3850559
closesodoo/odoo#160947
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts and create a contact from San Marino:
* Name: SM customer
* Country: San Marino
* Street, City, ZIP: [any]
* Destination Code: [any]
- Create an invoice:
* Customer: [the created contact from San Marino]
* Product: [any]
- Confirm the invoice
- Generate E-invoice XML via "Send & Print" button
Issue:
In the XML, the destination code (i.e. CodiceDestinatario) is the
default one for non-Italian customer (i.e. XXXXXXX).
Also, the VAT number (i.e. IdFiscaleIVA) is the default value for
countries that are not in the European Union (i.e. OO99999999999).
However, since October 2021, San Marino should be handled differently
for Italian electronic invoices.
A specific destination code (i.e. 2R4GTO8) should be used for all
customers from San Marino.
Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/
Solution:
For customers from San Marino:
- Keep VAT number
- Set "2R4GTO8" as destination code
opw-3819054
closesodoo/odoo#160494
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In Spain, "Cooperativas" have their own variant of the Spanish chart of
accounts. In order to support these businesses, we add two extra CoA
templates: Cooperatives - SMEs and Cooperatives - Complete.
task-3803050
closesodoo/odoo#159357
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- Install mrp and purchase
- Go to "Inventory / Configuration / Settings"
- Activate "Storage Locations"
- Go to "Inventory / Configuration / Warehouse Management / Operations Types"
- Edit "Receipts" type by activating "Show Detailed Operations"
- Go to "Manufactoring / Configuration / Settings"
- Activate "Subcontracting"
- Create product: (e.g. Product XYZ)
* Product Type: Storable Product
- Create a BoM for Product XYZ:
* BoM Type: Subcontracting
* Subcontractors: [any] (e.g. Azure Interior)
- Create a PO:
* Vendor: Azure Interior
* Products: 2 x Product XYZ
- Confirm the PO
- Open the picking from PO via the Receipt smart button
- In "Operations" tab, set done to 1
- On the picking form, change the destination location (e.g. WH/Stock/Shelf1)
- Save
- In "Detailed Operations" tab, a line should have appeared
- Select the same destination location on that line (i.e. WH/Stock/Shelf1)
- Validate the picking and create a backorder for the remaining quantity to produce
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ (Search Product: XYZ - Group by: Location)
=> The "On Hand Quantity" for Product XYZ is as followed:
* Virtual Locations/Production: -1.00 (correct)
* WH/Stock/Shelf1: 1.00 (correct)
- Open the backorder picking from PO via the Receipt smart button
- Record the production of the remaining unit
- Validate the picking
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ
Issue:
The "On Hand Quantity" for Product XYZ is as followed:
* Partners/Vendors: -1.00 (incorrect, it should be empty)
* Physical Locations/Subcontracting Location: 1.00 (incorrect, it should be 0.00)
* Virtual Locations/Production: -2.00 (correct)
* WH/Stock/Shelf1: 2.00 (correct)
Cause:
When the PO is confirmed, the stock picking and the stock move are created, they both
have the same source and destination locations.
However, in an overridden method from "mrp_subcontracting" module, a check is performed
on the move to determine if it is a subcontract.
If it is the case, its source location is set to the subcontractor location and so, the
source location of the picking and the move is not the same anymore.
When the destination location is changed on the picking, an onchange is triggering an
update of the destination location AND the source location of the move to the values
coming from the picking, erasing the subcontractor location set on the move.
The issue only happens for the backorder, because the source location update is not
propagated to the stock move lines.
In the case of the original picking, the move lines were already created with the
subcontractor location as source location.
But when the backorder is created, the move lines are created with the values coming
from a move without the subcontractor location.
Solution:
Do not propagate "location_id" from the picking to the subcontracting moves.
opw-3777379
closesodoo/odoo#161011
X-original-commit: e0f7577da1a42512d2fdc5ee316f27a1ce040522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
-Same behaviour as [1] we should use slug(job) instead of job.id
1: a2c6ddf8158bf40f13b5c5a8b89deb3d2ae8af6b
closesodoo/odoo#160972
X-original-commit: 721a8bd4b06668dac9fad0ba08a95b7943331918
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Issue:
When we have open tickets from anyone with
the email domain @proton.me, they are linked
together even though this domain is generic,
not a private one.
same issue with @cegetel.net and @dbmail.com
Steps To Reproduce:
- Create three tickets with "@proton.me"
domain but different addresses.
- See that in the smart button, the tickets
are linked to each other even though the
customers are different.
Solution:
- in `_compute_partner_ticket_count` we check
if the email domain of the partner is in
`iap_tools._MAIL_DOMAIN_BLACKLIST `, if not,
we consider the email to be a company email
which tickets can be grouped by.
- the _MAIL_DOMAIN_BLACKLIST is a list of generic
email providers on which IAP services should not run.
Retrieving company information from them makes no sense.
- To fix this issue I added `proton.me`,
`cegetel.net` and `dbmail.com`
to _MAIL_DOMAIN_BLACKLIST
opw-3786308
closesodoo/odoo#160804
X-original-commit: 0258fccc217142e66873c1dbb99efbfdd70a3887
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Issue:
=====
double scrollbar appears in notes.
Steps to reproduce the issue:
=============================
- Go to notes
- Insert a table
- Add some columns and try to stretch the last one to the right until it
goes outside the width of the editable.
- Click on the last cell to the right in the table and scroll left
- Another scrollbar will appear.
Origin of the issue:
====================
The part of the table that is invisible in the editor is considered as
overflow for the `html_field` so it will show a scrollbar which is not
needed since we already have a scrollbar in the edtibale.
Solution:
=========
We mark hide the overflow in `html_field` and let the editable takes
care of the overflow.
task-3721794
closesodoo/odoo#160953
X-original-commit: c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Small improvements on the download logs button in the Iot App:
- Log file contains the IoT name and date of generation
- Internal server error araise if the logfile config is missing
- Internal server error aised if the log file is missin
Was meant to be part of:
https://github.com/odoo/odoo/pull/159186
opw-3827121
closesodoo/odoo#160755
X-original-commit: a6bcfce6714c4a804fe84d81d8b9ee29c1440046
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
Steps to reproduce issue:
1. Select a boxed layout document
2. Create an invoice and add lines until the pdf version is on two pages
3. Print the pdf
4. On every page except the first one, the body of the document is cropped by the header
Explanation:
The PDF consists of three parts: the header, the footer and the body, and they are added separately. The body is delimited by the paper format and margins. Those do not depend on the size of the header and the footer.
In the boxed layout, the height of the header is bigger than the default size of the top margin of the body. Because of that, it covers a part of the body.
Suggested fix:
By removing some whitespace, the header size has been reduced to a size smaller than the default margins of the document while keeping every information readable.
opw-3768511
closesodoo/odoo#160925
X-original-commit: 08ec6a850b1959f71833d1ea7b39f50ab7ff4ed8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Steps to reproduce:
- Create a storable kit product
- Update on hand quantity:
only the components are displayed(correct behavior)
- In Inventory tab open Inventory Adjustement
- Possible to edit kit quantity
Bug:
In the product tab when trying to update qty the kit product is
replaced with its components instead but it is still Possible to
edit kit quantity directly in the inventory app
Fix:
introduced python constraint to prevent user from directly editing
the kit product qty in master
in standard just display a warning
opw-3681703
closesodoo/odoo#160978
X-original-commit: ba81d4ef64933dc025c7a473456c5c056ed69aac
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Create a SO with the following lines:
1. Price Unit 10000, tax 20%
2. Price Unit 10000, tax 20%
3. Price Unit 10000, tax 20%
4. Price Unit 50, tax 20%
Confirm, Create a downpayment of 840.0
Check the downpayment
Issue: Amount will be 840.01
This occurs because we compute the downpayment values aggregating
so line amounts line by line, each time multiplying for the downpayment
percentage and rounding the result.
Over multiple lines this mechanism may accumulate a rounding error.
opw-3812925
closesodoo/odoo#160781
X-original-commit: 1a21f40274d7d7c3c5029c3bb83214618cc2384f
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Before this commit, we didn't correctly detect when to prefix the
value of an url field for the href of its link.
closesodoo/odoo#160916
X-original-commit: 27458e3bdb545f550e60f1bd39addf188151c38b
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behavior:
Cannot send SMS to a partner that has
a mobile phone number from Panama.
Steps to reproduce:
parsed = phonenumbers.parse('6198 5462', region='PA')
is_valid = phonenumbers.is_valid_number(parsed)
is_valid == False
Cause of the issue:
Old versions of phonenumbers (external library) are not
updated to Panamas mobile phone numbers system change.
Fix:
Monkey patched the library
Similar as: https://github.com/odoo/odoo/commit/b21df8797141dac9f2cf0315658a08a238849f5b
opw-3682631
closesodoo/odoo#160885
X-original-commit: 1b6611f5d2d381ec53de8fce103759d6a5717d79
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Confirm an SO with a storable product
- in barcode app open the created picking
- Scan a different product confirm the picking and create a backorder
Bug:
the new product is not added to the SO and the original picking isn't
linked the SO anymore
Root cause:
when new moves are created in the inventory app default_picking_id
is set in the context and is used in _default_group_id to set the group
Fix:
explicitly set the group_id when creating the move instead of relying
on the defaults from the context when possible
test: https://github.com/odoo/enterprise/pull/57408
opw-3644773
closesodoo/odoo#160812
X-original-commit: adb072ce198454801d306df90f30a14a79e3dd3d
Related: odoo/enterprise#60200
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead of using information from the vendor line that is used for the price.
Steps to reproduce:
-------------------
* Go to the **Purchase** App
* Go to **Products**
* Select any product
* Select the **Purchase** tab
* Add `Vendor Product Name` and `Vendor Product Code` in additional line fields
* Add two vendor lines
* Line 1:
`Vendor`: Vendor1
`Vendor Product Name`: P1
`Vendor Product Code`: A
`Price`: 1
* Line 2: <br>
`Vendor`: Vendor 1
`Vendor Product Name`: P1 bis
`Vendor Product Code`: B
`Price`: 5
* Select **Orders** > **Request for quotation**
* Create a new quotation
* Select Vendor 1, add the product for which we just added the two vendor lines
> **Observation**: The description of the product shows information from both vendor lines added.
Why the fix:
------------
This behavior was introduced when `name_get` was removed to use `dispay_name` instead.
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210
When adding a product to the purchase order, the onchange on `product_id` is called. The onchange calls the function `_product_id_change`, which itself calls `_get_product_purchase_description`.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1224https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1401-L1407
The line `name = product_lang.display_name` calls the function `_compute_display_name`.
* We do have a parnter_id in the context as we have selected a vendor on the purchase order.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L434
* We don't have a supplierinfo in the context yet but we have multiple supplierinfo with the same partner_id.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L466-L467
Here we thus have 2 sellers.
* Ultimately, the display name joins the different display names computer for each seller.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L473-L483
Coming back to the line `self.name = self._get_product_purchase_description(product_lang)`, we now have the name of the purchase order line set as the concatenation of display names from the supplierinfo, i.e `'[A] P1, [B] P1 bis'`.
Once the onchange is called, the function `_compute_price_unit_and_date_planned_and_name` is being called.
https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1295
In the current state, we do not meet the if condition. Indeed, the line has a name (`'[A] P1, [B] P1 bis'`) but it isn't in the default_names (`['[A] P1', '[B] P1 bis']`). It somehow corresponds to a setting where the name of the purchase order line was setup by the user.
With this current fix, the call to `_product_id_change` will set the name of the line with the product information from the company; and not the partner. We also need to add this name to the `default_names` in `_compute_price_unit_and_date_planned_and_name` so that the description get recomputed with regards to the seller, if any.
opw-3802182
closesodoo/odoo#160778
X-original-commit: 6974f5303badbc5f5db104270f9492c12a52f220
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
It should not be common, but through custo or in debug mode, one can
create a menu without an URL since it's not required on the model.
Through regular flows, it won't be possible since our UI won't let you
go through when creating a menu if you don't set a URL.
Followup of https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20
X-original-commit: f2ac2ab72a190375c8116a11109191c0b7b970dc
Part-of: odoo/odoo#160588
Don't show HSN value for sale.order not linked to this localization.
Before this commit, if you have multi company with multi localization,
you see this field whatever the current localization.
It uses the same condition than other report: purchase/invoice/...
closesodoo/odoo#160833
X-original-commit: e2a684018d7f92994aa5d30ded8f64703254f0fb
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Without sudo, an user in a company can change the type even if somes not done stock.move.line exists.
closesodoo/odoo#160856
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The conditionnal `isinstance(exc, NotFound)` is shadowed by the
conditionnal `isinstance(exc, HTTPException)` two lines above. Nobody
ever complained that the warning for NotFound error was gone. Since
werkzeug 1.0.0, the status code in the response log is colored, 404 is
colored yellow which should catch the eye. The explicit warning line
isn't really necessary.
closesodoo/odoo#159895
X-original-commit: 851b91f19b87446662421cb8d801a9472725bc72
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit:
The cursor kept on flickering when attempting to enter a space at the end
of label text field of a link resulting in not being able to add space at all.
After this commit:
Now, it's possible to add spaces at the end of a link label.
task-3820250
closesodoo/odoo#160780
X-original-commit: 1af59ba5054dae5272506aead8b2c8dd0e5616fb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
How to reproduce:
- Install website_slides with demo data
- Log in from localhost
- Log in from dev.localhost
- Switch to localhost
- (The system property web.base.url is http://dev.localhost:8069 but we are
on localhost)
- Go to a course in the back end and click on “Go to website” button
You are redirected to the frontend website home page instead of the course
home page.
This fix solves the problem.
Afer correcting this error for the courses (slide.channel), we have found the
same problem for:
- event.sponsor
- event.meeting.room
- slide.slide
So we apply the same correction for them.
Technical note: the button "Go to website" uses the open_website_url method of
WebsitePublishedMultiMixin that relies on website_url. That method expects a
relative URL in the computed field website_url and not an absolute one
(actually, the method already handle adding the website domain, so it expect
the relative part). The problem is that the compute method for the field
website_url of channel compute an absolute URL. The consequence is that the
user is redirected to the home page instead of the course page (by
WebsitePreview, see get path method). In stable, we cannot change easily
website_url to make it relative as it is used in other of places (ex.: if we
make it relative the share link in the sidebar on the frontend is relative
which is not correct and in mail template, the URL might not be correct as the
mail system append the default domain for relative URLs). So instead, we
override open_website_url to use a relative URL when the website is not
defined. If the website is defined on the course, we call the super
implementation because a domain change might be required. Note that by doing
that, we duplicate the code of _compute_website_url in open_website_url but
making the URL relative instead of absolute. So we should clean that in master.
Task-3635856
closesodoo/odoo#160763
X-original-commit: 1f798428fc0f403755512a45f67b5f70aae0c808
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Pierre-Yves Dufays (pydu) <pydu@odoo.com>
In mobile, having a somewhat 'large price' (like a few thousands
currency units) can cause the bottom of the card to overflow (esp.
if buttons like 'add to card' or 'add to wishlist' are present).
This commit modifies the card template so that content is normally
spaced and can wrap to a new line if need be.
opw-3706637
closesodoo/odoo#160628
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Resolves an issue with Afterpay via Stripe not receiving correct
shipping address details, causing transaction failures. Now,
ensures shipping address from the order or invoice is accurately
sent to Stripe if we have it.
opw-3419984
closesodoo/odoo#160300
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Previously, methods on python objects such as sets and strings were
implemented as functions returning a function returning the result.
While curried functions can be a great tool, they're also confusing at
first glance and in this particular case they can be easily replaced by
a simple function and the usage of Function.prototype.bind to bind it to
the correct argument. We also add a simple whitelist for pyjs functions
as a sanity check as it makes no sense to call JS functions from python
code.
With this change, we can also treat functions and methods from any
object more uniformly instead of having many return points that are
treated like special cases.
task-3762958
Part-of: odoo/odoo#139451
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit[1] aimed to fix a layout issue inside the eCommerce categories
form view on mobile devices.
Prior to Commit[1], a `.float-start` class was applied to the content
of thesheet, moving it "out of the flow", resulting in a wrong sized
form_sheet.
To fix the issue, we removed the `.float-start` class, but doing such
a change introduced a risk for users's customizations.
======
After
======
To prevent this issue, we reintroduce the initial lines, and will provide
a fix in another PR.
Commit[1]: 9837396
Related to task-3847917
closesodoo/odoo#160858
X-original-commit: 0914a0bd179a6b644e51de25bfad0555ea0f40ca
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
The main purpose of this test is to ensure that line return are removed,
but all other special character are kept once the file is saved.
Unfortunately, werkzeug versions have different strategies on how to
quote the filename, removing less special character in latest versions
like after https://github.com/pallets/werkzeug/commit/babfc93b3834bcbb22163442a9af70141bcc5a81
This also changes after the changes that removed werkzeug urls methods
replacing them by urllib, making the behaviour different again.
This commit makes the test more robust by checking that the filename
correspond to the expeted one once unquoted, not comparing the quoted
versions.
Part-of: odoo/odoo#160842
In ubuntu noble, some timezone where removed leading to errors when
trying to assign/access them.
This was partially fixed in the code by removing all references to old
timezones but one issue remains: if a database contains timezones that
are not defined in the os, the resolution will fail and break at runtime
This patches proposes to alter timezone to fallback on the new canonical
timezone if the timezone was removed.
This list was generated by checking all symlink in /usr/share/zoneinfo
in ubuntu 22.04 that disapeared in ubuntu 24.04
This solutions will work when moving a database from one server to
another, even without migration.
The all_timezone is not modified on purpose to avoid breaking existing
logic. This list may be used to define if a timezone is known by
postgress, define selection fiels, .... we don"t want to increase the
list in those case.
Some other logic using all_timezone may need to be updated but This
will be done in master.
Part-of: odoo/odoo#160842
Some of the non canononical timezones are not present in Ubuntu Noble,
it would be a better practice to only use canonical timezones in data
and tests.
Note that this is not a real fix for all cases since the database that
ran on Ubuntu Jammy and are moved to an ubuntu Noble server will have
the issue with timezones already in database.
One of the possible fix would be to manage that during upgrades, but
this isn't a verry flexible solution since upgrade are meant to manage
chyange of version, not change of server. If an old 17.0 versions needs
to be moved to a Noble server, this won't work.
Another solution would be to install package like tzdata-legacy that may
keep the old timezones but it is not the only think since TAI-10 are
also in this package. This solution is not ideal because non canonical
timezone will still be shown in the dropdown. We would need to filter
them.
A last solution would be to add the support for those old timezones by
monkeypatching the lib. This way, only new timezones would be shown but
non canonical one won't crash when used. This is not ideal either
because we may need to keep this for a while. But in combination with
the upgrade solution, it may work proprely.
Part-of: odoo/odoo#160842
In latest versions of werkzeug, the `werkzeug.urls` module has been
reduced to remove feature present in urllib.parse. This commit vendored
the old version to avoid breaking compatibility with older versions of
odoo on ubuntu Noble, without adapting the whole codebase. This
should/may be removed in stable by adaptaing eveything to urlib.
This version of the lib was minimalized to avoid redondunce with feature
still present in werkzeug.urls. Some unused features in odoo are still
vendored for ease but are not exposed on the werkzeug.urls for now.
Part-of: odoo/odoo#160842
When python expression is evaluated in odoo form an action or qweb, we
are checking the opcodes generated by the evaluation of this code. We do
such a verification, because the code from actions and templates can be
written by someone having not access to the server and we don't want to
let them perform actions out of the scope of their database.
In python 3.11, some opcodes from previous versions of Python have been
renamed, grouped or sepcified. There are also new ones that have been
introduce.
In this PR, we are whitelisting the new ones that are needed by odoo to
properly work in this version of Python.
Part-of: odoo/odoo#160842
This commit fixes an issue regarding unwanted interaction between the
regular autocomplete option click selection and the onChange handler
from the input field hook used in the PartnerAutoCompleteCharField
component. This became an issue starting from https://github.com/odoo/odoo/pull/154203
because of the disappearance of the t-on-mousedown.prevent handler
placed on the autocomplete options list which would prevent the onChange
event from being triggered when clicking on an option. The issue would
be that the onChange handler from the input field hook would take
precedence over the option click handler of the autocomplete which would
most of the time be ignored afterwards. The solution found for This
problem is to prevent the immediate propagation of the change event
in the autocomplete handler when an option has been clicked on so that
it will never be propagated to the input field hook handler in this case.
Steps to reproduce:
- Go to contacts and open a company contact
- Type in the name field a few characters (at least 3)
- Click on any autocomplete option
Most of the time, the option will not be applied and the name won't change
closesodoo/odoo#160561
X-original-commit: aa1e5eabb67800fbf4155c9cae12b90d97bb75db
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
this commit fixes an issue introduced by https://github.com/odoo/odoo/pull/154203
which could keep the autocomplete options list opened even after a click
away when the user would "drag and drop" an option out of the list instead
of simply clicking on it. This is caused by the fact that the onInputBlur
code is directly terminated in this case (because of ignoreBlur) while
it is the only way for the autocomplete list to be closed in this case.
The solution is therefore to add an external listener on pointer down
which will always close the autocomplete list when clicking away from it.
Steps to reproduce:
- go to any autocomplete (crm salesperson for example)
- click on the input
- drag and drop a result outside of the list
- try to close the autocomplete list by clicking away
Before the fix, the autocomplete list would only close by scrolling
or clicking on the input once again.
X-original-commit: 57801ab7292e3d369615740a5f67aac9a4b9a521
Part-of: odoo/odoo#160561
At the moment, the partner being used to get the information
for the efaktur module is the partner set on the invoice.
This is wrong, since if the partner set on the invoice is a
child record of a company partner you cannot set most of these
fields.
To fix this issue, we will update in order to fetch the efaktur
related fields from the commercial partner instead. (vat, along
with all efaktur specific information used in the process)
closesodoo/odoo#160267
X-original-commit: 108a87407b7c46cc1682d93524398a968b025441
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.
Task-3761551
closesodoo/odoo#160768
X-original-commit: 29497433bb7e19fd58287ba2af28fac4890b0b76
Related: odoo/enterprise#60185
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Mohammed Basioni (basm) <basm@odoo.com>
At the moment, duplicating a website is not possible in the sense of
duplicating content, pages, etc. It is still available as an action from
the form view, and it could make sense to start up a new website with a
few common values (social media? etc?)... but many of website fields are
technical fields that should not be copied and many are dubious to copy
and not even visible in the form view. Really, duplicating a website at
the moment is misleading. This commit disables the possibility from the
form view.
In the future, we want to focus on the ability to export / import a full
website, but that's not for now.
opw-3782830
closesodoo/odoo#160587
X-original-commit: 43971a22c56b197306060ac3be7903d36d2c4be9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Related to previous commit: a9a9d2f12740b02c025f992d62c0d4f5feeaab1d
From initial PR: 158843
Improve Regexp to match double slugs /blog/blog-1/post-2 or /blog/1/2
Ignore param order: `?a=<param>&b=<param>` == `?b=<param>&a=<param>`
Remove trailing / from base url when querystring is present
Ignore '/en' url instead of '/en_US' since the default url_code has been
updated meanwhile (269aa59411).
Add a new test to check that urls are cleaned as expected
Remove crawl as admin, since the demo user already have all groups and
so we will check the same urls. The overlap is important for a really
low value.
X-original-commit: f17b210c6ad2364aebc6199153523ea5b767f67f
+ remove support of # part in clean url, not handled server side
+ support path in querystring (forum_origin)
closesodoo/odoo#160409
X-original-commit: 818e7af5650fae464090e7249f776193dc2b3814
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
On firefox and safari applying a position-sticky on an element inside
an other element with an overflow is causing a rendering issue (see
issue [1]).
This was occuring with the dropdown `.o_optional_columns_dropdown`
making it unusable as soon as the `overflow-x` triggered the horizontal
scroll in the table.
This commit works around this bug by moving the dropdown's menu out of
the actual table and attachs it to the ListRender's root element.
As this issue is specific to the Optional Fields dropdown, we
implemented it only in the ListRender (and not for all Dropdowns). Also
the issue is not present anymore in master since the Dropdown
refactoring (see PR [2]).
Note: a unique class identifying the ListRenderer has been introduced to
handle multiple List Views rendered at the same time (in the same view,
in modal...) as the the `t-portal` requires a global selector and
doesn't allow to use relative one (i.e. searching only the parents ; cf.
OWL feature request [3]).
task-3696473
opw-3682280
opw-3697814
X-original-commit: 01cd6d4d0cfa418f5a72a90742d10ee44af523a4
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1887116
[2]: https://github.com/odoo/odoo/pull/137691
[3]: https://github.com/odoo/owl/issues/1428closesodoo/odoo#160566
X-original-commit: 9a9da10bf5d1c0f96f48c9d56807512e0ad1d6ef
Related: odoo/enterprise#60116
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Soncrits