In this commit, current date is added in control panel breadcrums for calendar
week and calendar month views and this only for mobile screens.
If a week straddles two months then the two months are included in the wording
but in shortcuts (Aug-Sep 2023). In all other cases, the entire month and year
are included in the label (August 2023).
Task-3439201
closesodoo/odoo#133633
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
After the introduction of bootstrap, the floorplan edition style
changed. In this PR we want to make the floorplan edition look like
it was in saas-16.4.
closesodoo/odoo#133592
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Before this commit:
carry over field was two times one in radio and another in dropdown
After this commit:
dropdown carry over field is deleted from view
task-3481879
closesodoo/odoo#133327
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When a product is purchased and received, valuation layers are created.
if we created a bill for the PO and change the product price, when the
account move is posted, `_apply_price_difference` creates new SVLs to
correct the product value.
Before this commit, the above scenario did not work with subcontracted
products, mainly because the valuation layer is linked to the finished
product move of the MO and not the incoming move of the PO.
This is fixed in `_get_valued_in_moves` where if the move is_subcontract
the orig move is the one linked to the valuation layer.
Now that we have the valuation layer, another issue arises, in the aml
`_generate_price_difference_vals` when the difference is calculated.
the `unit_valuation_difference` is not properly calculated because the
value in the layer includes the components value, so its incorrect to compare
it to the AML price, so we use `_get_layer_price_unit` to get the layer_price_unit
relevant to the AML, which in this case is the price of subcontracting (price on the PO)
Also for automated inventory valuation, when the inventory correction entry is
created it must credit the stock input account since the value of the
subcontracted product is corrected.
closesodoo/odoo#131565
Taskid: 3449931
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When the customer tries to move the video to the first position of the product
image. at that time, the error would be generated.
step to reproduce:
-Install the website_sale
-open Invoicing > vendors > Products > open any Product
-open sales Notepage
-click on add a Media
-past any video url > save it
-click on Go To website from the state button
-click on Edit button > again double click on the image
-then click on a right side position of re-order
error- Key Error:'video_url'
After applying our commit, if the customer got a validation error when
the customer attempted to swap the video into the product images at
the first position. There is a controller named
`/shop/product/resequence-image` which called, when the customer
changes the position of the video.
https://github.com/odoo/odoo/blob/3ce90ddf33f59a80de34cbafd05679d0817d0076/addons/website_sale/controllers/main.py#L582-L587
The `image res_model` will then receive the `product.image` model when a
customer moves a video from the third to the second position, and that model
locates the field known as `video_url`. However, when a customer moves a
video from the second to the first position, `image res_model` will then
receive the `product.product` model, and that model finds the same field but
does not have that field in it.
sentry-4393257638
closesodoo/odoo#133878
X-original-commit: 8a6a5a10befb98bfe21e5beaf60c9a303304486a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Versions:
---------
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- saas-16.4
Steps to reproduce:
-------------------
1. install the purchase and account_accountant modules
2. create a purchase order using a non-default currency;
3. create bill;
4. switch to a journal without set currency.
Issue:
------
Currency of bill automatically changes from the one used
by the order to the company default.
Cause:
------
The `account.move` model only looks at bank statements, journal,
and the company default when computing currency, ignoring any
value that might already be present in the invoice:
```
def _compute_currency_id(self):
for invoice in self:
currency = (
invoice.statement_line_id.foreign_currency_id
or invoice.journal_id.currency_id
or invoice.journal_id.company_id.currency_id
)
invoice.currency_id = currency
```
Solution:
---------
Try to retrieve currency from `invoice.currency_id` before
falling back on the company default.
opw-3434518
closesodoo/odoo#133867
X-original-commit: 114f328575000fd31f117c46381441d7ec0bca05
Signed-off-by: Levi Siuzdak (sile) <sile@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.
Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea4c) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.
Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).
Closes#127846closesodoo/odoo#133859
X-original-commit: 4dbc3b00e587f3d64cfd964a685f2bddd1b499ad
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Enable different shipment methods (eg. Fedex US, USPS, DHLS US).
- Enable the 'Wire transfer' payment provider.
- Go to website, choose a storable product and checkout.
- On the last step of checkout, just click on 'Pay'
Issue:
The delivery method and cost is not the that was initially selected on the checkout page.
Reason:
On the start of the ``websiteSaleDelivery`` widget, we try to initialize the shipping cost of
every shipping methods in the list. But the we make a call on ``/shop/update_carrier`` which not
only gives the shipping cost but also change the delivery method of the order. As the loop is async,
the last random carrier to be computed is the one on the sale order when validating. So if we don't click on
the shipping method we want(to update the carrier) it will that last one which will be used.
Solution:
Use the ``/shop/carrier_rate_shipment`` which only returns a result with the cost without touching the
sale order.
opw-3457396
closesodoo/odoo#133846
X-original-commit: 7e2682b903b7908f0e86f66603e34d0b6fe90e52
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
Before this commit, message edition was available when
pressing the arrow up key. This was a mistake since the
message edition route is not available yet for livechat
visitors. This PR fixes this issue.
closesodoo/odoo#133815
X-original-commit: ab7e70e809b3c7fa5044139582bd09a9e94ee377
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
before this commit, In product page specification tags label is not vertially
align to it's value.
In this commit, fixes the alignment issue by centering the label in website
product page.
task-3451377
closesodoo/odoo#133812
X-original-commit: 8be036367c9a78fb93ae8e48a3d13f110a3a09bd
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
a translation issue that only appears on Odoo.sh. On the
other systems and locally, everything works fine.
The problem seems to have its source in odoo.tools.translate
Here is the problem:
On the basis of staging (brutus), in the LIMS application, menu Report / Test reports:
* take report 000022. The client is in French.
* click on the button "preview PDF"
-> the values of the "state" column are not translated.
Locally (same sources, same database), these values are well translated.
This field is defined as follows:
```py
state = fields.Selection('get_state_value', string='State', copy=True, required=True)
def get_state_value(self):
return [
('init', _('Init')), ('conform', _('Conform')), ('not_conform', _('Not Conform')),
('unconclusive', _('Inconclusive'))
]
```
Here's what happens:
When the '_' method is called, another method ("_get_translation") is called.
It tries to determine which module is used. To do so, it is based
on the path (path) and use the "get_resource_from_path" method:
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L474
This method iterates over all defined addon paths. On Odoo.sh, these are:
```
'/home/odoo/src/odoo/odoo/addons',
'/home/odoo/.local/share/Odoo/addons/16.0',
'/home/odoo/src/odoo/addons',
'/home/odoo/data/addons/16.0',
'/home/odoo/src/user',
'/home/odoo/src/user/Logicasoft/base',
'/home/odoo/src/user/Logicasoft/lims',
'/home/odoo/src/user/Logicasoft/mail',
'/home/odoo/src/user/Logicasoft/web',
'/home/odoo/src/enterprise',
'/home/odoo/src/themes',
```
The path variable is equivalent to "/home/odoo/src/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
As soon as the 'path' variable has a common prefix with one of the paths in the
mentioned list, Odoo considers that it has succeeded in finding the path that contains the module in question.
Locally, the path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
And the found path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/"
But on Odoo.sh, the path found is: "/home/odoo/src/user/"
because Odoo finds that there is a common prefix. This is the case, but another path also has a common prefix: "/home/odoo/src/user/Logicasoft/lims" and this one is the correct one.
The result is that the module found is not the correct one:
- module='Logicasoft' on Odoo.sh
- module = 'lims_base' on other systems
Since the module is not the correct one on odoo.sh, the translation is not found.
Solution
========
when we have a module present in parent and child path we want to take the child path,
which is the long one, so we sort the list of paths by length which ensures that children
have priority on parents.
opw-3374757
closesodoo/odoo#133862
X-original-commit: 6ef7e188963b65a31589f8f15107ce698cd3dc74
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Steps to reproduce:
-------------------
- create a cart;
- select an other shipping method than the default;
- apply a coupon code;
Issue:
------
The shipping method is modified.
Cause:
------
In the `_check_carrier_quotation`, we try to update
the carrier id with the partner's preferred carrier.
This behavior can be changed using `force_carrier_id`
and `keep_carrier` params.
When we call this route with a `GET` method, these parameters don't exist.
We will update the `carrier_id` according to:
```py
if not force_carrier_id and self.partner_shipping_id.property_delivery_carrier_id and not keep_carrier:
force_carrier_id = self.partner_shipping_id.property_delivery_carrier_id.id
```
This will have the effect of modifying the `carrier_id`
that we have previously modified.
Solution:
---------
Perform this logic only during a `POST` method.
When we call the route with a `GET` method,
we only want the information, without modifying it.
opw-3457243
closesodoo/odoo#133819
X-original-commit: 94ed203404b3b2121122697f5ebfe09cc21e3630
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
During 'l10n_eg_eta' server connection when the
'request_response' is not in proper json format then
while decoding 'request_response', the user will face the
'JSONDecodeError Expecting value: line 1 column 1 (char 0)'.
We are keeping the 'blocking_level' as 'error' because the
occurence of this error will prevent the succession of ongoing
operation.
Applying the changes will resolve the issue.
sentry-4220714667
closesodoo/odoo#133866
X-original-commit: 2cf76a9815af31a8d1eb8337d8807506569c9e43
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
Steps to reproduce:
-------------------
- create and pay with ewallet a cart with a ticket;
- create and pay with ewallet an other cart with a ticket;
Remark:
Don't clear element in the session like 'sale_order_id', etc.
For example, by moving the mouse over the cart or by making a payment process.
Issue:
------
An error is raised with the message:
"It is forbidden to modify a sales order which is not in draft status.".
Cause:
------
We apply an update to the cart on a sale order which is not in draft.
Solution:
---------
Make sure we are working on a sale order in draft
when applying a registration post.
If not, clear session elements.
opw-3465937
closesodoo/odoo#133825
X-original-commit: 22f652ddb85de065208371aa21fed8c674687063
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Improves on #119813 (595aa24843): the
commit splits the ORM cache into several, and adds a log entry when
invalidating caches (both individual and all).
To keep tests isolated and coherent (and also make performance tests
usable), the test framework has to clear all caches between tests to
ensure they don't affect one another. This adds a line of log
to *every* test, pointing into the guts of the test framework.
Since the clearing is willful, unconditional, and not bypassable, the
log line has essentially no value, it just adds tremendous amounts of
noise to the logs.
Fix by muting the registry logger specifically when clearing the cache
in the test suite (there is currently no dedicated cache logger, if
there ever is mute that instead).
closesodoo/odoo#133811
X-original-commit: 52371bac7d4fadbeab139e4cd044cdc6b1005299
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When we changed the display of the form in v16, we forgot to adapt the
python framework default form view layout (used when the form view of
the model isn't defined). This provided a weird layout in these case on
Odoo 16.+.
To fix this bad behavior, we adapt the algorithm used to build the
default view form.
Steps to reproduce:
Create a model without a form view and edit it (like we do when you
follow the rd training).
closesodoo/odoo#133837
X-original-commit: 93e95274939abce5f3facde6c8cd29b922d15251
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
The inherited field of a custom field cannot be deleted
Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts and open any contact
3. Toggle Studio
4. Add a field of any type in the view, remove it and close Studio
5. Go to Settings > Technical > Database Structure > Fields and search
for `x_studio`
Solution:
Mark the inherited field as manual if its parent field is manual and
allow the deletion of inherited custom field if we also delete its
dependency
Problem:
The inherited field was not marked as custom so it was impossible to
delete it
opw-3093581
closesodoo/odoo#133820
X-original-commit: 526f3407c7c5b4cd014a4d091ca01b9617e6e938
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps to reproduce the bug.
- In website edit mode, add a form snippet to a page.
- Add a "number" field within this form.
- Modify the label of this field in the options and name it "Field 1".
- Add a "text" field to the form.
- In the options of the "Text" field, select "Visible only if" for the
"visibility" option.
- Then, choose "Field 1" and "Is greater than" in the two dropdowns that
follow.
- Enter "10" in the input below.
- Save the page.
- Enter "2" in the "Field 1" input.
- Bug: The text field is displayed, even though it should only be
visible if "Field 1" is greater than 10.
This bug exists since the "conditionally show form fields" feature was
added to Website (in this commit [1]). The bug happened because we were
comparing strings instead of numbers.
[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce
opw-3449900
closesodoo/odoo#133838
X-original-commit: e4d64c9f4470874ca853bd871064bb8374c8b5cc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Create [TAX] as 21% included in price tax
Create a Sale Order with the lines:
- Product A, qty 1, unit price 900$, tax [TAX]
- Product B, qty 2, unit price 90$, tax [TAX]
- Product C, qty 4, unit price 49$, tax [TAX]
Confirm order
Create a downpayment with fixed amount of 550$
Go to the downpayment invoice
Issue 1: price total on the downpayment line is 549.99
when we make the downpayment we convert the fixed amount in percentage
and then compute the downpayment amounts.
This result in some rounding issues that are only partially corrected
The price total on the product line was not corrected
Confirm the downpayment invoice
Go back to SO
Hit create invoice again
Issue 2: 'Already invoiced' amount will be 549.99
When the make invoice wizard is created we operate on virtual records of
SO and invoices.
In particular, when the amount_to_invoice is recomputed, instead of using
the value saved in DB the system recompute the total of the downpayment
invoice from the lines, introducing a rounding error which is
manually corrected only when creating the downpayment
opw-3466409
closesodoo/odoo#133836
X-original-commit: e1c85283736deac7dd523f115e6ba9033b656ade
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
This was bothersome to export/import the registry and manually add
the model, by providing the model name and the model class.
```js
// before
modelRegistry.add(Model.name, Model);
// after
Model.register();
```
closesodoo/odoo#133658
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In preparation to improvements in models.
Some implementation techniques will want to `new Model()`
without any side-effects.
Part-of: odoo/odoo#133658
__Current behavior before commit:__
`_get_own_attribute_exclusions()` returns the product template attribute
value (ptav) even when `ptav_active` is **false**. This makes the
frontend crash when we add a product that has such ptav to a sale
order.
__Description of the fix:__
Prevent ptavs with `ptav_active = false` to be in the result of
`_get_own_attribute_exclusions()`.
__To reproduce:__
1. Create new Product template
1. Add 2 attributes with at least 2 values each
1. Click on the Configure button next to the first attribute line
1. Click on the first attribute value
1. Add an exclusion line for the newly created product template and one
of the value from the other attribute
1. Put `ptav_active` of the ptav to `false` (not sure how to do it
except from the ORM but one customer managed to do it)
1. Try to add the product to a sale order line
1. `TypeError: Cannot set properties of undefined (setting 'excluded')`
opw-3466451
closesodoo/odoo#133808
X-original-commit: cf58369310f13377cd70794bf777f4e9198f643a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In Saudi Arabia, the InvoiceLine/ID should not be greater than 6 digits.
Using the move.line_id, this limit can be exceeded.
Simply count the invoice line ids starting from 1 instead.
In master, add a parameter `line_id` to `_get_invoice_line_vals`.
closesodoo/odoo#133794
X-original-commit: 3ce90ddf33f59a80de34cbafd05679d0817d0076
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
When the JS client cannot retrieve the online payment data from the server for an order that has no online payment line, and that has been previously saved on the server (and has its server_id defined in JS), an error is thrown if the user confirms that there is no online payment for this order.
This commit fixes this issue.
closesodoo/odoo#133787
Task-id: 3484441
X-original-commit: 129bc21b609d6d3310d038e631f82bae56c14e74
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Crop widget is implemented as div block that is supposed to be displayed on top
of other elements. However, it's not the case for dialogs, because they want to
be on top as well (z-index of dialog is 1050 bootstrap [1])
STEPS:
* Go to Sales Order
* SO
* Schedule an activity
* Use '/' command
* select image
* click image
* crop image
BEFORE: image crop toolbar is hidden behind 'Schedule activity' Pop-up
Fix it by increasing z-index for the crop widget
[1]: https://github.com/odoo/odoo/blob/9102df15cce455205a19fb7b9a0c36186cc51e3a/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L5524
opw-3391583
closesodoo/odoo#133781
X-original-commit: 36c9b2b7916fbbdcfc912d652695699e50043edb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
This commit improves the mail `onChange` method by adding
the support for multiple keys. This will make the code shorter
and easier to read.
closesodoo/odoo#133778
Signed-off-by: Didier Debondt (did) <did@odoo.com>
* mondialrelay, stock
Overrides of `shop_payment_transaction` were retrieving the sale order
from a different way from the parent method, which should be prevented.
The logic is moved to a method on the sale order instead of the
controllers.
Part-of: odoo/odoo#117379
1. In mrp settings, check workorder by default
2. Remove stock for Table leg in demo data
closesodoo/odoo#133758
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
The following commit https://github.com/odoo/odoo/commit/0015662d166f5e07bcbd6c5e9e14f8837ffa58a3 was incorrectly done because the records are already limited to a 100 in the search query. We therefore remove redundant loop.
We also moved up all possible UserError in the _post() method before the soft computation such that if any UserError is raised (with the autopost cron for example), the soft computation will not be executed.
task-3482939
closesodoo/odoo#133756
X-original-commit: d87dc624c33c8edd0eafc130b02a95fd91e58094
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Versions:
---------
- saas-16.3
- saas-16.4
Steps to reproduce:
-------------------
1. go to a list view which starts with a numerical value;
- e.g. with developer mode enabled:
Settings > Technical > Scheduled Actions
2. group by any element.
Issue:
------
The width of the `o_group_name` elements is around 40px, not enough for
the names to be displayed.
Cause:
------
`list_renderer.js` calculates the `colspan` of `o_group_name` elements
based on the first occurence of a value that can be aggregated, i.e.
any numerical value. If this happens to be the first column, the
`colspan` is set to 1, leading to their width being the same as the
first column containing checkboxes. An update in saas-16.3 had forcibly
set these to 40px by adding the `!important` rule:
```scss
.o_list_record_selector {
width: 40px !important; // Force to 40px regardless by the font-size
}
```
Solution:
---------
After consulting the person who introduced the rule, we agreed that
removing it would be the easiest fix, unlikely to introduce any new issues.
opw-3459598
closesodoo/odoo#133521
X-original-commit: c89c94192685c989b65eb6b483b4120aa312252c
Signed-off-by: Levi Siuzdak (sile) <sile@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
luxon and moment are both used in the solution, but these two libraries
facilitate the manipulation of dates. It was decided to replace all uses of
moment with luxon so we can then remove moment.js from the code and lighten
the assets.
task-3391739
closesodoo/odoo#133144
Related: odoo/enterprise#46447
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Since 605943b5ea, the modification of a POS config while a session is open with that config is prevented with the error message "Unable to modify this PoS Configuraton because you can't modify Payment Methods while a session is open".
Steps to reproduce:
- Open a POS session
- Open the settings page of the POS config of the opened session
- For example, enable "Set Maximum Difference", then click on the "Save" button.
The error message "Unable to modify this PoS Configuraton because you can't modify Payment Methods while a session is open" is shown.
The fix consists in replacing the "invisible" property of the payment methods field by "readonly", as it was before the 605943b5ea commit.
closesodoo/odoo#133711
Task-id: 3487621
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The condition to create is wrongly evaluated and does not take into account
the country code and the picking type code. This commit fixes this by
reordering the conditions.
closesodoo/odoo#133637
X-original-commit: d57bffae3b13a58580dc82db878ce8809878ff04
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Since [1], many tickets were created because of a crash preventing any
action in edit mode. This actually occurred in most databases were
snippets were saved previously (which probably is most old-enough ones).
Steps to reproduce on a fresh DB:
1. Enter edit mode
2. Drag and drop a snippet which contains an image, like "Text - Image"
3. Click on the image once (a tooltip asks to double click)
4. Save the snippet (not the page, floppy disk icon in the right panel)
=> You cannot do anything in edit mode ever again.
This is actually a combination of 2 bugs:
A. On step (3) in the steps above, the image receives the
"aria-describedby" attribute related to the tooltip... and it never
disappears (if the page is saved, the attribute is saved with it).
When saving the snippets we should probably clean such problematic
attributes to be sure anyway too.
B. Because of [1], the snippets saved by the customers and which
contain the problematic "aria-describedby" attribute are now the
source of a crash: we try to hide the related tooltips... even
though there is none, which causes a crash.
This commit focuses on fixing (B). (A) will need to be fixed later,
probably in an earlier version anyway.
[1]: https://github.com/odoo/odoo/commit/095721a9cace476c3eae445c7abd8f8b458aea36
opw-3475051
opw-3481944
opw-3482170
opw-3483220
opw-3483829
opw-3483837
opw-3484069
opw-3484647
opw-3484950
opw-3485343
opw-3485612
opw-3485623
opw-3485704
opw-3486096
opw-3486425
... and many more
closesodoo/odoo#133707
X-original-commit: 824be46dded7efacf2a351b78e723aa9e205b60d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This function became useless at some point, after the views and
actions have been all converted to owl.
closesodoo/odoo#133699
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Steps to reproduce:
- Create a product in KIT
- The product and components must be AVCO rated.
- Sell product, confirm delivery and post the invoice
Bug:
the journal entries are not reconciled.
the lines are gouped by product but in this case the products don't match
on the stock side it's the components and on the invoice it's the kit
Fix:
match components stock moves of kits to the kit product
opw-3208169
closesodoo/odoo#133683
X-original-commit: 376e3cd31427a6715dd86af91755baca733d94ef
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When installing point_of_sale and loyalty modules, then creating an eWallet program, the user gets an error that prevents him from creating the program.
Steps to reproduce:
- Install point_of_sale and loyalty
- Open the settings of the default POS Shop
- Click on the "Gift cards & eWallet" link (under "Promotions, Coupons, Gift Card & Loyalty Program" setting)
- Click on "New" to create a new program
- Change "Program Type" to "eWallet"
- Set a name for the program, then click on the Save button (cloud button)
The error "Split per unit is not allowed for Loyalty and eWallet programs." is raised.
This error is due to the reward_point_split hidden and not modifiable by user field of loyalty.rule that is not correctly set.
The fix consists in correctly setting reward_point_split for new eWallet programs.
closesodoo/odoo#132631
Task-id: 3474750
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Pierre Pulinckx (pipu)