When cropping the image with a size, we crop it first and then we make a thumbnail out of it
Before this commit, the same byte stream was used, meaning that the thumbnail was
appended to the original
After this commit, we reset the stream
OPW 1876496
closes#26575
Before this commit, when we applied two or more groupbys in line
graph, the groups displayed on the X axis where shifted to the left,
and the first one wasn't displayed at all.
related task: #1848289Closes: #25037
Let x_1, ..., x_a, x_{a+1}, ..., x_{a+k}, x_{a+k+1}, ..., x_{n} be a record
sequence ordered by its 'sequence' field.
Suppose the reordering occurs between elements x_{a+k} and x_{a+1}.
If the subsequence x_1, ..., x_a is ordered, then it does not change.
This is also true of the subsequence x_{a+k+1}, ..., x_{n}.
The resquence function makes exactly this assumption, and only sends the server
the subsequence x_{a+1}, ..., x_{a+k} to update its 'sequence' field.
The update of x is done as follows: it is index + offset, where index is the
position of x in the subsequence, and offset is the 'sequence' of the first
element of the sequence (i.e. x_{a+1}.sequence).
It is easy to see that we need another hypothesis: that the sequence numbers are
unique. To show it, suppose that the sequence of x_1, ..., x_a is 0, then all
x_{a+1}, ..., x_{a+k} have sequence 1, and lastly all x_{a+k}, x_{a+k+1}, ...,
x_{n} have sequence 2. Then after the call to the server resequence, the
subsequence x_{a+1}, ..., x_{a+k} would have sequence numbers 1, 2,..., k.
Since the x_{a+k+1}, ..., x_{n} subsequence have 'sequence' value 1, this would
obviously be incorrect.
We fix the reordering of the data in the js frontend to be consistent with
what is done by the server.
Note that this is only pertinent for sequences of reordering moves, since
otherwise the data comes directly from the server.
opw 1867049
In the reconciliation widget, search for an amount like 5361.61
Before this commit, if the targetted line that you want to see was represented as 5361.61000001
you did not see it in the results of the search
After this commit, you do!
OPW 1872543
closes#26523
Following 50ab18176 an access token is added in the URL, but there may
not be an existing access token. If so this commit generate one.
opw-1877347
closes#26526
Display the field date_open in the crm.lead form view
Create a new record
Before this commit, there was a crash because since the record is a virtual one
there is no create_date, hence the crash
After this commit, we make sure we select records that have a create_date, and there is no crash
OPW 1877080
closes#26499
- In some cases (merge of partners, etc ...) there might be mail.channel
that have two mail.channel.partner with the same res.partner.
When you try to open a discuss window with a partner for which you
have no existing mail.channel.
The channel opened is the one where your partner is duplicated.
This is due to the fact that the SQL request to find the mail.channel
doesn't take in account that a mail.channel may have twice the same
partner.
To fix this issue, we try to exactly match the partners we search.
Usecase to reproduce:
- Create a receipt for 1 dozen.
- Mark as todo
- Unlock and update initial demand to 3 dozen.
The reserved quantity on move line is 36 dozen.
It happens because reserved_availability and product_qty are
compare. However reserved_availability is in move UoM and product_qty
is in move's product UoM.
This commit clean the code in order to compare field that use the same
UoM.
Close#26504
- Go to a contact C1 > Membership tab > Buy membership
- Create an invoice with the membership
=> It creates a membership line on C1
- Change the partner on the invoice to C2
The membership line and the membership status is not transfered to C2.
We first need to recompute on C1, and we also need to explicitly write
the new partner C2 on the membership lines.
opw-1875673
- Go to a contact > Membership tab > Buy membership
- Create an invoice with the membership
=> The status of the member goes to 'Waiting membership'
- Validate the invoice
=> The status of the member goes to 'Invoiced membership'
- Create a credit note to cancel the membership
=> The status of the member goes to 'Paid members'.
It shouldn't be the case because the client has canceled his membership.
We look on `payment_move_line_ids` instead of `payment_ids`. Indeed, the
latter doesn't list credit notes, while the first one lists all move
lines used for payment.
opw-1875673
Because of 2917b38f28 which appeared in v9.0 but has not been adapted to the new API
afterwards, the early return was out of sync with what a search returns in new API
in v9.0: search returns a list, so must our early return
in v10.0: search returns a recordset, hence the fix
OPW 1878192
closes#26474
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
This reverts commit 6e8f1fcc63.
Reverted commit broke more than it fixed.
What it fixed : Show partner info when partner is changed after the
movelines are created (very specific used case, could be considered to
be the wrong way to do things)
What it broke : dropshipping
Use case specifically for round globally, but the justifications hold anyway
Have a session with one tax, multiple partners, and returns of freight (negative amounts)
When validating a pos.session, the computation of amls was a bit out of logic,
Namely, we grouped tax lines by :
1. their tax id (correct)
2. their partner_id (not wrong but limited)
3. their balance > 0 (wrong)
The justification for point 2 and 3 is two fold:
- Ultimately, the order is level of granularity that really makes sense
It's the order that is paid and therefore that has both legal and business meaning
and on which the amounts are retrieved anyway
- On the order, we litterally make the sum of tax amounts of each line, aggregating
credit and debit under the same variable
It is only logic to do the same for grouping the taxes at validation time
This commit only corrects the behavior for the rounding method 'globally'
OPW 1865700
closes#26203
LP Papillon