*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
This PR is mainly meant for the support.
Note that the `stack_info` is purposefully accessible to add some stack trace in the logs.
Example of support tickets where it can be useful:
A certain field of a particular model change it's value with no particular pattern and way to reproduce.
With this commit, we can now create an automated actions on the model update trigger to dump the current stack that will lead us on the action that did trigger it.
closesodoo/odoo#75320
Signed-off-by: Julien Castiaux <juc@odoo.com>
- sync both versions of the doc
- spellcheck/unify the wording, capitalization, etc.
- "Odoo" is not a person, and using it in documentation sentences is
generally redundant and weird, unless there is a real ambigiuty.
By default, it's clear that everything we're talking about is
Odoo-related.
Part-of: odoo/odoo#75320
Before this commit, the text of a `CopyClipboardButtonField` could be
edited with a `label` option. But this label was never translated.
After this commit, the field `string` is used instead to rename the
button. This is automatically exported for translatation.
task-3054813
closesodoo/odoo#105560
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Payment fees appeared as float (and not monetary) in the Payment
provider form and were not converted into the chosen payment
currency.
Some tests check the `_compute_fees` function.
task-2854143
closesodoo/odoo#100156
Related: odoo/upgrade#4106
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Commit [1] introduced the shape system. This system was able to chain
shapes depending on the shape of the previous sibling element.
Unfortunately, if the shape selected on the sibling was the last shape
available, clicking on the toggle shape button would result in nothing
happening.
This commit fixes that by defaulting to the first shape if no possible
shapes are given by the sibling.
[1]: https://github.com/odoo/odoo/commit/b84e0af742c51b88b4c108ebec2d0c7fff4b7483
opw-3082292
closesodoo/odoo#108017
X-original-commit: 9bdd8faea9f0126305856a40b3215589e6b3e610
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
This commit fixes a test using a different uom in lines than the
one in the product, a new compute function added in the
`choose.delivery.carrier` model revealed this.
closesodoo/odoo#96660
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previously, when adding shipment to sale order, the user did not know
the total weight of the order when getting rate of shipping method.
This commit shows the total order weight to the user with the ability to
set it to any value to get the rate with.
Taskid: 2797613
Part-of: odoo/odoo#96660
`sale` module uses custom field class to provide extra features. Particularly,
it makes product field clickable depending on SO status. However, this feature
doesn't work in Studio context. Specifically, parent record might be not
`Record` instance for `sale.order`, but `StaticList` instance for
`sale.order.line`, which doesn't have `isReadonly` method.
Fix it by that `isReadonly` is not `undefined`. We don't need to make product
field clickable in Studio anyway.
opw-3098768
opw-3099942
closesodoo/odoo#107902
X-original-commit: 06e7ccd2fab28b46eeec28029e51ae7312e66d71
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Text content of table buttons (move left, insert right, etc) are missing
the _t() in order to become translatable strings.
task# 3054440
closesodoo/odoo#107430
X-original-commit: 8856a6b55f4c9a0d68576439a06f3a957dcfabeb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The condition to visualize the payment status on the dashboard of account moves has been improved (this dashboard can be accessed by clicking on the Vendor Bill Journal and removing the filter for example). The reason for this change is that for a lot of different entries the payment status is indicated as "Not paid" even though no payment is expected for those entries. Moreover, this status will not change even though a payment is registered, which is counter intuitive (for payment line PBNK for example). This commit therefore improves the condition to visualize The payment status.
task-3091141
PR number-107329
closesodoo/odoo#107329
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Currently _compute_bulk_weight and _compute_weight are
going through each picking in self and each stock_move_line
in picking.move_line_ids to compute the pickings' weight.
This can be slow when there are lots of move_lines by pickings
as the field cache will be filled by the move_lines records
and uom._compute_quantity will be called once by move_line.
This is especially true for pickings with SN-tracked products.
For SN tracked products there will be one move_line by product_qty
(so a picking with 1 SN tracked product with a qty of 100 will have
100 move_lines). In this case doing a read_group yields the highest
speedup.
Following the same reasoning a search_count is done in _compute_packages
before retrieving package.move_line_ids.
When package.move_line_ids.result_package_id is empty doing a count
is much faster as it avoids calling _in_cache_without for the package
move_line_ids. The search_count overhead is negligeable in the other
case so adding it leads to an overall speedup on average.
opw-3017013
closesodoo/odoo#107994
X-original-commit: c95abbe8fa09decca2f94a035934e8d6ae7903e1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
Steps to reproduce:
- Go to Point of Sale app.
- Create a new order with many items in it (until you need to scroll).
- Go to Orders > Click on 'All active orders' and select 'Paid'.
- Scroll throught the items in the right.
Issue:
The total summary has a transparent background, so it will overlap with
the items inside the order and make less clear to visualize the total.
Solution:
Added the `background: inherit` to the `summary` class in the
pos.scss so we get the right background that we need for this view.
FW - port: master
opw-3093131
closesodoo/odoo#107993
X-original-commit: 3edd7f5cc425d991c512e278c22ee44043bc9d86
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Before this commit, there were two kind of related issues with the
AutoComplete component, involving an "Enter" keydown.
1) Click in an empty Autocomplete input s.t. the (only) source has
no option, then press "Enter" -> crash
2) Enter something in an Autocomplete input s.t. there are results
in the dropdown, then update the input again s.t. the (only)
source has no option, then press "Enter" -> crash
This commit fixes those two issues by
1) Ensuring that we don't store in the state an option index that's
out of range with respect to the current available options
2) Reseting the options when reloading the sources.
Those issues were reproducible on the Company form view, by using
the company name field (which uses partner_autocomplete).
closesodoo/odoo#107982
X-original-commit: 390a9b589495e67235b15137ccc510b76350443f
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
currently in the kanban view of the apps, the install button is renamed to activate from https://github.com/odoo/odoo/commit/c70984f4031612d64872fcc12e89c35f03e7d2b2 , but still in the form and action(in tree), button is still labelled as Install, so unifying the label of button to Activate in tree, form and action.
closesodoo/odoo#107907
X-original-commit: 26935d67e62649c10ed907e4a730b8f5ab1f127f
Signed-off-by: Julien Castiaux <juc@odoo.com>
Start a server without a -d and with a --dbfilter that allows for
multiple database. Make sure one of the database has the
`base_import_module` addon installed. Create an empty module using
scaffold and deploy it to the server, make sure to provide the `--db`
argument to the deploy command.
It zips the file and attempt to upload it but it fails for a 404 page
not found error.
The problem is that the controllers of base_import_module are only
accessible when the client is connected to a database. It must first
connect to a database (to have a db in his session) and then access the
controller.
The /web/login route is an example of a rather cheap route to get that
is both accessible without being connected to a database and that takes
a `?db=` argument to connect to one. Using that route, we can ensure
that we are connected to a database prior to uploading a module.
Closes#104589closesodoo/odoo#107906
X-original-commit: 8feb5f366255c8cb7927842acea3ec76bbe11df2
Signed-off-by: Julien Castiaux <juc@odoo.com>
Steps to reproduce:
- Create a price list with different currency and discount with "show price and discount to the customer"
- On the website select this pricelist and try to select the booth
Issue:
The displayed price will not be the correct one
Note:
This is an issue discovered during the correction of https://github.com/odoo/odoo/pull/101375 (forward-port of https://github.com/odoo/odoo/pull/85640)
It allows to have the correct price depending of the currency of the pricelist applied.
Now the unlink of the rate makes the new rate directlt effective. There is no need of having a `new_company` anymore.
Summary:
- view modification in `website_event_booth_sale` -> price of selected booth, simplification of comparison for the `<del>`
- view modification in `website_event_sale` : simplification of comparison for the `<del>`
- backend test modification in `website_event_[booth_]sale` common: addapt the rate; take out useless `new_env`; simplified pricelists creation
- tour test addition: added the tour for essential use cases in event and event_booth; simplified the command so it is more readable
related ticket:
opw-2766997
closesodoo/odoo#106593closesodoo/odoo#107768
X-original-commit: 43c9d9892f593a41c7fe139dada0ce3f79f6f287
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Create a price list with different currency and discount with "show price and discount to the customer"
- On the website select this pricelist and register for the event.
Issue:
The price in the cart is shown in the main currency
Solution:
[website_event_sale] There is an initial issue which when it calls '_compute_price_reduce'. We compare, 'product.lst_price' (in product.currency) and 'product.price' (which has been converted to the pricelist.currency).
In order to compare apples with apples, a conversion is applied to have the 'product.lst_price' in the same currency.
After that, we have kind of a coherent behaviour in the sense that 'ticket.price_reduce' is in the same currency as 'ticket.price'.
Thereafter, a conversion is applied (if the pricelist.currency is different) to get the expected amount.
The same reasoning is applied to [website_event_booth_sale].
Note: 'list_price' has been changed to 'lst_price' in Booth to have the same logic between Event and Booth
opw-2766997
X-original-commit: ced49554dd7cca73a1da440607d545bad64e7af0
Part-of: odoo/odoo#107768
This commit aims at:
1. Fixing a bug where the invoice would be uploaded in the wrong journal
------------------------------------------------------------------------
To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill
2. Letting the FacturX move type override the user-chosen move type
-------------------------------------------------------------------
Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.
3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication
----------------------------------------------------------------------------------------------------------
Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.
4. Adding a 4th button in the Documents app to create a Vendor refund
---------------------------------------------------------------------
Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.
5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view
----------------------------------------------------------------------------------------------------
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.
Task id 2961932
closesodoo/odoo#103427
Related: odoo/enterprise#32890
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
There is no debug icon in Discuss Public Page to show whether debug mode
is on or not.
After this commit:
Added a debug icon which will be visible when debug mode is on.
Task-2664824
closesodoo/odoo#97178
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit removes unnecessary spaces from the XML of the table of
content block.
Related to opw-3047375
Related to opw-3035502
task-2948895
closesodoo/odoo#107732
X-original-commit: 7ee4cc7d02158c63e6e2bd5eacc94371040872a8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the Bootstrap 5 merge, when there were several TOCs on the same
page the scrollSpy only worked for one of them. This commit fixes that.
Steps to reproduce the bug:
- Drop two TOC blocks on the same page
- Save the page
=> The second TOC is not working properly, it does not highlight the
current section.
Related to opw-3047375
Related to opw-3035502
task-2948895
X-original-commit: c182691bbfd6be8cc9aed26162635f5fdb117991
Part-of: odoo/odoo#107732
The table of content (TOC) has two mechanisms that interest us here:
The first one is scrollSpy (from Bootstrap) which allows (among other
things) to bold the menu elements according to the scroll. The second
one is a mutation observer which is implemented to regenerate the menu
when the content of the TOC changes.
This being said, when we edit the TOC and scroll at the same time, there
is a race condition that makes scrollSpy want to add a class to a menu
element while this menu has just been regenerated by the observer. The
error is only visible since the migration from Bootstrap 4 to Bootstrap
5 because to add the class, Bootstrap 4 did it with the jQuery
`addClass()` function which does not cause an error if the element on
which it is called does not exist. Now, Bootstrap 5 does the same thing
in pure JS with `classList.add()` which causes an error if the element
on which it is called is not defined. This commit fixes this error by
disposing the scrollSpy when the menu is regenerated.
Steps to reproduce the error:
- drop a table of content block
- drag a snippet around and go over the drop zones
=> traceback. It can appear directly or after some tries.
opw-3047375
opw-3035502
task-2948895
X-original-commit: a05f782871c61b2d58ca2fd4277cb7aed65a301d
Part-of: odoo/odoo#107732
Since [this commit], when dropping several "table of content" blocks on
the same page, it was impossible to save. This commit solves this
problem.
Steps to reproduce the resolved bug:
- In edit mode, drop two TOC blocks
- Click on Save
=> the UI is blocked
[this commit]: https://github.com/odoo/odoo/commit/06b03ba5ef8375b1236f6ecb52ac468124e910ba
Related to opw-3047375
Related to opw-3035502
task-2948895
X-original-commit: a6de596017cdbd0da10b4050da132d46dc82a491
Part-of: odoo/odoo#107732
When clicking on a star from the (3|5)-stars widgets, the stars light up
in yellow to reflect a rating. We weren't making a history step when
this happened, meaning that an undo or a rollback of anything that
happened just after clicking, would undo that rating change as well.
task-3084709
closesodoo/odoo#107669
X-original-commit: d4d592350e0b887cc10cc540ab3e5e1b20600946
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Odoo sh needs the update channel event to always come first.
This PR ensures it will always be the case.
closesodoo/odoo#107971
X-original-commit: 1f29e7bec160c1fa6930b3ee8b7753150253a7e2
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
row
When it comes to closing POS sessions, both the frontend and the backend
currently have some way to prevent the same operations from executing
simultaneously because of repeated clicks. `closeSession` in the
frontend has a `closeSessionClicked` boolean that prevents the operation
from triggering multiple times at once. `close_session_from_ui`
in the backend checks if the session state isn't already `closed`.
A flaw in the current logic is that
`update_closing_control_state_session`, which is called by the frontend
before `close_session_from_ui`, doesn't check the session state before
writing it to be `closing_control`. This means that if you time things
in such a way that the `closeSession` logic in the frontend triggers
again right after it finishes, it will call
`update_closing_control_state_session` and `close_session_from_ui`
again, which will happily close the session again, duplicating stock
moves and account moves resulting from it.
This fix has `update_closing_control_state_session` check if the session
is already closed and raises a UserError if so. This prevents the
duplicate closings and records from happening.
There were two variants in the UI I observed when the issue occurred:
the first is when the repeated execution of
`update_closing_control_state_session` and `close_session_from_ui`
successfully finished. In that case the session would be closed with
duplicate stock moves and journal entries.
In the second variant, from the repeated calls only
`update_closing_control_state_session` executed but not
`close_session_from_ui`. This could happen if the timing of the
frontend was such that it redirected to the POS dashboard before it was
able to call `close_session_from_ui`. In that case, the session would
be in the `closing_control` state, which is visible in the POS dashboard
. If the user then closed the session, it would be closed twice and the
duplicate records would again be created.
opw-2988701
closesodoo/odoo#107961
X-original-commit: 6b12c64e09c92fba96532658f959daf7d234223c
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit:
Emoji data are all in English. Unable to use in other languages.
After this commit:
Emoji names and keywords are translatable for search and display purposes.
Emoji category names are translateable for display.
Task-3043336
closesodoo/odoo#107941
X-original-commit: ee5e0a201fb1980c1745692d366fd8539815773e
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With the previous commit fixing the forced purchase_price recomputation
on all lines caused by the dependencies added by sale_stock_margin,
we can now safely allow manual edition of the cost.
closesodoo/odoo#107909
X-original-commit: 9c51daaa58c403778861ec484e0493698bacbc92
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- change the cost to $20
- product category > costing method > standard price
- Create a SO:
- Add the product “P1”
- Change the cost from $20 to $10
- Save
- Sent the quotation by Email
Problem:
The `purchase_price` is recomputed and changes back to the original value.
When the quotation is sent, the state of the order lines change,
marking the field `qty_delivered_method` to be recomputed, but also
other computed fields depending on it, including the purchase_price
(because of the dependency added in sale_timesheet_margin).
To avoid this unexpected recomputation, we remove the useless
dependency on the `state` for the field `qty_delivered_method`.
There is no reference/check on the state in the method
_compute_qty_delivered_method or any of its overrides and
therefore the field should not be necessary in the compute
dependencies.
opw-2994136
Fw-port of 296ec254b8ba88022fd15cabb0e44956163835fb to 16.0+
X-original-commit: 6f2faf5ccfca41c4e3d8b85105dd5bca5d031106
Part-of: odoo/odoo#107909
The cost (purchase_price) of a sale order line is recomputed when the
sale order is confirmed, overwriting the potentially edited value
Steps to reproduce:
1. Install sale_stock_margin module
2. Create a quotation, add any customer and two lines: a service (e.g.
Deposit) and any other storable product (e.g. Large Cabinet)
3. Activate 'Cost (purchase_price)' column in the order lines view
4. Edit the cost of Deposit and confirm the quotation
5. The cost resets to the original product cost
Solution:
Modify the dependency of `_compute_purchase_price` to trigger it only
when the sale order line's related picking has changed state
Problem:
The dependency on order_id.picking_ids.state makes it that the purchase
price is recomputed for all sale order lines when any of the picking of
the related sale order has a modified state (but we want to recompute it
only for the sale order line that had its picking's state modified)
opw-2904500
FW-port of 9947b617a15a340a6d8127250918d8ea06a5354e to 16.0+
X-original-commit: 5287c0851cf7b3432427af17d3cc59c19306c417
Part-of: odoo/odoo#107909
An act_url action in target "self" redirects the current window/tab
to the given url. It always reloads the page, except when only the
hash or query string changes.
This commit blocks the ui when the page reloads, because there's a
lack of feedback and interacting with the ui is unnecessary anyway.
For instance, module operations (install, remove and update) end
with page reload. During the operation, the ui is already blocked
because the operation takes time. After the operation and before
the page is actually reloaded, the ui is unblocked. As the reload
also takes time because of asset rebuilding, it makes false feeling
for the user that operation completes and interface is ready for
interaction. With this commit ui is blocked until the page is
reloaded.
closesodoo/odoo#107830
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
In some case, we want that chatter takes the all space
available.
Steps to reproduce:
- Go to Email Marketing
- Click on any record
- Go to the Chat tab
closesodoo/odoo#107928
X-original-commit: cbbbc23800e2a00aab9af45087b5d3f7698823d8
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
No view is available for the mobile form of change.password.wizard. The
default behavior of the framework is to generate one using the backend
model. This result on showing some hidden fields to the user, some of
them (like in this case `Wizard Id`) is impossible to fill in.
opw-3027797
closesodoo/odoo#107911
X-original-commit: 0860ba8538793c081358105238946ebc0d2015e5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before [1], the bus was started lazily: either as a consequence of
the addition of a channel to listen to or by manually calling the
`startPolling` method.
Before this commit, the websocket would have been started as soon as
the bus service starts which degrades performances.
This PR fixes the issue by re-introducing the same mechanism as before
that is by starting the websocket either by calling manually the `start`
method of the bus service or automatically when adding a channel.
[1]: odoo#75510
closesodoo/odoo#107878
X-original-commit: 5d7deacf54f37f0938b92a3c45c9f1d1325d1a9f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
The linked overtime record was not deleted when deleting a time off.
Meaning that those hours were lost.
task-3097259
closesodoo/odoo#107917
X-original-commit: 54cdc8435c28ecea253f61d5c8eeef317874456a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
add documentation link for adyen terminal in point of sale settings, similar to the other payment terminals
closesodoo/odoo#107900
Related: odoo/enterprise#34948
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit the canceled lines would not filter out from checks for completeness
of the statements and also the corrections in split wizard consider canceled lines as
real values. One of the results of this is when the user import statements with some
duplicate lines, the duplicates are canceled but the statement stays complete regardless
of the missing lines.
Also fixes the line date is not auto-filled when creating lines in the list view if they don't have a state
Closes PR #105708closesodoo/odoo#107894
X-original-commit: 2422b2c619209c1ff4171902dd2f90824194366d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Pouya Malekinejad (poma) <poma@odoo.com>
- On the settings view;
- Open the CRM settings;
- Click on "Update Probabilities" button;
- Change the "consider leads created as of the" date;
- Click on "Confirm" button;
Before this commit, the fields on the settings related to the dialog
were not updated. This occurs because, as the setting model is a
transient model, the settings view should always perform an onchange to
fetch the view, and it wasn't the case here.
Now, we patch the basic model used on the settings view to remove the
res_id, to consider the record always as new. This will always perform
an onchange to fetch the data. Note that, this hack is the same as it
was done before the owl migration.
opw-3073124
closesodoo/odoo#107879
X-original-commit: 792567c71aed626b5566f32b656104e3e70c496c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This revision is related to odoo/enterprise#33088
The needs is the same:
While using Studio,
instead of removing the node from the view
when the user is not part of the group,
set the node as invisible.
This is so the xpath expressions computed by Studio
takes into account nodes which are removed from the view
when the user is not part of the group required by the node.
e.g.
```xml
<form>
<group>
<field name="name"/>
<field name="currency_id" groups="base.group_multi_currency"/>
<field name="foo"/>
</group>
</form>
```
With the above view, if you want to add a new field after
`<field name="foo"`/>
and the `currency_id` field node is removed from the view
during the post-processing of the view
because the user doesn't have the group,
Studio computed the xpath expression with `field[2]`,
and then the new field was mis-placed,
it was before the `foo` field instead of after.
The strategy is to let the nodes, as invisible,
for which the user doesn't have the groups
so the xpath expression is correctly computed
for the view as it is stored in the database/
before the post-processing step removing the nodes.
The above revision applies this strategy for
nodes other than `<field/>` and `<t/>`.
The `<field>` were not included because it was,
at that time, believed it wasn't necessary.
Even though the index was wrong as demonstrated
in the above example, it was then converted
with the expression `field[@name="foo"]`
instead of `field[2]`, and therefore it was
fine not to include the `field` nodes
in the strategy.
Also, fields were not included in the strategy
because for them, if the `groups` is set
in the Python model
e.g.
```py
currency_id = fields.Many2one(..., groups='base.group_multi_currency')
```
Attempting to read them while you don't have the group
will lead to an AccessError exception.
And there was no way to display the field as invisible in the view
without the web client to try to read its content.
Unfortunately, it isn't the case,
as demonstrated by the tours included in this revision,
field nodes must be included in the views, as invisible,
so Studio can compute correctly the xpath expression.
This revision therefore aims to apply the same strategy
for `field` nodes, make them invisible instead of removing
them from the view when the user is not part of the groups.
The revision takes care to override the web client so it doesn't
try to read the value of group-protected fields when the user
doesn't have the group.
So the field, with the label and everything,
is included in the view, but its content/value is left empty,
as the user cannot read the content.
Technically, there won't be many cases, because
users editing views using Studio are admins,
and in most-cases admins have access to these group-protected fields.
Having a field group-protected to which the admins do not belong
doesn't happen that often.
closesodoo/odoo#107877
X-original-commit: 91f213e202ca29c4ef0bb190663fc48f169a64a6
Related: odoo/enterprise#34940
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Co-authored-by: kebeclibre <lpe@odoo.com>
The tooltip for the setting module_product_email_template refers to a setting in the Sales tab of the product, but this has been moved to the Accounting tab in v15. Due to stable policy, this is fixed in master
task-3095455
closesodoo/odoo#107634
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos,
l10n_sa_pos, pos_adyen, pos_discount, pos_epson_printer,
pos_epson_printer_restaurant, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_restaurant_adyen, pos_restaurant_stripe, pos_sale,
pos_sale_product_configurator, pos_six, pos_stripe
We are about to refactor most of the Javasript code base of the point of
sale and related modules. In doing so, we will move a lot of files and
modernize the entire code-base. In order to avoid diffcult rebases,
their conversion to odoo-modules is done as a first step to avoid
getting lots of conflicts on files that were unindented, which marks the
entire file as being in conflict. Conflicts will occur during forward
ports but they will be easier to manage as the changes will be much
smaller in scope, and the author will have the context of the change
that causes the conflict in mind when dealing with it.
closesodoo/odoo#107621
Related: odoo/enterprise#34910
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
In some cases, when billing a received quantity that is already
delivered, the account move lines of Stock Interim (Received) will
not be reconciled
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 5 x P at $50
4. Process the receipt R
5. Create and confirm a SO with
- 5 X P
6. Process the delivery
7. Create and post partial bill B01 related to PO:
- 1 x P @ $60
8. Accounting > Accounting > Journal Items
- Group By: Account
- Note: There are three lines in Stock Interim (Receipt):
- [AML01] Debit: 0, Credit: 250 (receipt R)
- [AML02] Debit: 60, Credit: 0 (bill B01)
- [AML03] Debit: 0, Credit: 10 (price diff from B01 because
quantity already delivered)
There is a partial reconcile between AML01 and AML02, AML03 is
not part of this partial reconciliation
9. Create and post partial bill B02 related to PO:
- 4 x P @ $60
10. Accounting > Accounting > Journal Items
- Group By: Account
Error: The lines of account 'Stock Interim (Received)' are not
reconciled while it should
When confirming B01, we try to reconcile AML01, AML02, AML03. In the
reconciliation process, we first sort the AMLs and try to create a
partial reconciliation:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2282-L2293
Because of the sorting, here is the order of the AMLs:
- [AML01] Debit: 0, Credit: 250
- [AML03] Debit: 0, Credit: 10
- [AML02] Debit: 60, Credit: 0
In `_create_reconciliation_partials`, we consume the AMLs in that
specific order. So, it first uses one credit line and a debit one:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L1863-L1872
(i.e. AML01 and AML02) and creates a partial reconciliation for
theses AMLs. It gives a temporary credit line of 190, but there is
no more debit lines, so the partial reconciliation is stopped (this
explains the note at step 8)
Later on, while posting B02, we try again to reconcile the lines of
Stock Interim (Received)
https://github.com/odoo/odoo/blob/493020b9317a439c0a61a34f37cc92b6779ef633/addons/stock_account/models/account_move.py#L249
At that point, we have three AMLs:
- [AML01] Debit: 0, Credit: 250 (same as above)
- [AML04] Debit: 0, Credit: 40 (price diff from B02)
- [AML05] Debit: 240, Credit: 0 (B02)
Back in the reconciliation progress, we try to get all involved AMLs:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2284-L2287
It will be used later for the full reconciliation. To get the
involved ones, we recursively get the AMLs implied in the partial
reconciliation of AML01, AML04, AML05:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2481-L2489
Therefore, because of the first partial reconciliation explained above,
we will find AML02 but not AML03. This is the reason why the full
reconciliation will not happen.
Working on the assumption that the note of step 8 is not a bug (i.e.,
AML03 is not expected to be part of the first partial reconciliation),
we need to provide as much AML as we can when calling the
reconciliation process.
OPW-3040171
closesodoo/odoo#107908
X-original-commit: 3050e23f94c865f9938863f191076f761b80fedb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Julien Castiaux