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
This reverts commit 08b2d1f9ac and the
subsequent commit a75533daf2be325e059f0d4badfb0cf3a2f7590f, because they
caused more problems than they solved.
Not only did we get issues with missing footers in some cases, but the
address box also gets misplaced on the left in many layouts.
See #31184, #31533, #31531
See opw-1925894 (reason for patch), opw-1948160 and similar ones (regressions)
Closes#31626
Before this commit, when hovering on a email icon of a message
in chatter without any customer email data, there was a crash
with the following error message:
"No enumerator given to foreach"
This was caused by `undefined` being passed to `t-foreach` when
there are no customer email data on the message. Since
`undefined == null`, it raised the error above.
closesodoo/odoo#31587
Signed-off-by: =?utf-8?b?QWxleGFuZHJlIEvDvGhuIChha3Up?= <aku@odoo.com>
`this._id` is overriden by the crosstab_bus, so the event handlers
weren't unbound at destroy.
closesodoo/odoo#31578
Signed-off-by: "Aaron Bohy (aab)" <aab@odoo.com>
Together d60f2ab0e2 and
24ca67b545
corrected the triggering of automated actions at *each* recompute of a field
It is problematic since, maybe, the field that should trigger an action
*is* a computed one. It often happens with "state"-like fields
This commit aims at applying the logic of those two commits,
except in the case we do want the action to be triggered
even in a recompute case
OPW 1935727
closesodoo/odoo#31422
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
On some chart of accounts, some records (e.g. account.tax on l10n_be) have
children and some are deactivated when the chart of account is created.
The children on the account.tax and templates were not created in the same order
The deactivated records were not found in the search.
Before this commit the translations did not match the right record on the
account.tax (e.g. 21% tax translated with a 12% name in Dutch)
Bug noticed with avw
closesodoo/odoo#31510
Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>
When creating a portal user from the User & Companies menu in the
Settings.
Before this commit, the created user had both groups' portal user and
internal user, which generated an error in the display of the user
accesses and rights. This also occurred if we manually add a portal
user to the internal user group.
Now, when creating a portal user, the user only has this group. Also,
if we manually add a portal user to the internal user group, an error
is raised to inform that only one user type is allowed.
OPW-1929367
closesodoo/odoo#30958
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
This commit add a default barcode on locations automatically
created once a new warehouse is created (stock, input, output, ...)
Task : 1939268
closesodoo/odoo#31000
Signed-off-by: "Simon Lejeune (sle)" <sle@openerp.com>
08b2d1f9ac was intended so margin on the top of the body worked (it
seems that wkhtmtopdf only started the body from the first visible
elements).
From a subsequent report, on some document template the CSS could have
adverse effect of not showing the footer.
With this changeset, the CSS is only applied on the body which was the
first intention.
fixes#31531
opw-1925894
closes#31533
Set the invoice policy to "ordered".
Then you can set to true the parameter "automatic_invoice", along with choosing
a mail template.
If you then set the invoice policy to "delivered",
"automatic_invoice" is rendered invisible.
However its value is not changed, so it is possible to have it set to true,
while the invoice policy is set to "delivered".
We change the parameter when settings are saved.
opw 1940641
closesodoo/odoo#31524
When confirming purchase orders with a lot of lines the performance
is very slow (sometimes reaches the memory limit). Creating the stock
moves in only a multiple create ameliorates the performance.
opw 1929276
closesodoo/odoo#31471
Commit fcb972d skipped a test on saas-12.2 after forward port as it was not
working on that version.
This commit restore the test and fix it.
It was actually a race condition on the save step on edit mode.
Something similar was done already for another test, see 74a98ea.
closesodoo/odoo#31465
When a blocking message is configured on a product, we force the removal
of the `product_id` on the SO line. This causes a problem in method
`_get_display_price`. When the pricelist is configured with
`discount_policy != with_discount`, `get_product_price_rule` is called
with an empty `self.product_id`.
We move the `product_id` removal at the end of the onchange.
opw-1934386
closesodoo/odoo#31456
With the BS4 update, a traceback occured when clicking on a m2m tag using colors
in a list view.
When using colors on m2m tags, the badge was wrapped inside a `dropdown-toggle`.
However, there is no `dropdown-menu` by default (it is only rendered in FormFieldMany2ManyTags
when clicking on the `.dropdown-toggle`, hence the traceback.
The `dropdown-toggle` class is now only set if necessary.
Task 1925313
closesodoo/odoo#31445
- Activate 'Multiple prices per product'
- Create a Product A, and add an entry in the 'Pricing' section of the
product form
- Create a SO, a product, and add A in the 'Optional Products' tab.
- Click on 'Add to order lines'
A crash occurs at currency conversion.
When getting the conversion rate, the company is empty in method
`_get_conversion_rate`. This is because the company is a stored related
field, which is computed after creation. However, the method
`_prepare_add_missing_fields` is called before creation. This method
calls several onchange methods, one of them computing a price
conversion.
We explicitly add the company when creating the SO line.
opw-1939106
closesodoo/odoo#31455