In a multiple company account, when a parter is doesn't have a
company, the mails he revieved have "Send by using odoo" as footer.
This PR correct that by setting the footer to "Send using odoo" when
there is no company.
opw-1894825
In a multiple company account, when creating an event without
company, the emails sent contain "Send by False" as footer, this
PR correct that by disabling the footer in case there is no company
opw-1894825
Before this commit, RTL on frontend was only enabled for connected user.
To have RTL, we add the direction on the element, and the RTL version of
the stylesheet for the applicable languages are generated thanks to rtlcss.
opw-1892757
closes#28434
Odoo 12.0 does *not* officially support any python version below 3.5,
but no effort had been made to gracefully announce this to the end user
if they were to run Odoo in an unsupported python version.
This is done because Odoo 12.0 uses py3-only constructs which can
and will raise different errors if ran in python 2.
With this patch, Odoo will display an appropriate error message and won't
launch at all unless it is being run with python 3.5 or greater.
closesodoo/odoo#28502
Suppose you are editing a SO to add a new line. Depending on the configuration,
a sale order line wizard may open (e.g. if packages are activated).
This wizard is a form view, opened from the tree view of the sale order lines.
We have commit 8e5156938a
that adds extra fields from the originating view.
(However it doesn't work if the other view is inlined, so we modify this part to
add the extra field even in this case.)
Then we need the field info from the origin view in the target view;
we do so by extending the former with the content of the latter.
opw 1904337
closesodoo/odoo#28441
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
- When creating an eCommerce cart using the Public User, the code tries
to access all the sale orders linked to it.
Depending on the count of sale orders linked to the partner, the
loading can take a lot of time.
To avoid this, we only search for the sale orders of connected users
and we only retrieve the last one.
- 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
When loading the Reconciliation Widget, all reconciliation models are
retrieved. This is not correct: only the one matching the company and
the journal should be retrieved.
Fixes#28270
opw-1904475
closesodoo/odoo#28474
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
Before this commit, if you ask for a small image, you was waiting a picture of
64x64 but in case this image was not found, a placeholder with an other size
was returned.
Now, we try to guess the asked size, and return a resized placeholder.
This bug appear since we change the default placeholder picture with a big one
This will fix several issue and avoid to hard code size everywhere in the code
Eg: commit 92f837c and commit https://github.com/odoo/odoo/commit/154fc7d9dd550d35b7266af024e54c20e18938fc#diff-9af1af2039d16d6b544d481b4ee1ed7cR144closesodoo/odoo#27695
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
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.
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 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
Julien (juc) Castiaux