odoo-2 #170
Open
odoo-2 #170
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
2 similar comments
|
|
|
|
To replicate the issue: - Go to the partner page of the current company (Invoicing > Customers > Customers > Look for the company) - Change type from Company to Individual - Create and post an invoice - Click on Send & Print. Download the Facturae - NAME should appear in line 30, before AddressInSpain, but it doesn't Cause of the issue: The template values do not include a value for self_party_name, only for other_party_name. In the template, when partner_name is set, no value is passed for self_party. Fix: Instead of only extracting the partner name for partner (other_party), the code is used in a new function, which can be called for both partner and company (self_party). Then, self_party_name can be used as a value in the template. opw-4053023 closes #173608 Signed-off-by: John Laterre (jol) <jol@odoo.com>
In the POS Restaurant module, there was an issue where an order could be missed in the backend if a draft order, opened by a cashier on one device, was paid for on another device. Subsequently, if the cashier added more products to the order and completed the payment, the receipt would be printed, but the backend would fail to record the updated order. This fix ensures that an updated order with the same reference is captured in the backend if its content has changed, preventing data loss and ensuring consistency across devices. opw-4067875 closes #174200 Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit, search results for chats and channels on mobile show up in uppercase. This happens because of the class `text-uppercase` on a parent element. This commit fixes the issue by removing said class on the parent element. closes #174224 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit: When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages. After this commit: This commit updates the useMessageSearch hook to handle simultaneous requests more robustly by checking that search results are defined before processing them. This prevents errors and improves stability during rapid searches. closes #174174 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
*loyalty, pos_loyalty, sale_loyalty
Currently, archived products that are used in loyalty programs may cause
the POS shop to crash.
Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Go to the products
* Look for the product `Simple Pen`
* Archive the product
* Add some product to the order
* Add a customer that has loyalty points (`Azure Interior`)
> Observations: Blank screen. Error in the console: Cannot read properties of
undefined (reading 'id') at Proxy._computeUnclaimedFreeProductQty
> Doing an equivalent flow in sales, when you select `Promotions`, an error
message appears saying: Invalid Operation. Invalid product to claim.
Why the fix:
------------
When loading the `loyalty.rewards` to the pos session we check if there is
at least one active product. If there is none, we don't load the reward.
Explanation of the domain:
* We only filter in the case where the `reward_type` is `product`.
* Second condition:
* We cannot have a condition like `('reward_product_id', '!=', False)`
We could have a setting with both `reward_product_id` and `reward_product_ids`
being set. In this condition it would skip the check on `reward_product_ids`
* We connot have a condition like `('reward_product_ids', '!=', False)`
as `reward_product_ids` is always at least an empty set, thus it will
always be '`True`'
* We put the condition on `reward_product_tag_id`. When there is one set
the computation of `reward_product_ids` is triggered. `reward_product_ids`
will always include `reward_product_id`.
When there is no tag set, we will always, at least, have a `reward_product_id`.
opw-3968140
closes #174091
X-original-commit: 09bb0d7
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Context: when visiting the `/partners` url, the user has access to the
"silver", "gold" and "platinum" grades. However, when generating the
sitemap, the `/partners/grade/bronze-4` url is part of it but trying to
access it leads to a 404 server answer. Another problematic behavior is
that if the user deactivates a grade ("gold" for example), the grade is
still accessible from `/partners` (but the `/partners/grade/gold-2` url
is not on the sitemap anymore).
This can be explained as:
- When visiting the `/partners` url, the `partners` route searches for
grades from `request.env['res.partner']`. By doing so, it ensures that
grades are linked to at least one partner; this explains why the
"bronze" grade (not linked to any partner) is not shown at the
`/partners` url and why the deactivated "gold" grade is still
accessible (as a partner is still related to it).
- When the user tries to reach a `/partners` route, a 404 server answer
is returned if no partners are found for the route (e.g.
`/partners/grade/bronze-4`).
- When generating the sitemap, the system is searching for grades from
`env['res.partner.grade']`. Due to it, inactive grades (e.g. "gold") are
not shown on the sitemap and grades that are not linked to a partner
(e.g. "bronze") are shown on the sitemap.
The goal of this commit is to:
- Correct the `/partners` route so that it does not show inactive
grades.
- Generate the sitemap coherently from what is done in the `/partners`
route.
In the end, the `/partner` route only shows company website published
partners linked to active website published grades. The user has then
the possibility to filter the partners by grades or by country.
opw-3992340
closes #174250
X-original-commit: ffb3f26
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Steps: - Create a new Discount and loyalty program. - Keep the program type as Buy X Get Y / any other program - In the rewards pop-up, leave the 'description on the product' empty and click on 'save & close'. - Try to save the loyalty program. Validation error appears. Cause: - This occurs because the description is used to set the name of the discount product, but if it's empty, the write method will not get the proper values hence resulting in error. Fix: - Raise user error if the description field is set to empty. Affected Version: 16.0 - saas~17.4 opw-4032798 closes #174261 X-original-commit: 1b62b87 Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. task-3794551 closes #168447 Signed-off-by: Laurent Smet (las) <las@odoo.com>
…e state Steps to reproduce: - Open Project - Go into any project in kanban view - Mark any task as done. - From the progress bar click on done section Issue: - You can see that the color is not applies while grouping tasks using progress-bar. Cause: - Missing css-kanban-filter which supplies the color to be applied while grouping by progressbar. - Adding CSS-filter is not done because success-done i.e. color of done tasks is not from standard CSS library(I.e. Bootstrap). Solution: - Add the CSS filter for done stage name as success-done. task-3852596 closes #163086 Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
Before this commit: Inserting text into an empty paragraph tag with a `br` does not remove the `br`. After this commit: Inserting text into an empty node with a `br` should result in the removal of that `br`. task-3630662 Part-of: #173890 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit: When pasting single or multiple block elements the start and end block would unwrap causing inconsistency while pasting. After this commit: Make sure if the node to start or end with is the same node we want to paste into; unwrap it, otherwise split the node. When pasting nodes onto a blockquote or pre node, all the nodes are converted to match the format of the node they are pasted onto. task-3630662 Part-of: #173890 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit: Unwrapping the firstChild and the lastChild when pasting empty blocks resulted in the addition of br's to the block. After this commit: Empty blocks are no longer unwrapped when pasting. task-3630662 Part-of: #173890 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit: When the container to paste's last element is an empty element the insert command fails to implement oEnter and causes a traceback. After this commit: Make sure the if the last element is an empty element it must have at least an br element. task-3624809 closes #173890 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When importing a sale in PoS and doing a downpayment there was only one downpayment line created. And because of this the taxes where not always correct. If you do a 100% downpayment you would end up with negative untaxed amount on the invoice. Steps to reproduce: ------------------- * Create 2 taxes, A and B with 5% and 10% * Create 2 products, A and B. Assign the 2 taxes to the products * Create a sale order with the 2 products * Open the sale order in PoS and make a downpayment for it > Observation: There is only one downpayment line when it should have 2. Why the fix: ------------ If you do the same flow in the sales app, you get 2 downpayment lines. We do this to allign the behavior in sales and PoS. For each unique tax combination we compute what part of the total downpayment should be assigned to it. Then we make sure that the taxes are assigned to the line and that the line has the right value. opw-3999047 closes #174076 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Fixed printer and serial devices detection: both listing more devices than expected. closes #174164 Task: 3947355 Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Previously, the amount sent to Mollie always had 2 decimal places. However, Mollie supports 0 decimal places for amounts in ISK and JPY so it failed for payments in those currencies. This fix adjusts the decimal places sent to Mollie according to the currency. opw-4011259 closes #174278 Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
Issue ---- The date fields in the activity view aren't displayed according to the language's date/time formats. Steps ----- - Go to Settings -> Translations -> Language. - Use a custom date & time format. - Create a new model that has an activity view, say a project task. You'll see the task's deadline is displayed according to your format (correct behavior). - Add an activity and set a due date. - The "Created" & "Due On" dates don't match your custom format. Cause ----- In the activity component, the dates weren't formated according to the current language's date/time format but rather a hard-coded one. opw-3929864 closes #168074 Signed-off-by: Moataz Hussein (mohu) <mohu@odoo.com>
Before this commit: Long texts overflowed beyond the banner's boundaries. After this commit: Ensure that text remains within the banner's limits to improve readability and visual consistency. task-4037185 closes #172071 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
Generated invoices does not appear in the page 'Manage Attachments'.
Steps to reproduce:
- Activate the developper mode
- In Accounting > Customers > Invoices create a new one
- Confirm and click on Send & Print, an invoice is generated and can be seen in the attachment of the chatter
- Click on the debug icon then on 'Manage Attachments'
- The attachment does not show up
Cause:
The domain used for the 'Manage Attachments' search does not contain restriction on res_field and id. So a new condition is added: ('res_field', '=', False). The logic behind this functionnality is explained in this commit: 1bb61c9
In the case of invoices res_field is equal to invoice_pdf_report_file so the invoice does not appear.
Solution:
Add a context to the search request to skip the res_field test. Thus showing all attachments.
opw-3997094
closes #172722
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Summary
-----
In the method load in models.py, when there is an error when we try
to create a recordset with at least 2 records, we try to create each
record separately.
Only the errors caught by creating these single records are displayed
which is confusing.
Steps to Reproduce
-----
1. In Accounting > Configuration > Accounting > Chart of
Accounts, create an account with the type "Off-Balanced Sheet"
2. On the same page, import a Chart of Account (import journal
items) by uploading a file which contains the following lines
(example available on the ticket):
[
['move_id','account_id','balance' 'journal_id','date'],
[<move_name>,<account_code_1>,1,<journal_name>,2021-01-01],
[<move_name>,<account_code_2>,-1,<journal_name>,2021-01-01]
]
such that:
- move_name cannot exist
account_code_1 is the code of the created account at
first step
account_code_2 is not the code of an account with the
type "Off-Balanced Sheet"
- journal_name is the name of an existing journal
3. Test or import the uploaded file and see the error which does
not mention the "Off-Balanced Sheet" account.
Cause
-----
If a journal entry contains a line with an "Off
Balanced Sheet" account, then all the other lines must have an
account with the same type.
So when we try to load the lines of the uploaded file, it raises a
UserError which is caught (which is not added to the list 'messages').
Then we try to create the lines one by one which and that raises an
error too because the balance is not null.
Only these errors are added to the list 'messages' which contains the
displayed error messages.
Fix
-----
Add the first error to 'message', and ensure that the next errors are
not already in 'messages'.
opw-3945687
closes #173094
X-original-commit: 5d4a24a
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
and prevent parsing raw text as html. also impacted: test_mail_full Since ac71319, when sending an SMS via the composer, the sms body passes through plaintext2html then html2plaintext in order to have simple html respecting links in the chatter while keeping plaintext in the sms. It was overlooked however that plaintext2html converts links by adding links footnotes mark and a footnote, both of which make the sms unnecessary longer. Furthermore, it seems like converting html into text is probably not the desired behavior either, except when sending an SMS notification from a rendered HTML template. To solve this simply, we are * Reverting the above-mentioned commit to not parse sms body as html but instead escape content, add links on urls, and preserve new lines. * adding an extra parameter to _notify_record_by_sms to be able to directly pass plaintext and by-pass useless sanitation in that case * making message_post responsible for sms formatting instead of message_sms, so the latter does not become the entry point for sending raw sms content to be correctly formatted for the sms and its notification. Several tests are added covering all this. Task-3502174 X-original-commit: 11eab62 Part-of: #173285 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When adding opt-out link or any link in the text, the characters count was incorrect which made SMS campaigns more expensive than expected when added characters meant more SMS to send for the message. Task-3502174 X-original-commit: e5b88d3 Part-of: #173285 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce: - In website edit mode. - Drop enough blocks into the page to have a vertical scrollbar. - Click on the header. - Select the "Vertical" template in the options of the header. - Select the "Fixed" scroll effect in the options of the header. - click on the logo in the header. - Enter "80px" in the "Height" input in the options of the "Navbar Logo". - Scroll the page to the bottom. - Then, scroll the page to the top. - Bug: the "Navbar Logo" overlaps the navbar links. This bug occurred because the header size was calculated before the transition animation for the header height was completed. opw-4078173 closes #175653 Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Since [1], Werkzeug 2.2.2 or 3.0.1 is used depending on the python
version.
Unlike Werkzeug 2.0.2, Werkzeug 2.2.2's `url_quote` does not escape
single quote characters to ´%27´ anymore, and Werkzeug 3.0.1 does not
even provide `url_quote` anymore.
The monkey patch provided in [2] which is used when Werkzeug 3.0.1 is
running was copied from Werkzeug 2.2.2 and therefore does not escape
the single quote character to `%27` either.
This causes an issue for cover images that use the computed `image_src`
in a `background-image` CSS property using `url(...)` or `url('...')`.
This commit restores the former behavior of `_compute_image_src` to
avoid issues when its output is used in inadequately quoted CSS
properties.
Steps to reproduce:
- Use python_version >= '3.12' so that Werkzeug is 3.0.1.
- Create a new blog post.
- Set a cover image.
- Save.
=> Image is not displayed anymore because URL contains `'`.
[1]: 4a019ae
[2]: https://github.com/odoo/odoo/pull/160853/files#diff-1edfea7196bcb1ab64e1daf151095870945fa4dfdae14a8f15ccc8f6b8497502R604-R605
task-4099056
closes #175815
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
i found that context is never passed in '_duplicateRecords' function for list views, when making 'orm' calls from js side, while it is passed in 'duplicate' function of record, which is called when duplicating record from form view. use case: In sale_renting module, There is difference in the result, when a sale_order is duplcated from form view(duplicated properly) and when it is duplicated from list view(unexpected result). When duplicating a sale_order, its lines are also being duplicated, and at that time '_compute_is_rental' is being computed, which relies on context key 'in_rental_app'. 'in_rental_app' is set in the related action yet was not available when duplicating the sale_order from list view (which resulted in unexpected behaviour). closes #174137 Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Before this commit, searching for a sale order with a partner name containing special characters (e.g., &) would fail to correctly filter the sale orders. This commit ensures that partner names with special characters are properly handled, allowing for accurate sale order searches. opw-4062365 closes #174225 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, when using a product in a kit with a smaller unit of measure than the base product UoM, and the conversion resulted in a zero quantity, an unclear error message was displayed upon closing the PoS session: "Quantity or Reserved Quantity should be set." This error message lacked sufficient information, making it difficult to diagnose the issue, especially with multiple orders. This commit enhances the error message to clearly indicate the cause of the problem, providing specific details about the UoM conversion that resulted in a zero quantity. To reproduce the issue: 1. Create a product with a base UoM in kilograms (kg). 2. Include this product in a kit with a UoM of grams (g). 3. Set the rounding precision for both UoMs to 0.01. 4. Sell one kit through the PoS. The error would occur due to the quantity conversion from grams to kilograms resulting in zero, given the rounding precision settings. opw-4084783 closes #175007 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
steps to reproduce error:-
1.create db with 'point_of_sale' module
2.duplicate the record of pos_payement_method with journal type cash
3. install 'pos_restaurant' module this traceback will raise the or
start pos_session validation error will come
```
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1764, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/odoo/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1791, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1995, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 741, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "<decorator-gen-77>", line 2, in button_immediate_install
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 75, in check_and_log
return method(self, *args, **kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 466, in button_immediate_install
return self._button_immediate_function(self.env.registry[self._name].button_install)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 590, in _button_immediate_function
registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/odoo/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/17.0/addons/pos_restaurant/data/pos_restaurant_data.xml:4
You cannot use the same journal on multiples cash payment methods.
View error context:
'-no context-'
```
Here is the reason why above mentioned traceback is raised:
->
here
https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/addons/pos_restaurant/data/pos_restaurant_data.xml#L4
new record of pos.config is creating which trigger the check
of pos.config model due to that traceback is raised due to this validation
https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354
Current behavior before PR:
if we create ``new`` record journal_id field domain not let create
another record of journal with type cash if its already present
but if we` `duplicate`` record we can do which is not corrrect as per this validation
https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354
Desired behavior after PR is merged:
for resolving this not let duplicate journal_id. So, then select journal_id
with cash won't come again due to domain on journal_id records never will create.
From ui like this.
closes #175530
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Before this commit:
While generating an ewaybill we get the following traceback:
```log
File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 418, in _generate_ewaybill_direct
'ewaybill_expiry_date': self._indian_timezone_to_odoo_utc(
File "/home/odoo/odoo/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 433, in _indian_timezone_to_odoo_utc
local_time = datetime.strptime(str_date, time_format)
TypeError: strptime() argument 1 must be str, not None
```
After this commit:
We resolve the traceback it was caused due to
string to datetime conversion because we were
receving `None` value instead of datetime string.
Now `_indian_timezone_to_odoo_utc` will return
False, incase of missing string datetime from
the response
closes #176183
Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
Since commit adb5357, we have added a new DIV (`o_form_view_container`) around the form view. But the CSS selector for the sticky control panel was not adapted so the feature was not working anymore. This commit fixes the CSS selector. Steps to reproduce: * Open Odoo on small screen * Open the Contact App * Select a contact * Try to scroll down and up into the form view => Bug the control panel is not sticky Note : backport of PR 176015 closes #176215 X-original-commit: 1d2705e Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com> Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format This require us to add the triangular sales tax task-4080107 closes #174810 Backporting: a6bd404 Related: odoo/enterprise#67517 Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, performing a cash in/out operation in a session without any other cash transactions would result in the cash in/out not appearing in the report. opw-4076188 closes #175364 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When a menu link is defined towards an anchor, the scroll effect of the browser does not trigger from within the translated pages where the URL contains the additional path element about the used locale. The language is added in `ir.http`'s `url_lang` method, but we cannot always know the current URL at that point, nor during the template rendering - making it impossible to determine if the rendered anchor is local. This commit solves this client-side by first uniformizing the current and the target pathnames so that they both end with a `/`, and then, if they match replacing the link's target pathname by the window pathname so that the browser sees them as the same page. Steps to reproduce: - Install `website`. - Install a second language on the website. - Put some content in the Home page so that the bottom section requires scrolling to be seen. - Add a menu element that targets `#bottom`. - Either be a visitor or a connected user. - Go to the default language Home page. - Click on the new link. => Page scrolls to the bottom. - Switch to the second language Home page. - Click on the new link. => Page reloads targeting the bottom instead of scrolling. In master, remove `scroller_service.js` from `web`'s manifest. opw-3956066 closes #176077 X-original-commit: 5f45f6e Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com> Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Steps to reproduce: - Create 2 storable product - Update the on hand quantity to 100 only for the first one - Create an confirm an SO 75 units of each - Set the done qty to 50 on both moves and create a backorder - Print delivery slip for the original picking > The Ordered quantity is wrong on the product with no stock on hand (50 instead of 75). Cause of the issue: If there's no on hand qty the backorder move will not be associated to any `move_line` so that the `qty_ordered` will not be updated by these lines: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L785-L791 Furthermore, since they are not cancelled, they are filtered out here and hence do not update the `qty_ordered` by these lines either: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L813-L816 https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831 Fix: We modify the filter meant for empty move lines so that moves that are not confirmed and are not associated to any `move_line` contribute to the `qty_ordered` via these: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831 However, since we do not want a move that is fully backordered to appear on the delivery slip we need to filter out all the line keys that will be created, because they pass our new filtering condition (but didn't pass the old one), here: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L819-L821 opw-3957193 closes #176196 X-original-commit: 07d5b5c Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com> Co-authored-by: waha <waha@odoo.com>
Specification: when creating a widget percentpie with Studio, the field's name has been added after percent pie, which is not user-friendly. Expected behavior: The duplicate label should not be visible. Task-3942207 closes #172046 Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
If you were to refresh on a skipped question, the next_page_or_question would not be populated therefore causing any reference to this fail. There should not be a case where there is no next_page_or_question in _prepare_survey_data as the _get_next_page_or_question is only expecting an empty question in survey_submit. Adding a fallback to look for the next skipped question or page for when the next_skipped_page in the post parameter is lost in the http request through refreshing will allow this to work as expected. opw-4088129 closes #175933 Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
In this commit (464090d), we made the container for product images and media elements responsive. However, multiple clients did not appreciate the changes and like the images being highlighted. Additionally it was not the main focus of the ticket. opw-4056701 closes #176034 Signed-off-by: Abdessamad Zouiten (abzo) <abzo@odoo.com>
Set Company country to India Create a TAX as follows - Amount: 15% - Included in price: False - Tax repartition line: - 100.00% of tax to 100560 Tax Receivable - -100.00% of tax to 999999 Undistributed Profits/Losses Open Bank Reconciliation Widget Create a statement Match with Manual operation Select created tax Issue: created tax lines have no amount This occurs because when computing the tax amounts with compute_all if the configuration of tax is price included (enforced from context) and the tax is in cache we use the computed amount. Unfortunately in this particular configuration the amount is 0 opw-3986439 closes #176157 X-original-commit: e01eae9 Signed-off-by: Laurent Smet (las) <las@odoo.com> Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Steps to reproduce: 1. Create a storable product and set the quantity on hand to 100 units 2. Create a delivery of 20 units and mark as to-do 3. In the detailed operations, change the quantity to 10 units 4. Validate the transfer without backorder 5. Go to Inventory > Reporting > Locations 6. Click on Inventory at Date, and select a date one month in the past 7. The on hand quantity for the product is 10 Before this commit: When viewing a product's quantity in the past, the value was based on the `product_qty` of the done stock moves. However, this is the demand, and it is not always equals to the quantity that moved. After this commit: Use the quantity of the done stock move, which reflect better what really moved in the past. opw-3946354 closes #168456 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Specification: The time should not be reset when dragging an event in the month view. Observed behavior: Time is reset when dragging an event in month mode. Task-3432065 closes #171402 Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
When the current user is the system user, which happens during install and upgrades, the env company is possibly not included with the companies given to _get_query_currency_table, this can lead to a KeyError when fetching the rate for said company. closes #171605 Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce: - insert a pivot in a spreadsheet - add the formula =ODOO.PIVOT.TABLE(1) - share the spreadsheet - open the sharing link in an incognito browser window => only the top left cell of the table is present closes #175634 Task: 4089358 Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user closes #175686 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount + LINE.TaxAmount for LINE in invoice.invoice_line_ids]), obviously this poses a problem when we have a mix of down-payment and normal lines on our invoice since the formula does not differentiate between those. To fix this, we make sure that only down-payment lines actually include a Tax Subtotal breakdown (TaxableAmount & TaxAmount) closes #175761 X-original-commit: 3f5eccd Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
Steps to reproduce: - Install eCommerce module - Go to Website > Cart - Click on Edit > Customize > Extra Info - Go to Website settings and Check 'Extra Step During Checkout' Current behavior before PR: The 'Extra Step During checkout' setting is not synchronized when turning on and off from website editor or from website settings. This actually leads sometimes that you might turn it on from website settings and it won't be visible in the checkout process. This is happening because in the 'res.config.settings' we are dealing with 'ir.ui.view' that is not linked to any website but in the website editor we are dealing with 'ir.ui.view' that is linked to the website you are editing. https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/res_config_settings.py#L68 https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/website.py#L588 Desired behavior after PR is merged: When turning on/off the setting from the website settings now we are dealing with the 'ir.ui.view' that is linked to a website. So the setting is now website dependant. opw-3992571 closes #175929 X-original-commit: 533325a Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce: - Enable Multi-Step Routes and Batch Transfers in the settings - Inventory > Configuration > Warehouse Management > Operation Types - Click on internal transfer: Enable Auomatic batches group by dest - Create a internal transfer with two moves: 1 x screw and 1 x bolt - Mark the transfer as Todo, duplicate it and `mark as Todo` > the two transfers should be added to a batch - In the barcode app, batch transfers, go on your batch - Add a single screw and validate > A pop up appears to tell you that the rest will be backordered - Validate Bug: Instead of being redirected to the barcode app, you are left on the old version of the batch. If you go back the barcode app you will see that your old batch is actually empty (0 lines) and its state is "in progress" instead of being done. If you click on the the empty batch you get a traceback since its picking_type is nowhere to be found by owl Cause of the issue: When you added your screw via the barcode app, you marked the move of the picking as picked. When you validated the batch, you are going to mark this move as done and to back order its picking since only part of it was completed. However, since one of its move is 'done' and the other one is 'assigned', its state will not be done and the picking to backorder will be removed from the original batch y these lines: https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144 It would make sense if the the other pickings were to stay in the batch, which is what the "any" part of the if condition is trying to check. However the other picking of the batch is going to be removed later by these lines (since none of its move are picked so that it is considered to be empty): https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking_batch.py#L233-L234 https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L120-L121 This is the cause of all the issues since the old batch is now emptied from all of its picking so that its state will stay in progress and its picking_type_id can't be found from its pickings. Expected behavior: The part of the picking that was marked as done should have stayed in the old batch. Fix: The any part of this if condition should take into account the pickings that are going to be detached from the batch. https://github.com/odoo/odoo/blob/686e0f40f28b81ec99ad41f784a06d0ff231b01c/addons/stock_picking_batch/models/stock_picking.py#L140-L144 opw-4088846 closes #176121 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr