property_stock_account_input_categ_id,
property_stock_account_output_categ_id,
property_stock_valuation_account_id ir.property default values on
product.category could be duplicated eg. if l10n_generic_coa was
installed before stock_account.
This did not happen in enterprise but happened in enterprise breaking
the test added in odoo/odoo@6bcf9ac2e.
This is a manual forwardport of rev. b466b3bc.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
controller in the closest instance of a ViewManager-like widget
in the SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes#23293
Following the previous fixes in stock where we had to handle non-valued
move lines inside a valued move, the valuation of the dropshipping was
bypassed because a dropshipping move is not an in move, nor an out move.
We now value the dropshipping move always positively. We adapt the
sale_stock code that generate the anglo saxon entry to use the abs value
of the move, not -1 * value. It was done this way because all out moves
are negative.
We add 8 tests to test all the valuation cases: continental or anglo
saxon, ordered or delivered, fifo or standard.
opw-1817363
fixes#23214
Use case to reproduce:
- Create a sale order with a stockable product.
- Confirm the sale order.
- Validate the pick.
- Validate the pack.
- Cancel the OUT.
- Run the stock scheduler.
-> Picking are created from pick and ship.
The scheduler should not try to create missing pickings
for broken move's chain. Since v11, it's not possible to create
a partial mto chain that means if a chain is broken it's due to
a manual action from a user and thus we won't automatically
repair what he cancelled on purpose. That's why we won't create
a new move out in this case.
It also don't make sense to recreate a new mto chain from a
cancelled picking. Thus we had a condition in domain in order to
only take moves that make sense.
Based on preliminary work from Florent de Labarre <florent.mirieu@gmail.com>
Closes#23441#23458
OPW-1820226
Since we are able to lazy load Qweb templates, there was
an issue to generate Awesome Timesheet iOS native app with
Cordova properly. It seems that under Cordova, iOS always
returns 0 for the status on a xml http request object.
The problem is that native applications are requesting
a local file from something that isn't a webserver.
The local file is delivered with no http headers that means no
"200 OK" header and no "404 Not Found" errors.
In this case, the request is still be completing as intended even
if the status code used by browsers is 0.
For more info, see:
https://developer.mozilla.org/fr/docs/Web/API/XMLHttpRequesthttps://bugzilla.mozilla.org/show_bug.cgi?id=331610
There is several issue happening when changing quantity:
1) if website_sale_stock is installed, the displayed price is not
updated when changing quantities.
2) if the "Add to Cart" price is not updated, it erroneously displays
the price multiplied by the quantity.
3) when prices are updated, it only update attribute_value_ids.
4) when variant are displayed as list view, visually the last list item
is selected instead of the first, also changing quantity doesn't
update price as it should be given pricelist.
The first issue is caused by invalid JSON in data-attribute_value_ids
attribute. The code modify the `.data('attribute_value_ids')` thinking
it will be permanent. But if the value was invalid JSON we always parse
it on the fly inside a temporary object so the object is never changed.
The second issue is because originally, the "data-attribute_value_ids"
inside "Add to Cart" was set wrongly (when rendering the view) because
get_attribute_value_ids got the website_price multiplied by quantity.
The third issue was even with website_sale_stock is not installed
`.data('attribute_value_ids')` was only updated for one of the possible
multiple ones in the page.
With this change, we had json.dumps to ensure data-attribute_value_ids
is good JSON, and we correct errors so it is fixed for instance only
updating sources without updating website_sale and website_sale_options
modules.
note: when views are updated, this also solves a bigger issue when
python2 is used (because attribute_value_ids contained u'text' strings.
another version will be merged in master with #23467
opw-1816479
closes#23392
This commit adds 3 indexes targeting project_task which are not only
useful in regular RW use cases, but help tremendously when deleting
tasks.
In a production scenario, deleting a single task record went from 685ms
to 5ms.
Equivalent queries for an existing database:
CREATE INDEX account_analytic_line_task_id_index ON account_analytic_line(task_id);
CREATE INDEX project_task_parent_id_index ON project_task(parent_id);
CREATE INDEX sale_order_line_task_id_index ON sale_order_line(task_id);
- Create an activity for a crm lead
- Set the lead as lost
The activity still appears in the list.
A proper fix would be to have an `active` field on `mail.activity`. In
the meantime, simply delete activites when archiving.
opw-1817703
Uninstalling account gets rid of this view and since sale depends on account, it is uninstalled as well, which triggers the uninstall_hook.
Closes#23446
The duplication of a task crashes at the following:
`content = myPad.getHtml(path).get('html', '')`
The copy mechanism is quite cumbersome:
- In `copy` method, generate an URL of a pad which doesn't exist since
`object_id` is still undefined.
- The `create` method somehow attempts to fill in the previously created
pad thanks to `_set_pad_value`.
The logic is made simpler. The pad URL field is set as `copy=False`,
therefore the create mechanism will take care of handling the pad
creation and its synchronization.
opw-1818757
- On 'website_payment/pay' if the reference contains a '/' the payment will never succeed.
It is due to the fact that in the template "payment.pay" were setting "prepare_tx_url" and "form_action" using this reference.
But having a '/' in the reference breaks the URL to call to create a transaction.
So when creating a transaction (or even paying in S2S) the payment never succeed and returns a HTTP 404 error.
When creating an invoice from POS order having a negative amount (due to return products), a credit note must be
generated instead of a customer invoice.
-github issue 23167
Use case to reproduce:
- Create a Product MTO that should be buy
- Create a SO with this product and confirm it
- Confirm the RFQ
- Increase the ordered quantity on the SO
- Confirm the new RFQ
- Receive product from the 2 PO
-> Unable to reserve the quantity on the destination moves
It happens because the link between the reception move from the second PO and the delivery move is missing.
Update the quantity on the SO will create a new move with the missing quantity that will generate the new RFQ
then this move is merged in the main move. However the reception move is only created when the RFQ is confirm
and the move_dest_ids is stored on the purchase order line during this time.
Thus merge moves will unlink the new move with its reference on the purchase order line and the link is lost.
This commit do not merge move that have different RFQ/PO in order to avoid losing MTO information.
Use case to reproduce
- Create a planned transfer with 2 move lines (details operations)
- Leave the form view in order to lose the context then go back on the picking form view
- Delete a move line and save
The picking state change from draft to ready
It happens because planned_transfer is not in the context
then the autoconfirm is triggered.
This commit only autoconfirm if there's at least an intial demand in one of the move.
Closes#22834
The invoice printout would display taxes as floats instead of monetary
widgets, and as such display numbers such as 3.0500000000000003
instead of 3.05.
opw-1817230
When printing the delivery slip of a stock.pick, the message:
"All items couldn't be shipped, the remaining ones will be shipped as soon as they become available."
must be displayed only if there is still a backorder to process for this picking.
opw:1817573
- As admin, create an opportunity
- Under the tab Assigned partner set the portal user
- As portal user go to My account > My opportunities > Edit opportunity
- Change something
Confirm button doesn't work. In fact, an access error is raised silently
in the JS console.
The issue is raised in `update_lead_portal`, at `lead.activity_ids...`.
This is because the field `activity_ids` has
`groups="base.group_user"`.
opw-1817935
opw-1818629
In some cases, the footer in a form view dialog could be duplicated.
The reason was that the form view was rerendered completely, footer
included, by the renderer, out of the formcontroller control (it is the
formcontroller's job to move the footer buttons to the footer).
A possible fix is to work on the form renderer to make it aware that the footer
buttons are expected to be only rendered once, but it has the disadvantage to
be a fix specific to this issue, and any other form view behaviour with some
side effects may have the same issue.
This commit tries to prevent the form view from rerendering itself
completely in those cases. This also has the disadvantage of possibly
not being a complete fix, if some edge cases are missed. However, I
have the feeling that we still want to avoid rerendering the full view
if possible.
Before this rev., in week and month modes, when navigating through
weeks or months, the weekday/monthday of today was still
highlighted in other weeks and months than the current ones.
This rev. ensures to only highlight today in the main calendar
view (this doesn't impact the mini calendar).
- Create 2 SO for the same customer
- Send them
- As the customer, click on 'Accept and sign online' for both quotes.
The message 'Quotation viewed by customer' is only posted on the first
quote.
opw-1815082
This filter groups tasks based on a message_last_post field that is not
updated anymore since quite a long time. It has been implemented for some
internal custom use and not supported since.
As this field has no use and lead to wrong result it has to be removed. Its
purpose can still be achieved in custom using server actions activating the
message_last_post context key and adding the field in custom views.
Done after feedback from internal migration.
Customer portal has a widget to display a chatter-like communication
history. However only user comments are displayed. It seems interesting
for documents like tasks that also include tickets and support to
display incoming emails. Indeed most customers will use their email
to discuss with the responsible.
Done after feedback from internal migration.
As tasks are now used for a lot of use cases including tickets and support
it seems fair to include the task ID as reference in the portal view
for customers. It eases the communication process as people can directly
give the reference (aka ID).
This commit therefore adds a column in portal list view with the task ID
as reference. It also adds it in the portal form view, just after the
task name.
Done after feedback from internal migration.
The `location` variable was used before it was set in the event reminder in
the email template.
Introduced at f8c6c76
When rendered, the links to add the event to a Google/Yahoo/Outlook calendar
were not set the event to the correct location
opw-1818699
Steps to reproduce the bug:
- Set your company currency to USD
- Set multicurrency on your user
- Create a delivery method with a fixed price to 50$
- Create a SO with a pricelist in EUR
- Set the delivery method and check the price
Bug: It displayed 50€ while this amount should be converted
opw:1817666
Normally Vantiv should return an 'Invalid Purchase Amount' error. But
sometimes they will process the transaction anyway as if it had a
positive amount. We're sure the amount we send is negative. After
communicating with Vantiv it's unclear why that sometimes
happens. They recommend to explicitly prevent negative charges and to
not rely on them throwing an error.
Since we have to display an error message to the user anyway we take
the opportunity to explain the correct full flow to handle refunds.
opw-805302
Before this commit, the theme tutorial was still creating pages using
`<template page="true"/>`. This was not just outdated, it was also
making the whole created theme fail to load.
Closes https://github.com/odoo/odoo/issues/21243
- Assuming a sale order invoiced in a different company.
The sale order line's invoice_lines fields will be empty, which causes issues with sale_timesheet.
The code assumes that if the sale order line invoice status is set to 'invoice', it has at least one invoice line, which is not true.
This patch address a fix for this issue.
Nicolas Lempereur