- 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.
The curent behaviour of the 'phone validation' module will only format a
number to the national conventions IF possible and will never block a
user.
The term of 'Validation' isn't suited.
When something like this is in a html content:
```
<a href="hello">
<div>
<b>this</b>
<a href="world">!</a>
</div>
</a>
```
browsers may correct it to:
```
<a href="hello"> </a>
<div>
<a href="hello">
<b>this</b>
</a>
<a href="world">!</a>
</div>
</a>
```
which breaks our CSS.
This change transforms the inner tag in a button tag.
opw-1817668
closes#23373
Since procurement order removal. We lost the behavior
to access PO directly from the orderpoint.
In 10.0 the puchase button redirect to the procurement order
and the purchases were accessible from the procurement order.
We do not have the procurement order anymore thus the button
return to a list view with all RFQ and PO.
Fixes#23096
- When using perpetual inventory valuation, the accounts used for scrap, manufacturing,
and inventory adjustment operations are set on the corresponding locations .
- In a multicompany environment, you will have a separate chart of accounts for each company.
- Account fields on locations are not property fields.
- Therefore, in order to separate the accounting of manufacturing, scrap, and inventory
adjustment operations, you must use a location for each operation for each company.
- Set up one location for each company for scrap, production, and adjustment
locations, setting the company field on each.
Bug:
- When attempting to create a MO, inventory adjustment, or scrap order while signed
in to the second company, you will receive a permissions error on stock.location.
Fix:
- Now the right location is taken according to the company of the user.
opw:1817339
When copying a company, the default accounts/journals are copyied too.
The chart_template_id and the opening move are also copyied.
To conclude: copying a company is a very bad idea that leads to a lot of access rights issues.
-githug issue: 21213
The suggested analytic account must search based on the commercial_partner_id instead of
the partner_id field.
E.g. create an invoice with 'Agrolait, Thomas Passot', the analytic account 'Agrolait' wasn't set by default.
-github issue 21401
The DomainSelectorDialog behaves differently from classical dialogs
in terms of height and overflow: (1) its height can be larger than
the screen height, and (2) its content is never scrollable
(overflow visible).
However, before this rev., the 'height: auto' rule ensuring (1)
didn't apply, so the dialog's height was limited to the screen's
height, and when it had to much content to display, it overflowed.
It didn't work because the code tried to apply the rule too soon,
so the .modal-dialog element was not yet available.
Fixes#23292
- Create a user with Inventory access but no Sales access
- Access a product
An AccessError is raised because the user doesn't have access to
`sale.report`.
We hide the stat button if user has no access to Sales, and moreover we
do not compute the sales count in this case.
opw-1815436
This action is generic to print the account reports (in community).
However, it doesn't make sense to call this method from list view because
the data are added explicitly in the _print_report method (in account.common.report).
-github issue 22349
Olivier Dony