In manual reconciliation (but probably automatic too)
Have 3 lines for one account
2 of them are balanced
the third is of an amount X
Add the three lines to the reconciliation
A write-off proposal of -X should appear
Now, remove the third line by clicking on it
Click on Reconcile
Before this commit, the values sent to the server were wrong, as the write-off
was still included
After this commit, we make sure we don't send lines that are not displayed
Create an account.move, create a line, then add an item to start to add a second aml
The current balance of the move is put in debit (or credit) to help automatically making the second line
Save the move.
Edit the move
Delete a line
Add a new line
Before this commit, the balance was not correctly computed because the default_get did not compute
the balance on deleted lines
The move ended up with wrong unbalanced new lines
After this commit, the balance is computed with deleted lines taken into account
This is a standard BS4 bug: radio buttons's dot is not properly centered
as soon as the html font-size is not a multiple of 4 (and our backend
uses 13px). As a quick fix, I change that to 12px and use a font-size base
of 13/12rem so that the body font-size does not change. Bootstrap will
probably fix this in a future update.
Let's consider the partner P1 with the address A1 and its invoice partner P2
with the address A2.
When creating a transaction in the shop for P1 with billing address = A1:
- if option Payment Flow = Redirection to the acquirer website
=> the billing address of the transaction is A1
- if if option Payment Flow = Payment from Odoo
=> the billing address of the transaction was A2
Now with this patch, the billing address is A1 in each case.
opw:1867188
Purpose
=======
Improve some common usability issues coming from the invoicing followup.
Specification
=============
1. Sale: Rename 'Check/Set Price' buttons for more clarify
relabel "Check price" -> "Get rate"
relabel "Set Price" -> "Add to order"
2. Sale: Change the default invoicing method if there are downpayments
Purpose
-------
Currently the default invoicing method is not very clear.
Specification
-------------
Currently the result is not really correct. We can propose to deduct
the down payment even if there are no down payments on the sales order.
Now the option to deduct down payments will be selected if there
is a downpayment line on the sales order and if there exists at
least one invoice linked to the sales order that is not cancelled.
3. Delivery: Improve the SO invoice status
Purpose
-------
If a SO is only containing lines for which the product is invoiced on
the delivered quantity, the sales order is marked as 'Nothing to Invoice'.
If I add a delivery line, the SO becomes 'To Invoice'. There is not really
a use case in the real life where you will invoice the delivery fees before
invoicing what has been really delivered.
Specification
-------------
If an order:
- contains delivery lines or downpayment lines
- If the product on the other lines are invoiced on the delivered quantity
- Nothing has been delivery or can be invoiced for theses lines
Set the invoice status of the sales order to 'Nothing to invoice' instead
of 'To Invoice'
4. Sale: Unlink the down payment on a SO if the invoice is unlinked
Purpose
-------
When we create a downpayment line of SO and when we delete Invoice of downpayment then so line for downpayment is not deleted.
Specification
-------------
Remove the downpayment line in the SO if the related invoice is deleted
Task ID :33126
Purpose
=======
When we create a downpayment line of SO and when we delete Invoice of downpayment then so line for downpayment is not deleted.
Specification
=============
Remove the downpayment line in the SO if the related invoice is deleted
Task ID :33126
Purpose
=======
If a SO is only containing lines for which the product is invoiced on
the delivered quantity, the sales order is marked as 'Nothing to Invoice'.
If I add a delivery line, the SO becomes 'To Invoice'. There is not really
a use case in the real life where you will invoice the delivery fees before
invoicing what has been really delivered.
Specification
=============
If an order:
- contains delivery lines or downpayment lines
- If the product on the other lines are invoiced on the delivered quantity
- Nothing has been delivery or can be invoiced for theses lines
Set the invoice status of the sales order to 'Nothing to invoice' instead
of 'To Invoice'
Task ID : 33126
Purpose
=======
Currently the default invoicing method is not very clear.
Specification
=============
Currently the result is not really correct. We can propose to deduct
the down payment even if there are no down payments on the sales order.
Now the option to deduct down payments will be selected if there
is a downpayment line on the sales order and if there exists at
least one invoice linked to the sales order that is not cancelled.
Task ID : 33126
Before this commit, negative values in a float field interpreted as time
(i.e. unit_amount on analytic lines) were wrongly formatted
After this commit, not only we correct the hr_timesheet qweb templates
but we also correct the qweb widget to handle the case
OPW 1869986
closes#26024
Modal footers now use flex to vertically center buttons. So our
left-align style overridde had to be adapted. Also, we sometimes
use footer buttons as non-direct children of the modal-footer, which
is not a supported BS4 case, so we had to adapt that too.
In 75d3121c9 the bad rating was change from 0 to 1.
This commit update the javascript feedback part so the behavior is the
one expected.
related to opw-1863312
closes#26043
In the CSS of the ISR report, we had things like:
2 + 3/12in
This was valid in less, but in SCSS there would be no CSS with error:
Error: 2.4/in isn't a valid CSS value.
on line 3350 of stdin
>> width: 2 + 4/10in;
---------------^
These expressions were just used so it is more apparent that the number
is corresponding to the standard template.
We could keep them using:
#{2 + 3/12}in
But this commit change it to directly use float number since with
margin/fonts/padding/... the expressions anyway didn't match that much
the standard template.
Have the Admin in company A
Create a pos.config for company B
Have its default pricelist to be one of company A's
Save
Log in with user B, in company B
Try to make a new pos session
When everything is loaded, the screen stays black, leaving the pos unusable
After this commit, we constrain the pricelists to either be of company B's
or to not have a company set on them
The black screen doesn't happen
OPW 1861757
closes#25996
In the field HTML, click on create hyperlink
as its url, put in http://hell-broke-luce.waits/?param=tom@waits.com
Before this commit, since the url merely contains a @, it was considered as a mailto: link
After this commit, if the url starts with a flavor of http, it is considered
as a standard http link
OPW 1869087
closes#26012
Have an invoice with analytic tags
Create a credit note
Before this commit, the tags on the invoice lines
are not transmitted to the credit note's lines
After this commit, they are
OPW 1866432
closes#26010
In Python 3, SETUP_FINALLY is used if the exception object is bound in
the except block — even if there is no finally block — in order to
unbind and cleanup the exception's binding as part of PEP 3110:
https://www.python.org/dev/peps/pep-3110/#semantic-changes
This allows both using exception objects in Python 3 and using
finally blocks in both version.
opw 1824211
Have ~50 records in a column,
Mark 49 of them as blocked (kanban_state field)
Mark 1 or 2 as done
Before this commit, the bar that showed the proportions of blocked objects was invisible
This was because the min-width of a bar was 10px, without max-width
Leaving the red bar to 95% or something, the green bar to 10px
All of this overflowing 100%
After this commit, we compute max-width and min-width to be able to fit everything
within the progress bar
OPW 1867464
closes#25962
The functionality to add an event on outlook through a link seems gone on Microsoft's part
Or doesn't work as it did before
To avoid confusion, we remove the links
OPW 1865938
closes#25968
Revision on https://github.com/odoo/odoo/commit/4b3588feb2b7e260bf237b0f3944c90cdc47c3b5
In order to not replace characters with '*' in edit mode (because of `input`
with type 'password'), the above commit did not format the value at all.
The formatter of a char with the option 'isPassword' turns all of its
characters into '*'. That is not intended for password inputs, because the
content is hidden by the browser with the 'password' type.
The issue with not using the formatter is that an empty field has the value
`false`, so an empty password field produces an non-empty password input with
its value to 'false'.
This commit fixes the issue by forcing empty string for empty password values.
Note: if you use an integer field with password, falsy values (e.g. `0`) become
empty strings in the input value.
Purpose of this merge is to ease the use and discovery of activities by
notifying people assigned on an activity. This is limited to activities
assigned to another user than the creator to avoid being notified of
activities you just created for yourself.
This merge is related to task ID 1854820. Closes PR #25265.
When someone assigns an activity to another user it is a good idea to
notify this user a new activity has been assigned to him. This is done
using the message_notify method that sends a notification either in the
Inbox either by email depending on the user preferences.
This commits is linked to task ID 1854820. Closes PR #25265.
In af64780a2 an improvement was done so a numerical fields like '-500'
was not breaked up over two lines after the hyphen.
But it seems in a very particular case of printing PDF in a given
combination of condition:
- printing over wkhtmltopdf which itself uses an old version of webkit
- particular font (issue happen with Arial but not "Segoe UI")
- particular version of windows (windows server 2012, not on windows 10)
the - character at the front of a monetary, float or integer field would
be displayed as | erroneously.
The problem is probably that the font system in the old webkit with
given windows will not find the code point in the given font, and
doesn't fallback correctly.
This commit replace using the "NON-BREAKING HYPHEN (U+2011)" by using
the "ZERO WIDTH NO-BREAK SPACE (U+FEFF)" which is an invisible character
with no width that prevent splitting at its location.
As a note, an alternative to this character is "WORD JOINER (U+2060)"
that may be preferred, but it presents exactly the same issue (with
-|500 instead of -{WORD JOINER}500) in the same environment.
mentioned in https://www.odoo.com/forum/1/question/118653
opw-1867842
fixes#17093fixes#25840closes#26019
Before this commit, when someone was editing a password, the stored
password may not be the expected one by the user.
Steps to reproduce:
1. Open "Outgoing Mail Servers" form.
2. Set a password (e.g. "yop").
3. Save, then edit.
4. Add "y" at the end of the password field.
> Expected value: "yopy"
> Actual value: "***y"
This is due to the use of the char field formatter, which displays passwords
by replacing the characters with '*'. It is not necessary to do this in edit
mode, because it uses an input field of type 'password'. The browser
automatically hides the value of such inputs.
Any changes on a input field in edit mode uses the value of the input, so the
value of an password input should contain the password, without '*'.
This commit fixes the issue by using the formatter in edit mode for the input
of type 'password'.
Task-ID 1869565