In order to test performances let us be sure all modules are installed.
Task-2703289 (Event testing and coverage)
Preparing Task-2703285 (Event performance improvements)
Part-of: odoo/odoo#81717
Followup of odoo/odoo@034d369 . Now that followers computation is done in
batch we gain 1 query per additional record to create in a recordset. Indeed
some searches are now performed in batch instead of in loop. This allows to
gain notably 19 queries on batch of 20 records to create for example.
Task-2703289 (Event testing and coverage)
Preparing Task-2703285 (Event performance improvements)
Part-of: odoo/odoo#81717
Current behavior :
Cash in/out button is not present on mobile PoS app
Steps to reproduce :
- Go on your mobile app
- Go in PoS app
opw-2704097
closesodoo/odoo#81758
X-original-commit: cdd2475251e161e5029fc5a363e28aa8163fc490
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
The previous code resulted in only the last editor to trigger its
handler having hints, as all the others would be killed by the last one.
closesodoo/odoo#81743
Task-id: 2632841
X-original-commit: e24b039ea120597ff5438deca3c69c7a1d54cd31
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This label was defined with 'for="match_text_location_label"', even though it actually isn't met for just that field, but for the three boolean fields allowing to choose where to match on the statement line. As a consequence, in debug, it displayed the helper of that field, which was confusing for the user.
closesodoo/odoo#81730
X-original-commit: a89c6300f3b9b22fc4e18b286f2f28734e750638
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name.
This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working.
As an example, consider the following case:
1) setup an invoice-matcing reconciliation model as such:
- Partner Is Set and Matches = False
- Match Invoice/bill with = Reference
2) Create an invoice with payment reference 123, for 100€
3) Create a statement line of 100€, with reference ('ref' field, inherited from account.move) = 123, label='test', and no partner set.
4) Try to reconcile the statement line
=> not match is found
OPW 2701729
X-original-commit: 74894b0da82f5f71cd22a3c9bb405696f908ef5c
Part-of: odoo/odoo#81730
Issue
-----
When a customer sign and pay a sale order from the portal and
automatic invoicing is enabled, it generate an invoice.
Once the payment done the customer is redirected to
the sale order preview with a link to the invoice created.
To display the link to the invoice the method _portal_ensure_token() is
called and write the access token token.
In parallel, if the invoice need to send edi document, the cron job is
triggered at the posting of the invoice and thus the cron job try to
write as well on the invoice as the invoice link is displayed to the
customer
This lead to a concurrent update for the cron job that do not retry in
case of concurrent update as normal transactions do. So the edi document
is never synchronized and the invoice never sent
Solution
--------
Avoid to write on the invoice while displaying the sale order portal
view by already generating the access_token in the transaction that post
the invoice
closesodoo/odoo#81731
X-original-commit: ccf76a5b8c0671e69e8875ea476d13005dab8d72
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Context
-------
On some database, record rule may be configured in such a way
that user are able to read Purchase/Sale order
with a company_id != user.company_ids
Issue
-----
This commit https://github.com/odoo/odoo/commit/4dd150950274b1d7c3b24b7665443318f94323f6#
introduce a new field tax_country_id that require to be able to read
the fiscal.position as well.
The reading of a sale.order or purchase.order should not require the
right to read the fiscal.position for the computation of a technical
field only use during the modification.
Solution
--------
Compute tax_country_id as sudo
closesodoo/odoo#80049
X-original-commit: b329c3b18197ac6db5ffdf3cb4945a14997a1f0b
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Description of the issue/feature this PR addresses:
duplicate mandatory field in popup when save the contact record.
Current behavior before PR:
Its showing same field name twice in popup which asking invalid fields.
Desired behavior after PR is merged:
it should show 'name' field only once.
Fixes#79753closesodoo/odoo#81727
X-original-commit: eb4b49e7078f4aa90f9d652de10386da38ded2dc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Problem 1: The context was not passed when calling the resequence function.
Problem 2: Also, the subsequent read operation did not pass the full
context, but only the context of the user, not the context of the action.
A test has been added for the basic model to check that the context is properly
given after a resequence.
closesodoo/odoo#81726
X-original-commit: 75bbec4f7fe14aa9d9c310ffcbd500bd1f70b14f
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Renamed the 'Other' account type into 'Non Trade' to enhance clarity and coherence
Changed the filtering system in the accounting search view to improve coherence with the filtering system available in the reports.
It is now possible to filter the trade/non trade accounts in the accounting views.
This change may be overriden by default selections already in place.
Renaming Receivable/Payable to Trade Receivable/Trade Payable could have turned out to be confusing for accustomed users.
They are now renamed Receivable/Payable, though the Non-Trade option is still present.
task-2669128
closesodoo/odoo#79752
Related: odoo/enterprise#21773
Related: odoo/upgrade#3004
Signed-off-by: Laurent Smet <las@odoo.com>
Prior to this commit, the _search_valid method returns all the time off types.
With this commit, only the time off types that have a valid allocation are returned
task-2711388
closesodoo/odoo#81724
X-original-commit: 20a2b29ee273c505f0279f128e8ac6c13c5be043
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, in some cases the submit button of the form snippet
never stopped loading after being clicked (e.g. redirect to an anchor in
the same page).
Now, the form and the button loading effect are reset at the same time
at the appropriate time depending on the post-send action:
- Redirect to another page: never (we leave the form values and the
button loading effect for the whole redirection duration)
- Redirect to an anchor on the same page: after the scroll animation
- Show a custom HTML message: never (this type of post-send action is
meant to hide the form after that message is shown, there is no need
to restore it to its initial state)
- "Nothing" (= small message next to send button): once the data is sent
In the last two cases, a 400ms delay was also added before showing the
message so that the send flickers less and seems more smooth. In the
last case, it also prevents to double click and double send the form.
Related to task-2172312
closesodoo/odoo#81703
X-original-commit: 42f6887bb4406d4aa636040c8325e8ecab202778
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The current user of the pos session is unable to close the session even if he is the one who opened it.
This commit allows the cashier to close the session if he is linked to the user that opened the POS session.
closesodoo/odoo#81696
Task-id: 2713876
X-original-commit: 3a27e73894e374ff30246c984ec85dc72f5e9b37
Signed-off-by: Masereel Pierre <pim@odoo.com>
It was no longer possible to favorite a product and the already
favorited products were not showing.
closesodoo/odoo#81692
Taskid: 2704569
X-original-commit: 328e0384cc2cff34fc5c4131014d94efb5747cb5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current registrations tests run with event_crm rules being activated. In
order to better highlight their impact (which is important) let us have
some tests skipping them.
Followup of odoo/odoo#81068
Task-2703289 (Event testing and coverage)
Preparing Task-2703285 (Event performance improvements)
closesodoo/odoo#81604
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The `_insert_followers` wasn't batch in the `create` of `mail.thread`
for no reason, which call the create of a `mail.follower` one by one.
It is inefficient for the batch records creation (import or some
flows) of a model with `_inherit = [mail.thread, ...]`.
Then batch it, to miminize the cost of `_insert_followers`:
The creation of 100 `mail.follower` takes:
- 0.107 sec if you create one by one (before)
- 0.022 sec if you create in batch (now)
Also add two tests (on model with a chatter):
- One testing the behavior of follower and subtype in case of
multi-create
- One testing the number of queries done to create 5 records.
The old SQL request count was 23, now it is 19 (-1 by create
call).
task-2711448
closesodoo/odoo#80954
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No notifications should be received whilst in Kiosk Mode.
closesodoo/odoo#81694
Taskid: 2704624
X-original-commit: 202a5a075b90a564d37c68d2f21f9c1edd8a7caf
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior to this commit:
- The employee was the first one returned through a search that
was not taking the company into account.
After this commit:
- The employee will be selected according to the company.
This issue arose with b5b105ea
closesodoo/odoo#81704
X-original-commit: 246caae0e70a8af0b507ba87921783a493c86064
Related: odoo/enterprise#23010
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In owl-2, t-on will no longer be supported on components. This commit
converts the code that used to rely on the datetime-changed event to use
a callback-prop based approach instead.
closesodoo/odoo#81199
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
IdentifyingFields and fields marked `required` must have their inverse
with `isCausal: true`. This led to having to systematically declare
inverses on the related models in order to explicitly add `isCausal:
true` to them, even when these inverses are not used for anything else.
This commit automatically adds `isCausal: true` to the inverses
generated by the framework when they are related to required fields or
identifyingFields. Thus, it is no longer necessary to declare inverses
if they are not used for anything else.
This commit also removes all the inverses that are no longer needed
thanks to this change.
closesodoo/odoo#81679
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When a user double clicks on a record in the kanban view of the form view of project a crash occurs.
This happens because there is an init which is called twice and during the second time the component created during the first click is destroyed and a DOM_updated event is still trigger which leads to a crash because in the case of project_form there is has a use of the element's dom which is then no longer available.
There is the same case in "FieldHtmlWithAction" and in "MassMailingFullWidthFormController"
The problem can be easily fixed by using on_attached_callback and on_detach_callback instead of setting a listener on DOM_updated in the init method.
opw-2685867
closesodoo/odoo#81680
X-original-commit: 8d83433d463dd3d1aef321921939962883f57d68
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
Current behavior:
When a user doesn't have any HR access right he cannot access his own profile
Steps to reproduce:
-Go to the demo user settings
-Remove all the right in the HR section
-Log into demo account
-Try to access My Profile
opw-2712593
closesodoo/odoo#81674
X-original-commit: ee932eab329043a3ddf82bb39dff458f4eb7f7ad
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Step to reproduce:
Try to print traceability report
Current Behaviour:
Traceback wrongly generated header
Behaviour after PR:
No Traceback, the header is now correctly generated
opw-2704299
closesodoo/odoo#81673
X-original-commit: 6b567326edc7bc691d87d911759ee30a24a8a1d7
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Before this commit, it was possible to drag and drop a popup inside an
oe_structure which was itself inside an other oe_structure (e.g. snippet
parallax). It didn't make sense and moreover created bugs.
After this commit, it is no longer possible to drag and drop the popup
snippet or the newsletter popup snippet in a substructure.
task-2491976
closesodoo/odoo#81669
X-original-commit: 49050c124795852ce7ad51b92958498972730dcf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
The tags management on an employee was limited to HR Administrator,
which didn't make sense as an HR Officer could manage the tags just not
assign them to an employee.
closesodoo/odoo#81654
Taskid: 2715498
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When pressing enter at the edge of an anchor that is a child of an
unbreakable element, we inserted line breaks in the anchor itself, which
is unexpected. This inserts the anchors after/before it instead.
closesodoo/odoo#81662
X-original-commit: df6f8dd0c54c40ea7edbd3821ae068d79b1b7af7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The snippet selection was lost on every action in mass mailing. The code
that prevents that was checking if the target of a click was the body
element but for mass mailing we needed to be a little bit more
restrictive since the editable area is not the body itself and we want
to actually prevent changing the snippet selection when the target is
the iframe target as well.
Since the mailing itself has a options, the sidebar is actually never
empty and therefore removing a snippet doesn't bring us back to the
block tab. Since therefore also ensures that we actually do.
task-2716397
X-original-commit: ecdb71bf6a566f5f6c294904e84f2132561dbb3c
Part-of: odoo/odoo#81662
Same issue as odoo/odoo#71068 but for subcontracting rather than a MO.
Steps to reproduce:
- create a subcontracted product w/tracked component
- create receipt with subcontracted product (don't forget to set
"Receive From" = subcontractor
- fill in Detailed Operations with tracked component lot/sn, but Done=0
- Try to record production
Expected Result: Subcontract production is done + window closes
Actual Result: nonsensical "The quantity to produce must be positive"
validation error
Discovered during task: 2695173
closesodoo/odoo#81649
X-original-commit: 646789811c1f874160318badfe8105d84057b8bd
Related: odoo/enterprise#22998
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Both mrp_subcontracting and a module in Enterprise both inherit
`mrp.mrp_production_form_view`. This was leading to a conflict where the
Enterprise view could overwrite the invisible=1 attribute added by
mrp_subcontracting, therefore we update the views to avoid this.
Part of Task: 2695173
ENT PR: odoo/enterprise#22637
X-original-commit: 6317c34808d381e54bae2431fec2de4b8503b447
Part-of: odoo/odoo#81649
Fixes 2 issues:
Issue 1: wrong view shown when registering strict consumption
To reproduce:
- create tracked product to subcontract
- create subcontract BoM with no tracked components + strict consumption
- create receipt of subcontracted product (remember to select From =
subcontractor)
- click on `action_show_details` burger button in Operations
Expected result:
- Detailed Operations window with no move lines in it (i.e.
stock.view_stock_move_nosuggest_operations view)
Actual Result:
- Detailed Operations window with move lines w/ 0 Done
(i.e. stock.view_stock_move_operations view _ lines also do
not get filled in when using the `action_assign_serial_show_details`,
=> twice as many lines as needed end up in view)i
Similar issue can occur when using a non-strict BoM + tracked product.
Issue appears to be that conditional was incorrectly updated during
refactoring to allow non-strict BoMs also record components.
stock.view_stock_move_operations view should only appear when all
productions are recorded
Issue 2: Consumption warning wizard not showing correctly
To reproduce:
- same as Issue 1, except consume less than BoM amount
Expected result: Consumption Wizard
Actual Result: stock move view shown instead
Issue was due to 'form_view_ref' value in context of picking view,
therefore we force clear this value everytime we expect this wizard
to open.
Task: 2695173
X-original-commit: b9990a5dab8731a8f69fd07aa73a318fc9d4a808
Part-of: odoo/odoo#81649
A horizontal padding was applied to each media list item, making it
impossible to make the media list items full width. Full width media
list items can always be reduced by adding padding in the editor, but
the converse is not true. For this reason, this commit applies
horizontal padding 0 to each media list item in the snippet template.
task-2716398
closesodoo/odoo#81637
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the cover snippet's image is in full width, we don't notice it's
not centered. But reduce its width and it appears at the left of its
container. There is no reasonable scenario in which this would be what
we expect so this commit centers that image by default.
task-2716399
Part-of: odoo/odoo#81637
The footer templates were using a font awesome icon for the copyright
sign, while it has a unicode equivalent, which is easier to edit and
lighter.
task-2716401
Part-of: odoo/odoo#81637
Have an MX database set up
Activate multicurrency (MXN and USD)
Have several rate for USD
- yesterday 0.047939098170
- today 0.048486729180
Make an invoice, dated yesterday for USD 116, tax 16% (cash basis)
Create a received payment dated today, for USD 116
Reconcile invoice and payment
Jounal items will be created for the invoice, for the exchange
difference and for the cash basis entries, but there are redundant
entries addressing the tax.
This occur because when reconciling the payment with the invoice the
system create the cash basis moves and reconcile them. During this inner
reconciliation exchange difference move are created (1) just for the tax
line.
Then the outer reconciliation flow continue and compute the exchange
difference moves, considering all cash basis items created before. A new
couple of journal items will be created to account for the difference in
tax, but this is redundant since it was already covered before (1)
opw-2685570
closesodoo/odoo#81624
X-original-commit: 03bf311bfde98f28a9b8e73953869a42b828c5e3
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this commit, when the redirection of a form was an anchor and
that anchor link came from the anchor option, the scroll animation was
not triggered.
task-2172312
closesodoo/odoo#81622
X-original-commit: 5db838cfc91d8438d6234df00bd8174768445974
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There were some issues when auto printing the receipt with images.
It could happen that the receipt was printed and the image were not yet visible.
To fix this, we make sure the image are rendered on the receipt before we print it.
closesodoo/odoo#81579
Ticket-id: 2688238
X-original-commit: 10d47ed2aee17f2a0d0b76c49c623fb3da4d5e30
Signed-off-by: Masereel Pierre <pim@odoo.com>
When a ticket was sent by email or printed, the qr code was not
visible. This was because it was not correctly put in the report and was
injected in the DOM throught the mounted of the component.
So we are now setting it in the qweb and prepare the values in
export_for_printing instead of inject it through the component that
display it.
closesodoo/odoo#81573
X-original-commit: 1ca12f15d39f9cda09fd1743184d64daf82adabc
Signed-off-by: Masereel Pierre <pim@odoo.com>
- Create a TAX A and TAX B
- Create a fiscal position, and TAX A in scr and TAX B in dest, and add other tax map
- Use this fiscal position in POS
- A month latter unactive TAX B (because the law have change).
--> You have an issue during opening the pos
closesodoo/odoo#81427
X-original-commit: 7471f13264d7002bd5570b5008565d3cc84042e6
Signed-off-by: Masereel Pierre <pim@odoo.com>
Expected behaviour
When having multiple promotions with, for example, a promotion of X% for the
first order and a promotion of Y% (Y<X), we should apply the first promotion
on the first order and then don't get this promotion into account to choose
the best promotion for a future order, so that we have:
1. A promotion of X% on the first order
2. A promotion of Y% on every other order
Observed behaviour
When trying to apply promotion on other order, nothing seems to happen, as
Odoo take the already-used X% promotion into account, being the most
interesting promotion, select it as the best promotion to apply and then
apply it to finally get a result of a 0% discount as the promotion has
already been used.
Problem Root Cause
As it can be seen in the commit, the error comes from the fact we filtered
the available promotion with a non-strict inequality.
Validation
A test has been added in test_program_numbers.py to validate our fix
Related issue
- opw-2674681
closesodoo/odoo#81633
X-original-commit: 9bade951570d79e2623d3bf548df445c22c31034
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
When the user has no rights on the Employee app, he can still
see the information on the employee public view
If the skills module is installed, there are add and remove buttons
displayed even in the absence of user rights.
Buttons should be hidden if the user has no rights to edit the
skills and resume
task-2702678
closesodoo/odoo#81617
X-original-commit: fd2f6e9586c5c853ba36d7ce511591574fac0bb2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
How to reproduce the bug:
- install l10n_de
- in Settings/General Settings/Business Documents, configure document
layout to DIN 5008
- try to print one of several:
=> timesheet entries
=> direct debit mandates
=> follow-up reports
Bug:
When you use the DIN 5008 report defined in l10n_de, the o variable is
defined which generates an error.
closesodoo/odoo#81505
Opw: 2659703,2699563,2649221
X-original-commit: c6ffe7eb65844dad33db4390ffeeb24d61a36f40
Signed-off-by: William André (wan) <wan@odoo.com>
We did not add the description of the invoice line on the print-out
of the invoice. (probably because description is not translatable
and the name of the product is)
If a product is set, the name of the product becomes the description (label)
on the invoice line, but of course this depends on the language.
So, we only add the description if it does not correspond
to either the English (/standard language) or Arabic product description.
(People can always add both languages in the same field)
Of course, if the product is not set, it will also just show the description (label).
Also put the : of the payment reference in Arabic on the other side.
closesodoo/odoo#81620
X-original-commit: 3485c7ad368d9c841d75a0b0614082b8989e2afc
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Thibault Delavallée