Stock moves show a detailed operations icon if the tracking, locations, or
consignment allow to be configured.
However it did so on a per move basis, only displaying it if the considered move
has some of these features.
This fix makes it that the "detailed operations" icon is always displayed if at
least one group of group_tracking_lot, group_stock_multi_locations, or
group_tracking_owner is active, or the move is tracked,
unless the move picking type already does show detailed operations.
opw 1893106closesodoo/odoo#28072
Create an automated action to create a new activity on update of a record
(e.g. a CRM lead).
At update, many fields recompute may be triggered, triggering as many write.
Thus it would generate many activities.
We simply do nothing if we are in a recompute.
Coauthored by rco
opw 1904156
closesodoo/odoo#28498
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
Also the behavior of not clearing the message if there was an error is
introduced back.
Without change in code, added test fails with:
"Should keep unsent message in the composer on failure" (result: "")
"Send button should be re-enabled on message post failure" (result: true)
issue found when checking opw-1904029
closes#28475
- Create a SO
- Paid the SO using a transaction
- Create an invoice from the SO
=> The invoice will now be reconciled automatically with the payment transaction
Was task: 1890029
Was PR #27390
Before that, with "post at bank reconciliation option" activated on bank journal, the following scenarii did not work as expected:
1. When creating an invoice, making two payments for it, and then matching only one of them with a bank statement
=> the invoice was marked as 'paid' while it should have staid 'in payment' until the second payment gets a bank statement.
2. When directly reconciling a bank statement with an invoice for its full amount
=> the invoice staid in "in payment" state, while it should have been "paid"
[IMP] account: add tests for the aforementioned cases
closesodoo/odoo#28428
Sometimes, a sale.order in the SALE state doesn't have a confirmed date,
which can cause a traceback. To avoid this, when confirmation_date is
null, use the write_date, which is never NULL when sale.order is in sale
state.
In migration, we will try to populate the confirmation date with
the mail.message subtype. As ultimate fallback, we will take
the write_date.
closesodoo/odoo#28296
Create an accrual leave, and set it e.g. by employee tag.
For each employee having the tag, a child allocation will be created.
When doing so, it will prepare the values for these creations.
However the relevant fields for accrual leaves were missing from these values.
opw 1906476
closesodoo/odoo#28492
1. Create a payment term with:
- 50% due now
- balance due in 14 days
2. Validate an invoice with this payment term and partner Agrolait
3. Create a payment from Agrolait with the 50% due
4. Add this outstanding credit to the invoice
It is reconciled with the balance due in 14 days instead of what is
due now. Because of this e.g. the Aged Receivable report will show the
customer being overdue with a payment.
This issue was first fixed in 9.0 at
adad192cc0. It was then reintroduced in
saas-11.4 at d3d2612061. This commit
adds a test to avoid regressions like this.
To fix the issue this sorts journal items by their Due Date if there
is one. Otherwise we use the date from the journal entry as before.
Note that before this commit journal items were not sorted at all by
the two 'sorted' statements. sorted returns a sorted recordset, it
doesn't modify the recordset it's called on.
opw-1906665
When changing the field `image` on `res.users`, the `write_date` of the user is
not updated because the field is inherited from `res.partner`.
Related to Issue : 1839603
This code is called by account_reports to build the Aged Receivable/Payable.
However, no support for the multi-company/multi-currency is there and then,
the multi-company filter on account_reports never worked.
In a multicompany environment, an user who has access to multiple companies is
able to select accounts and analytic accounts of multiple companies. This can
easily lead to mistakes in the definition of the asset category.
With this commit the user can only read/select accounts and analytic accounts
belonging to the company already set in the asset category.
This is what is already done in most invoice or other accounting views
Closes#26578
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
payment_term.id, creates a tuple wich works if payment_term.id is set
in case payment_term.id is False this creates the tuple (False,) which
is then converted by the Odoo ORM to a account.payment.term(False, )
record set, which in term may cause weird behaviour as this value does
not eval to false in cases like `if self.payment_term_id:`
Closesodoo/odoo#28397
Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.
Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.
Before that, taxes were only applied with the most recent currency rate, which caused problems in multi currencies, when reconciling statement lines made in the past with invoices, causing the amount currencies in the payment account.move to be wrong.
//Scenario to reproduce the issue (from customer ticket 1903497):
(for a company with USD as base currency)
1. Create a new bank journal for EUR payments
2. Create a new customer invoice for 90€
3. Create a new tax for the reconciliation model, price-included and amounting to 15%
4. Create a new reconciliation model using this tax
5. Use the currency rates from the demo data, add one that is closer to current date than the most recent one.
6. Create a new bank statement for the created EUR bank journal. Make sure that the transaction is less than the actual amount due on the invoice so that we can apply the reconciliation model. Also make sure to set a date on the transaction that lies in the past at some point when the currency rate was (significantly) different.
7. Hit the reconcile button, select the amount due from the invoice and apply the discount reconciliation model(take note of the amount on the created tax move line). Now reconcile.
What is the current behavior that you observe?
Now go back to the bank statement and check the created journal entries. You will see a difference in the amount currency values of the payment and the tax account move line. This difference should not exist.
Revert commits da2140b726, e65c8826ef and 06cd145a79. They
introduce an incorrect UOM.
The original issue was an `AccessError` due to the fact that the
employee chosen was not in the same company than the user. Therefore,
instead of changing the logic of the UOM selection, we make sure to
select the employee in the appropriate company first, then fall back on
any company then.
opw-1888299
Due to the implementation of PEP-475[1] in Python 3.5, revision
e98e8e9b1b used the recommended technique
of wakeup file descriptors in order to detect interruption of sleep() and
select() by signals, when running in multi-process mode (workers > 0).
The technique works well, however the initial patch never bothered to
read the byte that is written to the wakeup pipe when a signal is
processed. This does not matter when the signal is meant to shut down
the server, but it matters when the signal is SIGQUIT: it simply prints
thread dumps, and continues operating normally.
As a consequence, that byte remains in the wakeup pipe forever, causing
all the subsequent select/sleep calls to return immediately because
the wakeup fd *is* already ready. The symptom was that worker
processes would start cycling their main run loop very fast after
receiving a SIGQUIT signal, eating 100% CPU.
This patch ensures we always empty the wakeup pipe after an interruptible
call, to avoid this effect. It also refactors another occurrence of the
"empty pipe" pattern, in the PreforkServer, and incidentally uses readable
aliases for the file descriptors bound to the ends of the wakeup pipe
(wakeup_fd_r / wakeup_fd_w).
[1] https://www.python.org/dev/peps/pep-0475closesodoo/odoo#28356
This commit tackles the issue of having the pseudo-object 'parent' in the
invoice lines views
In the regular o2m, parent refers to the current invoice
From commit eca030cc38
we learn that parent.get() is not a valid field according to python
From OPW 1912243, we learn that:
- when the invoice line form view is standalone (not popped from the o2m)
'parent' is not what we expect (in this case it will refer to the record list of all invoice lines, NOT the invoice)
- parent.type in that case is undefined and makes the JS crash
So, to make sure we retrieve the right field and value, we retrieve them through
related fields pointing to the invoice
closesodoo/odoo#29074
Have an expense product with a supplier tax on it
Write an email to be caught by the thread model to create an expense for that product
Before this commit, the tax was not set up on the expense
After this commit, it is
OPW 1908596
closesodoo/odoo#29061
Have a form record with a progress bar
Modify the max_value of the progress, as well as the current_value bar through an onchange
Before this commit, the new max_value was not taken into account
After this commit, it is.
closesodoo/odoo#29056
Have a sales team without a target in the kanban view
click on define a target
Before this commit, the veiw wasn't rerendered, so the change apparently did not happen
(while the write was triggered)
Also, the Enter key did not work to validate the input
After this commit, the view is refreshed and the enter key works
OPW 1906938
closesodoo/odoo#29055
Send a message using the popup editor.
Drag and drop an image into the message content.
It will create an attachment for the inlined image.
To generate the values for the attachment, a regex is used to parse the content.
Besides summoning Eldritch abominations, it didnt't take into account the
original filename, whereas the default one (image) would have no extension.
We extend the regex to capture the filename and use it.
opw 1903194
closesodoo/odoo#28527
Send a message using the popup editor.
Drag and drop an image into the message content.
It will create an attachment for the inlined image.
However it did give a res_model value of mail.message but no res_id;
add_missing_default_value would fill in the res_id from the _context, which is
not the mail_message but the current object on which it applies
(e.g. helpdesk.ticket).
We put the correct res_model along with the res_id.
opw 1903194
closesodoo/odoo#28526
When creating a SO line and clicking on search more for product_id
Before this commit, every user had the button "Create" to create a product.product
After this commit, only user in groups that actually can create a product have the button
OPW 1910371
closesodoo/odoo#28924
When creating a mail for a user in an other company then the
record, the "send" button fails with a traceback because on
specific template try to access the company.id of the user
which is not accessible due to the access controle.
This PR fixes the problem by sudoing the access to company id.
The mail now sends without problem.
Step to reproduce:
1. Use two companies (comp1 and comp2)
2. Use 3 users (user1, user2, user3)
3. Be sure every user has a confirmed account
4. Change the users to set both company as allowed.
5. Set the current company of the users as follow:
user1: comp1
user2: comp2
user3: comp2
6. Install the project module
7. In `settings > security > record rules`, archive the rules named:
- `Project: multiple-company`
- `Project/Task: multiple-company`
- `user rule`
8. Using user1, create a new project and a new task.
9. Using user2, go to `Project module > Search`, remove `My tasks` filter,
select the task created by user1, in the chatter add user3 as follower.
10. Send the mail => access error.
The `AccessError` is due to user2 trying to access comp1, in particular
`company.name`.
By adding a `sudo`, we also make sure that the template rendering won't
fail bacause of a similar `AccessError`.
opw-1907844
closesodoo/odoo#28710
Define a x2m tree view with a default_sort including more than 1 field to order the list against
Before this commit, the second field was never used
After this commit, it is used
OPW 1909785
closesodoo/odoo#28840
When opening the Manual Reconciliation widget, all partners with opened
invoices and payments are fetched.
In some cases, the database might contain a lot of partners without any
reconciliation suggestion; therefore, the partners with suggestions are
'lost' in the view.
This commit sorts the data: we first display the parters with a
suggestion, then the others. This should improve the usability of the
view.
opw-1903575
closesodoo/odoo#28958
Consider a many2one field `foo_id` on model `bar`, with an inverse one2many
field `bar_ids` on model `foo`. During an onchange, the statement
bar.foo_id = foo
puts a special value in cache to add `bar` to the value of `foo.bar_ids`
without explicitly reading `foo.bar_ids`.
Executing the above statement a second time, the cache of `foo.bar_ids` is no
longer empty. This causes the actual value of `foo.bar_ids` to be read and
updated. The issue is that this can be slow for large values of `foo.bar_ids`.
Avoid reading the value of the one2many field by handling the case where the
cache contains the special value: simply update the special value to take into
account the second assignment.
closesodoo/odoo#28982
Embedding a video can't work because it embeds an iframe, which is not supported
by most email clients for security reasons.
(What happens when Gmail shows embedded videos in displayed emails, is that you
send a link in the email body, and it is at rendering that Gmail adds the iframe
into the page.)
So the bugfix solution is to hide the button.
Since there is an option "res_model" that allows us to know when we are in that
case, we remove the video option.
opw 1905497
closesodoo/odoo#28911
In the case of calculating payroll, we don't want to convert the
datetimes using the timezone of the user as we really want to see what
the employee has done from one date to another (usually from the start of
the month to end of the month)
Closes#26256closesodoo/odoo#28977
Fine-tuning of commit: o50f77ba091189bd785d459c042a6cec04a125fdb
When costing is in FIFO mode, product price can be updated whereas the current
user doesn't have the right to modify the products.
It therefore introduced a sudo() to make this computation;
however since this is modifying a company-dependent field,
a force_company was missing to update the correct one.
Closes#28487
opw 1907377
closesodoo/odoo#28662
This commit extend commit https://github.com/odoo/odoo/commit/ef48b81ab127dd717a4a9d106edd5c51121bc8f7
When you have a cart on multiple session and confirm the card in one of them,
you could still access your cart from other session (note that you could not do
anything with it as it would be reset when adding product or changing qty).
Closes#28210
len-odoo