Syncing from upstream odoo/odoo (17.0) #34160
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…data In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect types linked to business code that should not be unlinked or changed from model. Introduce a generic way to mark some activity types as master data * model is fixed and should not be modified, because it is linked to specific flows e.g. todo should be generic; * data should not be unlinked, because it is used in automated flows like plans, business code, ... and cannot easily be replaced; Mail: make "Call", "Meeting" and "Todo" activity types master data users cannot remove as they are required in various flows: fleet, plans, voip, ... Also force their model to be False (aka be cross model). Mail: make "Warning" and "Upload document" activity types in addition to "Call" and "Todo", always cross model. As they are used in various apps it should not be specific to a model. Hr holidays: prevent from modifying leave activity types, as they are used in business flows and in automated code. Fleet: prevent from modifying contract activity type (same reason). Task-3777606 Part-of: #156731 Related: odoo/enterprise#58164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
When creating several activities linked to the same record you may encouter a crash due to several followers being inserted for the same record. Indeed everything is done at the same time and all data is not already flushed. It is actually better to uniquify list of records to subscribe, so that subscription is done once / user. Task-3777606 Part-of: #156731 Related: odoo/enterprise#58164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
When model does not match, raise a warning and fallback on default activity type. Task-3777606 Part-of: #156731 Related: odoo/enterprise#58164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Just make tests from 00f2a6a a bit clearer about expected behavior when creating with default activities in context. Task-3777606 Part-of: #156731 Related: odoo/enterprise#58164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Current event creation tries to create activities. However code coming from #72043 seems quite broken: it tries to find if the target model accepts activities, but does not by browsing the wrong model with wrong ids ... which globally turns off activity creation. This fix rewrites a bit code creating activities when creating an event so that * check activity support on the right model; * it uses the right model on activity type: otherwise you may end up with models that do not match between record and activity type; * remove useless (or wrong) code trying to browse 'model ids' on a given model; * we now correctly check for activity inheritance using 'is_mail_activity' field on IrModel; Task-3777606 Part-of: #156731 Related: odoo/enterprise#58164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Avoid calling '_sync_activities' when activities are anyway created directly from event itself. Task-3777606 Part-of: #156731 Related: odoo/enterprise#58164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect types linked to business code that should not be unlinked or changed from model. Introduce a generic way to mark some activity types as master data * model is fixed and should not be modified, because it is linked to specific flows e.g. todo should be generic; * data should not be unlinked, because it is used in automated flows like plans, business code, ... and cannot easily be replaced; Mail: make "Call", "Meeting" and "Todo" activity types master data users cannot remove as they are required in various flows: fleet, plans, voip, ... Also force their model to be False (aka be cross model). Mail: make "Warning" and "Upload document" activity types in addition to "Call" and "Todo", always cross model. As they are used in various apps it should not be specific to a model. Hr holidays: prevent from modifying leave activity types, as they are used in business flows and in automated code. Fleet: prevent from modifying contract activity type (same reason). Account Online Synchornization: make "Bank Synchronization" master data as business behavior dependso on it. Also fix model used for the type. Account reports: make "Tax Closing" master data as business flow depends on it. Approvals: make "Approval" master data as business flow depends on it and it is not easy to remove it in their usage. Hr Payroll: make "Leaves to defer" master data as business flow depends on it. Voip: make "Call" activity type master data users cannot remove as it is required in various flows of VOIP. Also force its model to be False as it is used in various models and should not suddenly be limited to a given model. Done in community, as activity is defined in 'mail'. Studio: make "Approval" master data as approval flow depends on it. Calendar: fix activities creation ========================= Current event creation tries to create activities. However code coming from #72043 seems quite broken: it tries to find if the target model accepts activities, but does not by browsing the wrong model with wrong ids ... which globally turns off activity creation. This fix rewrites a bit code creating activities when creating an event so that * check activity support on the right model; * it uses the right model on activity type: otherwise you may end up with models that do not match between record and activity type; * remove useless (or wrong) code trying to browse 'model ids' on a given model; * we now correctly check for activity inheritance using 'is_mail_activity' field on IrModel; Task-3777606 closes #156731 Related: odoo/enterprise#58164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Versions -------- - 17.0+ Steps ----- 1. Configure website to display prices tax-included; 2. disable selling out-of-stock products; 3. go to an out-of-stock product page; 4. request a reminder email; 5. replenish product stock; 6. run the `_send_availability_email` action; 7. check email that was sent. Issue ----- The price display in the email does not include taxes. Cause ----- The email only checks the `list_price` defined on the product. Solution -------- Don't include the price in the email: - On stable: hide the element to avoid breaking xpaths - On master: remove the element from the template opw-4712613 closes #215292 Signed-off-by: Levi Siuzdak <[email protected]>
Event with the document integration correctly setup, e-invoice xml generated in the send&print wizard will not create an associated document unless the attachment is actually sent via mail Steps to reproduce: - Have a EU Company setup - Enable and configure Peppol Electronic Invoicing - Enable documents integration with accounting - Create an invoice to a Peppol enabled customer, confirm - Open send&print wizard, enable only 'Download' and 'BIS Billing 3.0' Issue: Document related to the xml attachment is not created. This will work as expected when the message is sent to the customer opw-4720588 closes #216243 Related: odoo/enterprise#88746 Signed-off-by: Ruben Gomes (rugo) <[email protected]>
Before this commit: 1. Create an expense paid by company 2. Create an empty expense report (not through the expense form view) 3. Add the expense to the report (Updates the payment_method and payment_method_line_id but not the journal_id) 4. Try to move forward to create the move 5. Error (The selected payment method is not available for this payment, please select the payment method again.) After this commit: The right journal_id is set when adding an expense to an empty expense report. task-4804970 closes #211190 Signed-off-by: Julien Alardot (jual) <[email protected]>
**Problem:** when updating quantity of a product in company A from a user logged in on company B the svl are created with wrong values and standard price is incorrectly updated **Steps to reproduce:** - check two companies on the top right of the screen (comp A and comp B) - create a storable product with a avco category - make sure that the cost method of the category is avco both when logged in with company A and B (the cost method is company dependent) - while logged in with comp A create, confirm, receive and validate a PO for a quantity of 1 and a unit price of 100 - do the same while logged in with comp B but with a unit price of 10 - open the product form (cost should be 100 or 10 depending on the company) - while logged in on comp B click on the 'on hand' smart button - update from 1 to 2 the on hand quantity in the WH of comp A - switch to comp A and come back to prodcut form **Current behavior:** the standard price is 55. additionaly, when opening inventory/reporting/valuation and chossing the product we see that the svl created has a value of 55 **Expected behavior:** standard price should stay at 100 and the svl should be created with a value of 100 **Cause of the issue:** Product_price_udpate_before_done calls get_price_unit to compute the new standard price. https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L345 Inside get_price_unit, because the move has no unit_price we use self.product_id.standard_price which will take the standard price of comp B https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L59 opw-4852096 closes #217524 Signed-off-by: Tiffany Chang (tic) <[email protected]>
closes #217649 X-original-commit: 027d07d Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Josse Colpaert (jco) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
bt_gitbot