PR #16826 (rev fa3ff5b41a) added the
`company_id` field in the Journal Entry form.
Unfortunately that field was not marked read-only, so creating a move
would write to this field, triggering a useless and possibly very long
recomputation of many related fields based on the company of the
account. It must be read-only, its value solely driven by the value of
the account_id field.
To avoid harcorded dates in this test, we use next
monday as starting date for leaves and timesheets.
But today (19/03/2018), next monday will be after
the daylight savings time, so resource module gives
one additionnal day with one hour to be worked, so
one more timesheet is generated and fails the test.
To avoid this, we are now hardcoded dates to a monday
(to avoid weekend and global leaves) and be sure the
number of working days will be 3.
Before checking the first element of
'partner_id.child_ids', rather check that
the partner and not the object has children,
to avoid crashes when the partner of the PO
is a company.
opw-1826359
Before this commit, we had the following issue:
1. install CRM and Sales
2. Sales > Customers > (open any form)
3. Click on browser's "back" button
We are redirected to the contact kanban view in CRM
instead of Sales.
This is due to the fact that both menu items share the
same action. When the user uses the browser's "back" button
(AKA. it triggers an hashchange event), the web_client opens
the first menu_item that matches the action.
This commit fixes the issue by allowing us to open an action
by providing a menu ID:
1. If it matches the action, then it opens this menu
instead of the first match.
2. If we do not provide any menuID, or this menuID does
not match with the action, it falls back to the first
menu matching this action.
Fixes#23639
Before this commit, the menu_id displayed in the url was incorrect
when we click on a menu item for the first time.
This is due to the fact that the web_client was mistakenly using the
previous menu_id as the action's menu_id: the JS widget menu is not
up-to-date with the value of the current menuID, and the web client
was relying on its internal state instead of the server's response.
With this commit, the web client uses the server's reponse to
register the correct menuID that has been clicked.
* in _adyen_generate_merchant_sig_sha256 no need to encode dict key as we
have a normal dict. Because of this encoding it will search for byte
string key but we have string key;
* _adyen_generate_merchant_sig method requires the latest computed data
from adyen_form_generate_values method. If we directly pass the dictionary
while updating it, it will pass only business parameters and we don't need
it. After updating values we have actual transaction data.
This commit is related to task ID 1815966.
When configuring a survey with a
Multiple choice: only one answer
question,
the answers shown in the result may be in the wrong order
because of the use of a simple `Dict` instead
of an `OrderedDict`.
The behavior was increased when using Python 3.5,
as it randomizes on purpose dictionnaries.
opw-1818797
Having the 'on' using the same styling of the document name that is a link
make us think the 'on' is part of the name. Let us fix this small issue
by getting the 'on' out of the link tag.
Before this commit:
When you 'CONFIRM SALE', it would recompute the coupons just before
confirming the quote.
This would cause 2 issues:
1. You had no way to know what the generated SO will looks like (maybe unless
you know perfectly all the coupon promotions?).
You would end up with a 'surprise' SO that could be totally different from
the quote you just confirmed.
2. You had no way to cancel or prevent a coupon to be applied even if you
wanted to.
Eg: you don't wan't to offer this free forth iPad or this 10% discount to
that customer or this week.
Obviously, you could set all your coupons to be used with a code so the
recompute won't add any coupon to the quote but that would not make sense since
you would be limited to one coupon per SO.
At the end, there is a `UPDATE PROMOTIONS` on the quote which it's only purpose
is to recompute the coupons. The good practice would be to use that button
instead of using the confirm quote step to recompute the coupons.
Comes from #1967 (see review comment)
Steps to reproduce the bug:
-Activate multi currency
-Set the receivable account with the same currency of the company.
-Create a customer invoice in the currency of the company
-Register a payment for this invoice
Bug:
The payment was not reconciliated with the invoice.
opw:1826121
- Set an employee in a department A
- Create some timesheet entries for this employee, validate them
- Change the employee to department B
An error arise:
> You cannot modify an entry in a confirmed timesheet.
The field `department_id` on the `account.analytic.line` is a related on
`user.employee_ids.department_id`. By changing the department on the
employee, it changes the department on the analytic line (= timesheet).
There is no real need of a related field. Actually, it makes more sense
to change the department with the user (e.g. at creation or change of
the user), and then do not change it later on. Indeed, a timesheet entry
that was created when the employee was in department A should remain in
department A even if the employee change of department.
opw-1824913
Before this rev., the search menus (Filters, Group By, Favorites)
were lost when the user came back to an action with the
breadcrumbs (e.g. go to My pipeline, open a lead, click on the
Meetings stat button, go back to My pipeline).
This was because the two searchviews shared the same jQuery element
containing their dropdowns. This behavior is there for a long time,
but the bug has been revealed by 7b6056a0, which changes the way
the action manager and controllers interact with the control panel.
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
- This commit fixes crashes occuring when the expiry date for a credit card was invalid.
Instead of crashing we now warn the customer that the expiry date is invalid.
The recent change (e130606602) broke the use case of an invoice/payment in the company currency without any secondary currency involved. Payment was recorded correctly but no full reconciliation was created (and it was not tested).
In order to fix that, we allow to test total_debit and total_credit also when currency has never been set (no secondary currency at all)
In the frontend only plaintext is saved without any javascript fiddling
so in the controller it should be adapted to be saved.
With this change, the behavior is more similar to backend chatter which
sends html (processed by javascript) to the server.
opw-1817918
closes#23706
- The payment template is overwriting the return url which caused it to be never valid.
This is mainly used by payment that uses 3D Secure.
If the return_url doesn't exists, then the customer is redirect to '/' which is not what we want.
If the payment doesn't use 3D Secure, then the controllers that handle it may (and it is always the case) redirect the url to a hardcoded url inside it.
Revision on https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417
There was an issue with the nocontent helper of im_livechat channels where two paragraphs
were shown instead of a single one.
This was due to a typo where the paragraph was decorated with another paragraph tag.
The commit above tried to fix the issue by not decorating the static help with a paragraph,
since it already contains a paragraph. However, the fix introduced some dead code, so that
this overridden method has no purpose (it simply calls `super`).
This commit removes the overridden method, which preserves the current and correct behaviour.
IT was not possible to differenciate between variants as using the
product.template name in the message.
Same for the location were it was using the last level name (e.g. 'Shelve 42')
instead of the full path
Closes#20174
Along with new tests, 2 things have been changed:
1) amount_currency field is not written anymore when matching an amount paid in company currency against some invoice(s) in secondary currency (see changes in test_reconciliation.py)
This was previously made to help computing the exchange rate difference entry, but we now instead completelly rely on the amount_currency field set on the partial reconciliation. Besides being wrong from a purely functional pont of view (we never received money in secondary currency so why should the ORM act as if it was the case), it was the root cause of the problem related test_partial_reconcile_currencies_02, in test_reconciliation.py.
2) when registering a payment directly from an invoice, containing both an exchange difference and a write-off to force the full reconciliation, we now correctly create the accounting entries.
A weird behavior spotted in #21888 was introduced by 2093546, to deal with impossibility to full reconcile an invoice due to rounding errors. Fortunately, this use case (test_payment_and_writeoff_in_other_currency_3, in test_payment.py) can now be solved in the right way thanks to changes introduced in the previous point.
On mobile, kanban view always have its custom "menu" bar to cycle
between grouping if the kanban view is grouped.
But if the kanban view did not have the class `o_kanban_small_column`
the mobile CSS on record was not applied:
- all columns were always displayed one over the other
- switching tab did not hides other columns and show current one
- the style was the same than desktop (but on mobile and with column
after first "to be loaded)
opw-1827142
closes#23691
Github will automatically close the report is you use the format
Closes #number
No need to a leading #
cf https://help.github.com/articles/closing-issues-using-keywords/
Add the meaning of [I18N] tag
This commit is an example of a violation of the "one commit, one fix" principle
Example failing before this commit:
- amount = 11.01
- decimal = 11.01 % 1 = 0.009999999999999787
- 0.009999999999999787 < 0.01
Use correct float_is_zero method to test if there is decimal or not
Closes#18306
Jeremy Kersten