Daily updates from Odoo
Navigate
Branch
Monday, November 4, 2019
35 changes
Enhancements to existing features
The product stock view now hides the Removal Date field when a product does not use expiration dates, reducing unnecessary information for users. The field is also optional, so users can hide it when it is not relevant to their work.
Original PR description
When user goes on product's quants, hides the "Removal Date" field if the product doesn't use expiration dates. Also, set it as optional to be hide if the user wants.
Resolved issues and error corrections
The stock app now allows module-related inventory records to be removed during uninstall, even when inventory adjustments are no longer in draft. This helps reinstall related apps with demo data and ensures databases can cleanly remove stock-related tables and records.
Original PR description
Business cases should not prevent the unlink of module-related records during an uninstall. This commit allows the reinstallation of sale_stock with demo data and also allows the proper removal of tables and records if a db has any non-draft inventory adjustments. Backportable (?)
Down payment lines are now placed at the end of sales orders instead of being mixed into long order lists. This makes them easier for sales teams and customers to find and review.
Original PR description
Task : https://www.odoo.com/web?#id=2025709&action=327&model=project.task&view_type=form&menu_id=4720 Pad : https://pad.odoo.com/p/r.7a2fcaa42e03926acc2ccd2491044a40 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A test for the Website Slides app was adjusted so it runs after installation rather than during setup. This prevents installation-time test issues and helps keep automated checks aligned with the expected process.
Original PR description
Since odoo/odoo@8d5da6e4be05 HttpCase should not be started at install.
This fix restores access to internal system utility functions that some parts of Odoo expected to be available automatically. It prevents failures during specific operations that could otherwise break only when those features are used.
Original PR description
Turns out almost no user of odoo.tools.osutil actually imports it. Following odoo/odoo#39573 (355e3609732bdc1ef0563edadb8634a322d7d5af) removing what were apparently the only two users of the submodule properly importing it, other calls to osutil features now blow up, which went unnoticed as these calls are lazy (so don't prevent starting the server) and only happen for very specific operations. The smallest change there is to simply re-enable the old behaviour by explicitly importing osutil from tools.__init__.
The WinBooks import tool now uses a supported temporary file method instead of a deprecated one. This keeps the import process compatible with recent Odoo platform changes and reduces the risk of future maintenance issues.
Original PR description
The function `odoo.tools.osutil.tempdir` has been deprecated with odoo/odoo@355e360973, the standard module `tempfile` can be used as a drop-in replacement.
Features or functions removed from Odoo
The Point of Sale setup removes its local PostgreSQL dependency from the POS box initialization and service startup flow. This simplifies deployment and maintenance of POS hardware by reducing bundled infrastructure requirements.
Original PR description
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/web?#id=1885478&action=333&active_id=1428&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.c56c0db6adaacd1765c04d84532802b7 Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The 'delivered quantity' field sometime needs to trigger a search on related objects (e.g. analytic lines) to know how much has been delivered. For performance reasons, this search is done using a read_group where the results are grouped by SO line. Unfortunately, this computation is sometimes launched during recomputes/onchanges where the line in question has a NewId instead of a regular id. This means that the mapping will return something like {240: 50.0} indicating that (e.g.
Original PR description
The 'delivered quantity' field sometime needs to trigger a search on related objects (e.g. analytic lines) to know how much has been delivered. For performance reasons, this search is done using a…
The 'delivered quantity' field sometime needs to trigger a search
on related objects (e.g. analytic lines) to know how much has been
delivered.
For performance reasons, this search is done using a read_group where
the results are grouped by SO line.
Unfortunately, this computation is sometimes launched during
recomputes/onchanges where the line in question has a NewId instead
of a regular id.
This means that the mapping will return something like
{240: 50.0}
indicating that (e.g.) there are 50 timesheet hours for the SO line
with id 240; unfortunately by doing
mapping.get(line.id, 0.0)
the NewId (240) is used - therefore returning a delivered quantity
of 0.0 for a line which has actual timesheets.
This commit ensures that if the line has a NewId and an original
underlying record, the id of the latter is used as the key to fetch
the value from the dict that contains the read_group result.
Note that the problem was quite tricky to reproduce as it depended
on the order of operations launched by triggers - the order of
operations was important since triggering the compute with the 'real'
record put things in order before any other piece of code could have
spotted the issue.
Forward-Port-Of: odoo/odoo#39778Business cases should not prevent the unlink of module-related records during an uninstall. This commit allows the reinstallation of sale_stock with demo data and also allows the proper removal of tables and records if a db has any non-draft inventory adjustments. Forward-Port-Of: odoo/odoo#39764
Original PR description
Business cases should not prevent the unlink of module-related records during an uninstall. This commit allows the reinstallation of sale_stock with demo data and also allows the proper removal of tables and records if a db has any non-draft inventory adjustments. Forward-Port-Of: odoo/odoo#39764
Forward-Port-Of: odoo/odoo#39751
Original PR description
Forward-Port-Of: odoo/odoo#39751
The extra informations not on the sale.order models were sent before 13.0 with the superuser user. In 13.0 with the change of `sudo` and `with_user` behavior, we were now in superuser mode but not with the superuser so the mail would error (no from address) and the sale order would error. With this changeset, we get back to the pre-13 behavior. opw-2116346 Forward-Port-Of: odoo/odoo#39730
Original PR description
The extra informations not on the sale.order models were sent before 13.0 with the superuser user. In 13.0 with the change of `sudo` and `with_user` behavior, we were now in superuser mode but not with the superuser so the mail would error (no from address) and the sale order would error. With this changeset, we get back to the pre-13 behavior. opw-2116346 Forward-Port-Of: odoo/odoo#39730
Before 13.0 .sudo() before sending a mail would send it as superuser user (which was the intention in this case), but since 13.0 for the same intention we need .with_user(SUPERUSER_ID). Without this change, the confirmation email on a sale order would have no sender ending up in failure. opw-2118612 Forward-Port-Of: odoo/odoo#39737
Original PR description
Before 13.0 .sudo() before sending a mail would send it as superuser user (which was the intention in this case), but since 13.0 for the same intention we need .with_user(SUPERUSER_ID). Without this change, the confirmation email on a sale order would have no sender ending up in failure. opw-2118612 Forward-Port-Of: odoo/odoo#39737
Before this rev, it crashed when opening the (sale or purchase) product matrix (e.g. on runbot, go to quotations, create, add a line, select 'My Company tshirt'). This was due to a recent override of _applyChanges (see 4bf98b47), which didn't return the value returned by super. OPW 2116083 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at
Original PR description
Before this rev, it crashed when opening the (sale or purchase) product matrix (e.g. on runbot, go to quotations, create, add a line, select 'My Company tshirt'). This was due to a recent override of _applyChanges (see 4bf98b47), which didn't return the value returned by super. OPW 2116083 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39717
In the contacts app, you can select 2 partners and merge them. Before this commit: - If a partner was added by a SQL query and not directly on Odoo, the create_date will be empty. This causes a crash because the merge wizard try to sort the partners by date After this commit: - If a partner do not have a create_date, it will be considered as 01/01/1970. The merge wizard will sort the partners by IDs too. OPW-2091925 Description of the issue/feature
Original PR description
In the contacts app, you can select 2 partners and merge them.
Before this commit:
- If a partner was added by a SQL query and not directly on Odoo,
the create_date will be empty. This causes a crash because the
merge wizard try to sort the partners by date
After this commit:
- If a partner do not have a create_date, it will be considered
as 01/01/1970. The merge wizard will sort the partners by IDs too.
OPW-2091925
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#39503Prior to this commit: b234e97f87c577a7cd85230c4f42277b39e8c842, uninvoiced orders' state is set to 'done' when the session is validated. However, this was not taken into consideration in the said commit such that even if the session is already validated, the uninvoiced orders' state remains 'paid'. Setting the orders state to 'done' is the correct behavior and is implemented in this commit. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa
Original PR description
Prior to this commit: b234e97f87c577a7cd85230c4f42277b39e8c842, uninvoiced orders' state is set to 'done' when the session is validated. However, this was not taken into consideration in the said commit such that even if the session is already validated, the uninvoiced orders' state remains 'paid'. Setting the orders state to 'done' is the correct behavior and is implemented in this commit. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39720
Hit by @Icallhimtest Apparently while Thread.join is signal-interruptible since 3.2, SIGXCPU is delivered to the thread which caused the limit to be hit (on linux, other systems may differ), and Python's redispatch to the main thread does *not* interrupt Thread.join to bouce the signal, leading to SIGXCPU being delivered as a side effect of an other interruption (or never). Blocking (pthread_sigmask) SIGXCPU on the worker thread seems to force delivery on the main thread fixing the issue.
Original PR description
Hit by @Icallhimtest Apparently while Thread.join is signal-interruptible since 3.2, SIGXCPU is delivered to the thread which caused the limit to be hit (on linux, other systems may differ), and…
Hit by @Icallhimtest Apparently while Thread.join is signal-interruptible since 3.2, SIGXCPU is delivered to the thread which caused the limit to be hit (on linux, other systems may differ), and Python's redispatch to the main thread does *not* interrupt Thread.join to bouce the signal, leading to SIGXCPU being delivered as a side effect of an other interruption (or never). Blocking (pthread_sigmask) SIGXCPU on the worker thread seems to force delivery on the main thread fixing the issue. We may also want to implement a busier loop of `while t.is_alive(): t.join(small_timeout)`? That would burn CPU but might be a good safety mechanism to ensure the main thread has a window to get bounced signals from the child. Also fix the thing so RLIMIT_CPU is again a per-request limit, I apparently missed that in 6ce2d6efb5b53451f369d544a31c36a024e0faf5 and probably over-recycled workers for people using the feature as a consequence. Configure other relevant signal handlers while at it: * block the signals for which there is a sensible handler set in the worker, they seem to work regardless (possibly because linux delivers process-targeted signals on the main thread by default? that means the sigxcpu issue could exist for e.g. sigquit on bsds?) but it should not hurt * unset / reset some of the handlers set in the server which are not sensible for workers (TERM and CHLD were already unset, but HUP, TTIN and TTOU make no sense either) Forward-Port-Of: odoo/odoo#39341
Make an invoice in Foreign Make a refund in Foreign reconcile the two, partially Make a payment in domestic, partial also, but with writeoff Before this commit, The invoice was not fully reconciled and -0.02 was yet to pay on it Notice the negativity of that number, which actually means that it HAS been fully reconciled !!!! (there is too much payment compared to invoiced) This was because, the account.payment in domestic currency is doing: Invoice residual in foreign, converted
Original PR description
Make an invoice in Foreign Make a refund in Foreign reconcile the two, partially Make a payment in domestic, partial also, but with writeoff Before this commit, The invoice was not fully reconciled…
Make an invoice in Foreign Make a refund in Foreign reconcile the two, partially Make a payment in domestic, partial also, but with writeoff Before this commit, The invoice was not fully reconciled and -0.02 was yet to pay on it Notice the negativity of that number, which actually means that it HAS been fully reconciled !!!! (there is too much payment compared to invoiced) This was because, the account.payment in domestic currency is doing: Invoice residual in foreign, converted to domestic Then that amount minus payment's amount gives write off amount in domestic Then, at reconciliation, the whole payment's amount, which is the payment + the writeoff contained the expected and mathematically correct conversion and currency rounding errors (which should make out the exchange difference) The exchange difference IS created, and rightfully too that is, it records the exchange difference as debit 0.01 in the receivable ! What was tricky though, is that the partial line recorded the debit 0.01 receivable as its CREDIT move line ! After this commit, the receivable line is recorded as the DEBIT move line of the partial between the payment and the invoice so the invoice, is fully paid. We keenly admit this is hackish, but justified: - business-wise: the rounding/exchange errors are appearing ex-post to the choice of the amount of the reconciliation between the payment and the invoice, because we are reconciling them on the domestic amount - technically: our hands are tied because some key information is not present every time, and weirdly, not symmetrically. That is, the computation of line.amount_residual[currency] may be different if your are on a line with a currency, or on a line that doesn't. We should really think of systematically putting the currency on the line whichever it is ! The same goes for partial reconciliation model ! Touching the current behavior is out of the question. Moreover, we should take into account that comparing amounts at different points in time should be done by actualizing those amounts to a common date See #39117 for details OPW 2057845 Forward-Port-Of: odoo/odoo#39685 Forward-Port-Of: odoo/odoo#39205
Usecase to reproduce: - Set warehouse as 3 steps delivery - On pack rule set the procure method as 'take from stock if enough or trigger another rule' - Do an inventory adjustement of a product and set 10 units in pack zone - Do a delivery order for this product with only 1 unit. It will create the delivery order from stock to pack even if the quantity in pack was sufficient. It's due to [1] that introduce a new function but if the force company and location (with an integer) are bo
Original PR description
Usecase to reproduce: - Set warehouse as 3 steps delivery - On pack rule set the procure method as 'take from stock if enough or trigger another rule' - Do an inventory adjustement of a product and set 10 units in pack zone - Do a delivery order for this product with only 1 unit. It will create the delivery order from stock to pack even if the quantity in pack was sufficient. It's due to [1] that introduce a new function but if the force company and location (with an integer) are both set in the domain it will select the wrong ids. It will take all the location in the company + the location in the context. However if a location is explicitly given to the context, it should only consider the stock at this location. [1] commit 330b99f60c0fcc09e2438a1958d11bf7e1383d8d opw-2090384 Forward-Port-Of: odoo/odoo#39644
Task: https://www.odoo.com/web?debug=1#id=2089999&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.983db9f60172075f542d1f9ee607e939 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39708
Original PR description
Task: https://www.odoo.com/web?debug=1#id=2089999&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.983db9f60172075f542d1f9ee607e939 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39708
* Reordering * Cleaning docstrings in doc and code * Removing deprecated/wrong stuff ... -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#36130
Original PR description
* Reordering * Cleaning docstrings in doc and code * Removing deprecated/wrong stuff ... -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#36130
Steps to reproduce the bug: - Let's consider Today = 31/10/2019 - Create a new hr.leave.type LT and set a validity from 01/01/2020 to 31/12/2020 - Set mode = Free Allocation Request and Validation = No Validation - Try to create leave allocations for LT Bug: It was impossible to create a leave allocation for LT because Today < 01/01/2020 So it was impossible to allocate future leave. We had to wait the 01/01/2020 to make the allocation of LT leaves opw:2092830 Forward-Port-Of: od
Original PR description
Steps to reproduce the bug: - Let's consider Today = 31/10/2019 - Create a new hr.leave.type LT and set a validity from 01/01/2020 to 31/12/2020 - Set mode = Free Allocation Request and Validation = No Validation - Try to create leave allocations for LT Bug: It was impossible to create a leave allocation for LT because Today < 01/01/2020 So it was impossible to allocate future leave. We had to wait the 01/01/2020 to make the allocation of LT leaves opw:2092830 Forward-Port-Of: odoo/odoo#39645
Steps to reproduce the bug: - Let's consider two storable products P1 and P2 - Update the cost of P2 to 10€ - Create a BOM for P1 with P2 as component - Click on Bom Structure & Cost - Click on P2 - Try to update the cost Bug: A traceback was raised saying that "Record does not exist or has been deleted" or the cost of an other product was displayed because the active_id was still the id of the bom. opw:2093199 Forward-Port-Of: odoo/odoo#39657
Original PR description
Steps to reproduce the bug: - Let's consider two storable products P1 and P2 - Update the cost of P2 to 10€ - Create a BOM for P1 with P2 as component - Click on Bom Structure & Cost - Click on P2 - Try to update the cost Bug: A traceback was raised saying that "Record does not exist or has been deleted" or the cost of an other product was displayed because the active_id was still the id of the bom. opw:2093199 Forward-Port-Of: odoo/odoo#39657
While the in / not in case will work, `is_false` also relies on equality to `TRUE_LEAF` and `FALSE_LEAF` to perform its inference. `TRUE_LEAF` and `FALSE_LEAF` are defined as tuples while RPC protocols don't have tuples and both JSON and XML-RPC will have domain segments as (python) lists. However, Python's tuples and lists *never compare equal*. So these two cases can never trigger on domains obtained over RPC, and thus it's likely many domains could shortcut but don't. Fix by having d
Original PR description
While the in / not in case will work, `is_false` also relies on equality to `TRUE_LEAF` and `FALSE_LEAF` to perform its inference. `TRUE_LEAF` and `FALSE_LEAF` are defined as tuples while RPC protocols don't have tuples and both JSON and XML-RPC will have domain segments as (python) lists. However, Python's tuples and lists *never compare equal*. So these two cases can never trigger on domains obtained over RPC, and thus it's likely many domains could shortcut but don't. Fix by having domain normalization also ensure all triplets are tuples: that's the first thing `is_false` does, it should never cause issues and could fix / improve / shortcut other routines. Forward-Port-Of: odoo/odoo#39684 Forward-Port-Of: odoo/odoo#39590
Activate Google Synchronization, create on GC a recurrent event, synchronize OE, then delete an event of the recursion on GC, sync again on OE. The event will be deleted from GC but not from OE after sync. The exclusion on OE is not correctly working in that particular case, fixing require also to "suppress" the attendee to avoid that just created exclusions would be detected as changes to send in a following synchronization. -- I confirm I have signed the CLA and read the PR guid
Original PR description
Activate Google Synchronization, create on GC a recurrent event, synchronize OE, then delete an event of the recursion on GC, sync again on OE. The event will be deleted from GC but not from OE after sync. The exclusion on OE is not correctly working in that particular case, fixing require also to "suppress" the attendee to avoid that just created exclusions would be detected as changes to send in a following synchronization. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#37884
Description of the issue/feature this PR addresses: Fixes https://github.com/odoo/odoo/issues/38340 and Followup on https://github.com/odoo/odoo/commit/9920f20e4c7753bc17bea71dea3a90f7de687196#diff-d9c980d61cddfd4f76333e7a5b92552bR204 Current behavior before PR: See https://github.com/odoo/odoo/issues/38340 Desired behavior after PR is merged: Correct Recomputation -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odo
Original PR description
Description of the issue/feature this PR addresses: Fixes https://github.com/odoo/odoo/issues/38340 and Followup on https://github.com/odoo/odoo/commit/9920f20e4c7753bc17bea71dea3a90f7de687196#diff-d9c980d61cddfd4f76333e7a5b92552bR204 Current behavior before PR: See https://github.com/odoo/odoo/issues/38340 Desired behavior after PR is merged: Correct Recomputation -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#38907
In form views, when the window size is too small, a "More" button appears and it should contain the overflow buttons. On all browsers, the "More" dropdown doesn't contain the expected amount of buttons, so it is shifted on the second line. Before this commit: - The "More" dropdown doesn't contain the expected amount of buttons, so it is shifted on the second line. After this commit: - The "More" dropdown contains the expected amount of buttons and it is not
Original PR description
In form views, when the window size is too small, a "More" button
appears and it should contain the overflow buttons.
On all browsers, the "More" dropdown doesn't contain the expected
amount of buttons, so it is shifted on the second line.
Before this commit:
- The "More" dropdown doesn't contain the expected amount of
buttons, so it is shifted on the second line.
After this commit:
- The "More" dropdown contains the expected amount of buttons
and it is not shifted on the second line anymore.
OPW-2079694
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#39380
Forward-Port-Of: odoo/odoo#38853Before this commit, the value in the EC sales list report was always 0. It was adding the balance of the move lines, and each move has two move lines one with an amount in the credit and one with an amount in the debit. Now, the value is the sum of the invoices (moves) opw-2081572 Forward-Port-Of: odoo/enterprise#6519
Original PR description
Before this commit, the value in the EC sales list report was always 0. It was adding the balance of the move lines, and each move has two move lines one with an amount in the credit and one with an amount in the debit. Now, the value is the sum of the invoices (moves) opw-2081572 Forward-Port-Of: odoo/enterprise#6519
**[IMP] Update default offers with newly matched product** Prior to this commit, if a synchronized SKU was found in an offer, the associated product was set to the sales order line in all cases. This lead to situations where the user would later set the corresponding SKU as internal reference of another product and expect the matching to happen but, as the offer was never updated, the default product was still linked to this SKU. This commit makes the search for a matching offer go through a
Original PR description
**[IMP] Update default offers with newly matched product** Prior to this commit, if a synchronized SKU was found in an offer, the associated product was set to the sales order line in all cases. This…
**[IMP] Update default offers with newly matched product** Prior to this commit, if a synchronized SKU was found in an offer, the associated product was set to the sales order line in all cases. This lead to situations where the user would later set the corresponding SKU as internal reference of another product and expect the matching to happen but, as the offer was never updated, the default product was still linked to this SKU. This commit makes the search for a matching offer go through all products again to find one with an internal reference matching the current SKU if the product currently associated with the offer is the default product. **[FIX] sale_amazon: display gift messages as notes on orders** As Amazon dropped the possibility (at least on the amazon.com marketplace) to choose paid gift wrappings for order items, causing gift messages to not display on sales orders anymore. This commit makes gift messages being displayed as notes on orders, whether the gift wrapping is charged or not. This allows to match a product with gift wrapping charges if any or to only display the gift message in the other case. **[FIX] Request TaxCloud to fetch taxes** Prior to this commit, TaxCloud never applied the right taxes on sales orders synchronized from Amazon as they were directly created either in the 'sale' or 'done' state, while TaxCloud is called in the 'action_confirm()' method. This commit adds a call to sale_account_taxcloud to trigger the fetching of the right taxes after the synchronization of an order from Amazon. **[FIX] Add company checks to amazon_account** Prior to this commit, it was possible to assign to an amazon account a salesperson, sales team or stock location with a different company than that of the amazon account, which later resulted in an error (depending of the field concerned). This is fixed by adding company_checks to all relational fields in amazon_account. Task ID: 2081012 Forward-Port-Of: odoo/enterprise#6461
This commit excludes section and note lines from the tax fetching performed by TaxCloud. task-2081012 Forward-Port-Of: odoo/enterprise#6488
Original PR description
This commit excludes section and note lines from the tax fetching performed by TaxCloud. task-2081012 Forward-Port-Of: odoo/enterprise#6488
This commit fixes 3 problems with the same solution: * In winbooks, there seems to be multiple savepoints depending on the local databases of different users. All these savepoints are saved in different filed. Before this commit, we tried to be smart about it and we tried to merge those files. * It seems you can have plugins for winbooks for some kind of control on the accounts. The parameters were stored in a file that matched the pattern we chose to find the files containing the char
Original PR description
This commit fixes 3 problems with the same solution: * In winbooks, there seems to be multiple savepoints depending on the local databases of different users. All these savepoints are saved in different filed. Before this commit, we tried to be smart about it and we tried to merge those files. * It seems you can have plugins for winbooks for some kind of control on the accounts. The parameters were stored in a file that matched the pattern we chose to find the files containing the chart of accounts. * It seems winbooks needs a file for migration of the account codes/names. This file was also taken in the pattern. The solution is to not trying to be smart anymore. It turns out there is not really a heuristic that could make this, so the import is only based on the "master" files, reducing the possible patterns. Forward-Port-Of: odoo/enterprise#6412
Given 2 simple models: user and company - Use Odoo Studio to customize the company model - Add 2 many2many relations between "company" and users, let's call those x_studio_employees and x_studio_managers - Switch to the ir.model.fields form view to edit those 2 fields modify the relation_table fields to: x_user_x_company_rel_employee and x_user_x_company_rel_manager - Export the customizations. The file `ir_model_fields.xml` doesn't contain `<field name="relation_table">` entrie
Original PR description
Given 2 simple models: user and company - Use Odoo Studio to customize the company model - Add 2 many2many relations between "company" and users, let's call those x_studio_employees and x_studio_managers - Switch to the ir.model.fields form view to edit those 2 fields modify the relation_table fields to: x_user_x_company_rel_employee and x_user_x_company_rel_manager - Export the customizations. The file `ir_model_fields.xml` doesn't contain `<field name="relation_table">` entries If the relation_table field is not saved, the imported customization links both employee and manager to the same list of users. OPW-2093824 Forward-Port-Of: odoo/enterprise#6538
Be in multi-company. Download an accounting tax report. If have only one company selected (who is not the default company), the report will display the information of the default company. It happens because the tax report doesn't have the multi_company option and there is now allowed_company_ids in the context. We set them in the context using the `cids` cookies so that the correct report is downloaded. This commit impacts all the reports who doesn't have the multi_company option.
Original PR description
Be in multi-company. Download an accounting tax report. If have only one company selected (who is not the default company), the report will display the information of the default company. It happens because the tax report doesn't have the multi_company option and there is now allowed_company_ids in the context. We set them in the context using the `cids` cookies so that the correct report is downloaded. This commit impacts all the reports who doesn't have the multi_company option. Related to task 2091557 OPW-2091214 Forward-Port-Of: odoo/enterprise#6503
Before this commit: - When you click on a relational field on mobile, you should be redirected to a kanban view with all entries but it shows only 320 of them. After this commit: - All the entries are available. This is only impacts the mobile version. OPW-2090181 Forward-Port-Of: odoo/enterprise#6508
Original PR description
Before this commit:
- When you click on a relational field on mobile, you should be
redirected to a kanban view with all entries but it shows only
320 of them.
After this commit:
- All the entries are available.
This is only impacts the mobile version.
OPW-2090181
Forward-Port-Of: odoo/enterprise#6508The `color` field never existed on `website.crm.score`. And there was no point on making the `group` invisible in cfcba7fd093922c10432c71. opw-2116108 Forward-Port-Of: odoo/enterprise#6526
Original PR description
The `color` field never existed on `website.crm.score`. And there was no point on making the `group` invisible in cfcba7fd093922c10432c71. opw-2116108 Forward-Port-Of: odoo/enterprise#6526
opw-2116827 Forward-Port-Of: odoo/enterprise#6520
Original PR description
opw-2116827 Forward-Port-Of: odoo/enterprise#6520