Gave back focus to the last edited cell to increase usability with key nav.
Before this commit, after saving several records with multi edition in a list,
focus was lost (given to the body).
Now, last edited cell is given back the focus after multi editing.
The Date(Time)Fields listen to 'input' and 'change' events (like
all InputFields) to keep track of changes. However, the datepicker
already listens to the 'change' event. As a consequence, in multi
edition in a list view, if the user changed the value of a
date(time) field by directly editing the input, the fieldChanged
event was triggered twice, and there were 2 dialogs asking the user
if he wanted to save the change.
This rev. makes the Date(Time)Fields stop listening themselves to
'input' and 'change' events, and instead completely rely on the
datepicker widget.
Task 2068280
Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.
Task 2068280
Having those inputs enabled can lead to weird situations where a
record has been modified but can't be saved anymore (because the
user clicked on one of those record selectors to focusout the edited
row). Also we don't want the user to start multi-editing a field,
then change the selection, and then validate the changes.
Task 2068280
Before this commit, if a record was selected and another one was edited,
it was considered as multi edition.
Now, the multi edition only works if the edited record is included in the
selection; else it will be the only edited record (single edition).
Task 2068280
...when validating last row by pressing ENTER.
In single edition, we automatically add a new row when the user
edits the last one and presses ENTER. This is something we don't
want in multi edition.
Task 2068280
Fixes the way many2one fields are rendered in editable list views.
Before this commit, many2ones in readonly mode would render as links
and their widget would be considered as active even though you couldn't
edit it.
Now, they are rendered as plain text and act the same way as readonly char fields.
Fixes the way records are discarded in list views
Before this commit, clicking the "Discard changes" button in a list view
after editing a record triggered both the "field changed" and the "discard changes"
methods (resulting in 2 modals opening).
Now, all fieldChanges are prevented when trying to click "Discard changes",
and are re-applied if the click was unsuccessful (lifted left mouse button somewhere else).
Task 2068280
Let's assume an editable list view with a many2one field and 2
records: the first one has value 1, the second value 2. The user
selects all records and wants to set their many2one to value 1. It
edits the first one, sets 1 and validates the confirm dialog.
Before this rev., it didn't save anything because the 'reference'
record (the one used to edit), didn't actually changed, as we reset
the same value.
This rev. forces the write the new value on all selected records in
that case.
Task 2068280
Backport of 10eaf74230
Fixed crashes/incorrect behaviours in multi edition in the list views.
The solution to these problems was mainly to refactor the function
used to save multiple records.
Before this commit:
- Cancelling the confirmation dialog in multi edition caused
the edited record to be editable but disabled
- Saving an empty field in multi edition triggered a JS error
- Static confirmation message ("saving 0 valid records")
After this commit:
- Ability to cancel confirmation
- Proper error display when trying to save empty fields
- Message consistent with the situation
Backport of 1f2c64013
Adding a line in grouped listviews caused a crash in some cases.
Steps to reproduce:
- go in any grouped editable list view
- click on any "Add a line" cell, but not on the link itself
- press ENTER
Before this commit:
A crash occured. Unable to add a new line. Needed to refresh the page.
After this commit:
Line addition functionnality properly working even when selecting the outer cell
Backport of 801c603218
Pressing ENTER on a button element triggers an additionnal 'click' event.
Since this 'unwanted' click caused some issues in a few cases, we prevent it.
Moreover, there isn't currently any known case in which this event is useful.
Before this commit:
No modification of the initial behaviour on ENTER key
After this commit:
ENTER key pressed in abstract fields has its default behaviour suppressed
Before this commit, the cart recovery email displayed all lines of the order
After this commit, the email only shows relevant lines, that is
excluding deliveries for example
OPW 2072814
closesodoo/odoo#37025
X-original-commit: 234c3f56f4c03281f068981cd5af6bc8f5956334
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a multiwebsite setup
have stripe installed for one of the two websites
Make an order on that website and try to pay with stripe
Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP
After this commit, the payment success page is opened as we took
the request's url as the return url
OPW 2070428
closesodoo/odoo#37024
X-original-commit: 937b5c076e7175bec664ed0cf4b77505e342f1e2
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
If you register online on a free event, there is an
access rights error when trying to download the ICS file
if you are connectd with public user.
`if not event` part is pointless, if event cannot be resolved,
@http.route would return a 404 anyway.
`if not event.registration_ids` does not make sense from a
functional point of view: there is no problem in generating
an .ics file for a public event that has no registrations (yet)
and the button we use to generate the .ics file is displayed
after the registration anyway.
opw-2066847
closesodoo/odoo#37012
X-origin-commit: f4ca5897df9295b684bcbfcafd98fbde2f8bf673
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- Let's consider the portal user Pu, the project Pr and the task Ta
- Add Pu as a follower of Pr
- Log as Pu and open Ta
- Try to post a message
Bug:
An access error was raised due to the rule "res_partner: portal/public: read
access on my commercial partner".
opw:2070320
closesodoo/odoo#36960
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In some cases, after installing a new language in rte_translator tour,
some query using ir_translation table will become very slow.
Identified query:
SELECT res_groups_users_rel.uid, res_groups_users_rel.gid
FROM res_groups_users_rel, "res_groups" LEFT JOIN "ir_translation" as "res_groups__name"
ON ("res_groups"."id" = "res_groups__name"."res_id"
AND "res_groups__name"."type" = 'model'
AND "res_groups__name"."name" = 'res.groups,name'
AND "res_groups__name"."lang" = 'en_US'
AND "res_groups__name"."value" ! '')
WHERE 1=1 AND res_groups_users_rel.uid IN (2) AND res_groups_users_rel.gid = res_groups.id
ORDER BY COALESE("res_groups__name"."value", "res_groups"."name") OFFSET 0´
During post_install this query will become slower (between 0.7 and 2 seconds) ~50%
of the time, when this usually take less than 0.1 second.
For some tour step, this query is executed several times, making a simple
/web loading going from less than one second to more than 10 second, breaking the tour.
The main intuition behind that would be that the query plan completely fails,
mainly because postgress is to busy and doesn't have time to launch an analyse
when runbot load is high.
This commit proposes to execute a manual ANALYZE on ir_translation table
after a new language is installed. Tested with 40 builds, rte_translator never failed
with this fix.
cherry-pick of fc5934dc45closesodoo/odoo#37013
X-original-commit: 57f91453cb567d8a7a29137b321a630fe0dbb9a6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Be in company C1. Create the invoice I for a SO in company C2.
The invoice is created on the default account.journal for C1.
This happens when e.g. C2 is a child company of C1.
Then I is accessible from C1, but not from C2
as reading the journal violates the multi-company record rules.
Note that if company_id == False, then
self.env['account.invoice'].with_context(company_id=company_id)
.default_get(['journal_id'])['journal_id']
returns False, and in that case, it would raise below.
To keep with the existing behaviour, we put a fallback on
self.env.user.company_id.id
which means that the values we pass are:
'company_id': False, 'journal_id': J for some J in company C
which is flaky, but won't trigger any extra errors.
opw 2068291
closesodoo/odoo#37002
X-original-commit: 427280d9760a71e6ca2961bcf4a2f9f157e6dddd
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Steps to reproduce the bug:
- Let's consider that warehouse A resupplies from warehouse B
- A has Outgoing Shipments in one step
- B has Outgoing Shipments in two steps
- Change Outgoing Shipments of B in one step
Bug: An integrity error was raised because route_id field is required
on model 'stock.rule'
PS Inspired from function create_resupply_routes
opw:2069163
closesodoo/odoo#36991
X-original-commit: 2a87b56efab1246fa85c1b507322e0909db3dd20
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Some operations call the WizardMultiChartsAccounts.existing_accounting
(file chart_template.py), such as going to the settings of the Accounting app.
This function tests whether any lines are present in several tables related
to accouting.
Before this commit:
a search is performed throughout the tables and takes forever for a large db.
Partner reports: "with current code, a customer with 12M account move lines
gets an out of memory error after the screen has sat for 10 minutes - this is
because the code is doing a read on every row in the account move line just to
see if the user company has a record".
After this commit:
with limit=1, the search stops after only one line is found in any table.
closesodoo/odoo#36975
Opw: 2066938
X-original-commit: 80563819ae93c00d171935f1d1cded33de15ba21
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before that, when using a small screen (with width <= 768 px) and
showing the accounting dashboard of a company without any chart of
accounts installed, the icon and message prompting to install a chart of
accounts was displayed in the lower left corner, instead of being
horizontally centered.
closesodoo/odoo#36974
X-original-commit: 4999f47d7e283c6a5799e68f2b0e1351638e17a3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
-Create a random journal entry affecting the partner A, using a receivable/payable account.
-Let the journal entry in draft.
=> The amount set on the line must not be sum in the partner's amount_due.
closesodoo/odoo#36973
X-original-commit: 3ab4589ff444da9889ac922ac9d7ba6c8e8638bc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Following 40487aca5c there was an issue
where a delivery could be splitted because of mrp specific code.
This test checks that when creating a sale order including a level 3
bom (MTO) the delivery is one, containing the correct products
closesodoo/odoo#36961
X-original-commit: c07ecea7923c1609c4461fadbc61040e9fd3d86a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On the pivot view, there is the following unsigned measure fields:
"account_tax" and "account_untaxed".
It can cause mistakes since for example the sum of a invoice an its
full credit note should be zero, but here it will be double the amount.
So here we complete 97aec9f8 for two fields that were still available.
opw-2071027
closes#36940closesodoo/odoo#36971
X-original-commit: 2dc8e2feec9e5b604e0c0acae52562822a113342
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The progress bar was pretty broken before this commit.
> It was not possible to input the value as text
> Moving the progress bar to modify value and saving crashed
> modifying the max value crashed
> The whole feature was ill-defined
With this commit, we fix the crashed. It is now possible to write the field
behind the progress bar by moving it in RO mode
or by typing the input in RW mode
*if it is the value we want to write on*
It it is the max value that the field targets, we can do it in RO and RW mode,
only with the input as text
Note that this works *only if* the editable option on the widget is set to true
OPW 2061846
closesodoo/odoo#36928closesodoo/odoo#36970
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In case you have a button of type action, the controller is doing an rpc
on the model using the right method, but in this rpc, the context is not
passed.
This creates a translation problem (nothing is translated) since the
language is not defined in the context.
Task Id 2062419
Closes#36189closesodoo/odoo#36969
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There is no need to redefine `_get_stripe_api_url` by adding `https`
since all existing calls to the method programmatically add it already.
Therefore, we use the same approach: we add `https://`, then join the
URL.
opw-2031745
closesodoo/odoo#36957
X-original-commit: 0412786486462423c91afc1c5a4dcb25886827e4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Log an error only if a transaction exists.
opw-2071862
closesodoo/odoo#36946
X-original-commit: 903bd53d5f11dc9a9cfea246e6c5c0a088ad02ba
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Change the date format of your current lang
- Reconcile a statement
Bug:
The maturity date displayed in the widget didn't use the format of your
current lang.
opw:2068241
closesodoo/odoo#36944
X-original-commit: d2ad3d6542bfe1c900720148f22abe4b507e2a41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
before this commit: it gives error when we redirect to payumoney site
after this commit: payment testing in payumoney is working as expected
closesodoo/odoo#36937
X-original-commit: 97c0ece7857ca56b1fd20d3772262def5aeebdc4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reverts d91b1e5bd5
But still handles the use case (cancelling transfer payment)
Make a payment, confirm it
The payment's move has a name, i.e. constructed from its sequence
Cancel it
the payment has no move anymore
Re-confirm the payment
Before this commit, the new move had a new name from a new sequence number
This is problematic to ensure accounting consistency
Besides, it was not the way it works for invoices' moves
After this commit, the former name of the move is taken
to build the new move of the re-confirmed payment
OPW 2046412
OPW 2070167
closesodoo/odoo#36868closesodoo/odoo#36922
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When processing a payment in Ecommerce, if the payment
acquirer communication is defined on 'Based on Document Reference'
and if the sale order sequence is having a suffix, we have
an internal error due to a bad implemented regexp.
opw-2067596
closes#36867closesodoo/odoo#36892
X-original-commit: b08a0025e7900554791a4e42bddcbeb09739a8a1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
In case no email address was specified on the delivery address stripe
redirect flow will fail, so we define a fallback on the billing partner
email.
closesodoo/odoo#36833closesodoo/odoo#36862
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* website
Following the new editor merge at https://github.com/odoo/odoo/pull/29775
(which was finally partially reverted for 13.0), the crop dialog was not
working anymore on sub-sequent crop. This was due to 2 things:
1) Re-cropping an image that was just cropped now
The original source of the recently cropped image is saved as temporary
jQuery data on the image element. Unfortunately, for some strange
reason, that image is cloned before any edition and thus lose that data.
This commit fixes the problem by cloning the data too... supposing the
orignal clone is there for a reason.
2) Re-cropping an image that was saved before
This did not work anymore simply because... the cropped images were not
saved in database anymore but saved as base64 data in the view... For
some reason, the cropped images to save were searched in the original
DOM instead of the edited DOM...
Also fixing the random use of a mutex.
Discovered while working on task-2059480
closesodoo/odoo#36878
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With the PSD2 directive coming into effect on September 14th,
was had no choice but to switch our Stripe integration to use
newer APIs that support Strong Customer Authentication (SCA for short).
This meant switching from the old stripe.js implementation for
'redirection' flow to the Stripe Checkout API and from the
Charge API to the newer SetupIntent & PaymentIntent APIs
for s2s flows.
This new modules introduce these changes in a non-intrusive way,
this means that installing this module is *not* required for
all customers (e.g. instances only accepting payment to and
from countries that are not part of the EU), that installing it
will support SCA flows and that uninstallation leaves you with
a working instance as well.
Task 2039100
closesodoo/odoo#36869
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With the PSD2 directive coming into effect on September 14th,
was had no choice but to switch our Stripe integration to use
newer APIs that support Strong Customer Authentication (SCA for short).
This meant switching from the old stripe.js implementation for
'redirection' flow to the Stripe Checkout API and from the
Charge API to the newer SetupIntent API for s2s flows.
This new modules introduce these changes in a non-intrusive way,
this means that installing this module is *not* required for
all customers (e.g. instances only accepting payment to and
from countries that are not part of the EU), that installing it
will support SCA flows and that uninstallation leaves you with
a working instance as well. Essentially a backport of 9f5f2fc
in a seperate module.
Task 2039100
- allow acquirers to arbitrarily include info about the tx in the
processing page
- pending is now a valid state that could require customer action in the
payment processing page - don't blindly redirect to the return url of
another tx if a pending transaction is there
This latest change might mean that customers with many tx attempts might
have a sub-par experience as they may need to click manually on the
redirect url of a successful tx while before they were redirected
immediately.
Be in multi-company, with shared products, let P be a product in company C.
Suppose there are stock moves or pickings in company C'.
Suppose a non-admin writes on P: it triggers an access error.
Stock moves are not shared across companies in all cases.
So fields that depend on product_id might trigger a recompute on stock.moves
that are in another company, and thus trigger a spurious ACL error while
simply writing product attributes.
Note that _cal_move_weight depends on product_qty, however it is not sufficient
to only put that field in compute_sudo; the product_qty has already been marked
as todo, and so it is recomputed in the initial environment.
opw 2066691
forward port of 7d4d8fa18aecb3b78c8d359434a165c1de71a9b4
closesodoo/odoo#36838
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
As of this commit, the menu items Customers/Products and Vendors/Products now display product templates instead of product variants, which makes more sense in the scope of invoicing/accounting.
task-2052537
closesodoo/odoo#36802
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Indeed since a lot of cleaning has happened, notably merging lead and
opportunity views and actions cleaning, let us have a real name for
that main action instead of a bad and error-prone name.
Task 2070287
closesodoo/odoo#36676
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Fixes traceback when clicking on "re-send letter" or "cancel letter" buttons
(RPCs were being made with wrong number of arguments)
makes the "Buy credits" link open in a new tab to not interrupt the user's workflow
task-2068271
closesodoo/odoo#36667
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In this commit, replaced label string 'Finished Products' to 'By-Products'
inside the work order form view. It's more readable and useful to the user
task-2058431
closesodoo/odoo#36343
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Julien Mougenot