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.
Purpose of this commit is to test existing behavior of followers subscription
as well as adding some query count tests about message_subscribe method. As
followers subscription technical implementation may change in a near future
in order to be optimized it is a good idea to have current behavior and query
count validated.
This commit adds
* test for followers update using message_subscribe API. Tests are added
with forced and unforced subtypes to ensure behavior will not change or
will be changed while knowing it;
* performance test about message_subscribe, about adding new followers,
and subscribing already-existing followers in force mode or not;
Query count performance test shows that message_subscribe could probably
be improved. It does several things that require queries (check of access
rights, check for existing subscriptions, ensure customers have no access
to internal subtypes, ...). However we feel it could be improved in order
to speed-up the subscription of followers.
This is linked to task 49265; it is only the first steps of it.
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).
Make sure that all propositions/created data will be linked to the company of the processed statement line.
+ adapted QUnit tests
Closes PR #23070.
Co-authored-by: Miquel Raïch (Eficent) <miquel.raich@eficent.com>
When updating the cost on products with realtime valuation, the journal
entries do not have their product_id set, whcih make it difficult to
track/filter on them.
Closes#18492Closes#22281
Task 60955
- 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
No purpose, no explanation, incorrect commit message, no review from
technical and functional team, no task, separate features mixed in same
commit, incorrect code.
As /dev/null and its related POs manage timesheet applicationplease ask us
for guidance and review before committing that kind of commits. Many thanks.
Arnold Moyaux