Sibling commit of 427280d9760a71e6ca2961bcf4a2f9f157e6dddd, same use case.
Be in company C1. Create the invoice I for a SO in company C2.
The invoice line is with an account created of C1.
This is because property_account_income_id or property_account_income_categ_id
are company dependent properties that need to be accessed with a force_company.
This happens when e.g. C2 is a child company of C1.
However, accounts are not readable across companies, so the resulting invoice
cannot be validated in either company, since there is a mix of accounts.
Note that in case force_company is False, it defaults to the user's company,
which is already the default.
opw 2068291
forwardport of 79714bafe4b
closesodoo/odoo#37146
X-original-commit: ae84e7fd416c38404c20607b5b04fc1c9b790cde
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Commit c3717f3018 added a (5, 0, 0) command when modifying groups_id of any
non-internal user, to avoid the situation where the various implications would
end up giving the portal user group_user rights.
This risk is avoided by commit f206714af0, which added a constraint
check_one_user_type, which would raise in that specific case.
The last missing piece was 9badedcd98f; when groups are added through settings,
they are added through the implied_groups of the group model.
The (5,) command has the unfortunate side-effect to remove the portal group
from a user if a write is triggered programmatically.
If that happens, then the 'signing up' process end-destination is a 500 error.
Now we simplify the logic that keeping the same behaviour for implied_ids for
internal (group_user) and non-internal users.
We keep the (5,) command in one case: if a user is demoted to portal or public,
he may have groups should be reserved to internal users, but that do not imply
group_user (which would raise).
To avoid that, we remove all its groups, since there is no clear distinction
between technical display groups and actual privilege-granting groups.
opw 2041606
closesodoo/odoo#37144
X-original-commit: 29723e351d5dc5e5ea055c80da86f4e871909de9
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Steps to reproduce the bug:
- Go to Sales app and open the form view of a product P
- With studio add the field display_name in the view
- Try to create a new product
Bug:
A access error was raised because a read was made on a record in cache
opw:2070074
closesodoo/odoo#37133
X-original-commit: 90143c18f50ff31ded5aba7d7ba3beb66423ff06
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Create two operation types OP1, OP2 with code = mrp_manufacture
- Create a BOM B with operation type = OP2
- Create a MO with B
Bug:
The operation type set on the MO was OP1 instead of OP2
Technically:
The default value was always taken from function _get_default_picking_type
opw:2070370
closesodoo/odoo#37029
X-original-commit: 3c5338dce8db7606ac2ac0101473bcafe3bd4f76
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The test was made with an epsilon of 0.00001, which is precise enough to avoid
false positives, but allowing false negatives.
As a results, some orders can be incorrectly determined unpaid.
No (non-digital) currency has a precision higher than 0.00001,
but many currencies have a precision much lower (e.g the unit for ¥).
Also, we prepare for the future where all orders will be paid in Bitcoin.
opw 2059997
closesodoo/odoo#37112
X-original-commit: 73c2d46f4a443885fbf67879141ac892efebe3c7
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
— Create a new product, it's tracking must be set to 'By Unique Serial
Number';
— Create a new purchase order, with 500 lines. Each line with 10 units
of quantity of the previously created product;
— Confirm the purchase.
Before this commit, the creation of the stock piking take a quite some
time, and becomes difficult to use this functionality.
Now, the creation of the stock piking time was significantly improved.
opw-2070738
closesodoo/odoo#37107
X-original-commit: a434b087c86888903e320532b5e75856fa32bd13
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since fbbfa6d it's not longer possible
to write a date without separator (e.g., 0102 for 01/02/2019; 121298 for
12/12/1998; 02042018 for 02/04/2018), or a date without year (e.g.,
01/02 for 01/02/2019) in the datepicker widget.
In this commit we have decided to be as permissive as tempus dominus
that call moment.js with strict false. This allows moment.js to deduct a
date from a string in a more versatile way. This also allows a more
versatile autocomplete in the search views.
opw-2070464
opw-2070931
closesodoo/odoo#37095
Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the field cash_basis_base_account_id, used
to keep track of the base on which a tax a computed for cash basis entries
was required in the tax form view
Since this account can be absent, and will be most of the time, and that
an account is retrieved anyway in the move creation process it is safe
to remove the required attribute in the view
After this commit, the field is not required in view anymore
OPW 2072750
closesodoo/odoo#37060
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since commit 8fa9f7d6d4 refactoring the
actions server, the documentation was outdated.
This commit removes and fixes the documentation on ir.actions.server.
Also adds the display of the docstring of the IrActionsServer class from
odoo.addons.base.models.ir_actions.
Solves #31044
The `forcecreate=0` is required because the ICP will be deleted when set
to `False` (which is quite frequent for a boolean).
closesodoo/odoo#37103
X-original-commit: 255a12931d2a22dfadb1455a5dfc0a5e2f37b730
Signed-off-by: Christophe Simonis <chs@odoo.com>
When a title with boxed style (border arround title) is split (by doing
normal ENTER (and not shift ENTER which work as expected)) the title
being in inline-block for styling purpose, this give odd results (of
several title boxes on the same line).
With this commit style is changed so split title are on different lines.
opw-2070611
closes#37084
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
need seperate lines with different labels(SGST and CGST) on the invoice report and pos receipt
so use a tax group instead of repartition line
closesodoo/odoo#37080
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, discuss widgets had to wait for the route
`mail/init_messaging`. This behaviour slowed down the loading of the
web client.
This commit solves the issue by rendering discuss widgets even when
`mail/init_messaging` hasn't been resolved. For instance, the
messaging menu displays a spinner until messaging becomes ready.
Task-Id 2072835
closesodoo/odoo#37031
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, there was no way in the event question report
to filter out cancelled registration
After this commit, we introduce a filter for it
OPW 2072973
closesodoo/odoo#37032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Changed the way the header selector behave when the selection changes.
Before this commit, the header selector was only checked when clicked and
was unchecked as soon as any other record was unchecked.
Now, the header selector reflects the current visible selection:
if all of the other visible selectors are checked, it will be checked.
Folded records are not considered visible, thus only records from active groups
and from the current pager will be taken into account.
closesodoo/odoo#36522
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Added handling of invalid format types in multiple edition in list views.
Before this commit, in multiple edition, a field that was edited with an invalid value format
(e.g. a numeric field receiving a string value) didn't trigger a field_changed and no prompt
was shown; the record was simply idle with an dirty value.
Now, the list controller also listents for set_dirty events and automatically triggers
an error modal + discards all changes when receiving one.
Gives time to the user to enter an actual value in m2o in list views.
Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE)
triggered instantly a field_change. This was an issue in multi edition as a field
changed triggered instantly a save on selected records without giving time to the
user to enter a new value.
Now, many2ones only trigger a fieldChange when selecting a new valid value.
This rev. solves the similar issue as 801c603218, but with boolean
fields.
Scenario: select several records, select a boolean cell, press
enter to change the boolean value.
Task 2068280
Onchanges make no sense in multi edition as they would be computed
on the 'reference' record (the one use to edit), but applied on all
selected records. This rev. simply disables them in that case.
Task 2068280
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>
'Journal Entries' stat button on 'Configuration/Accounting/Reconciliation Models'
do not consider entries which are automatically validated.
closesodoo/odoo#36169
Task: 2056926
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Nans Lefebvre