-
Notifications
You must be signed in to change notification settings - Fork 2
14.0 #12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
Behavior prior to this commit: When a PO is generated (via reordering rule, mto rule, or manual replenish), the description on the PO line includes the internal notes. Behavior after this commit: The description on the PO line does not include the internal notes. opw-24222438 closes odoo#63892 Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Reproduction step: - Create Sale Oder(Add optional product) - Customer Preview(portal) - Add to cart closes odoo#64317 Taskid: 2431351 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
From Invoice list view select 2+ invoices (A, B), click Action>send and print In each invoice 2 invoices will be sent: - In A, you'll find A and A - In B, you'll find A and B This occur because the composition_mode of the composer is computed after the attachment has been generated. When the composer has an attachment, it is included into the sent mail along the relevant one, generated on the fly for each record. opw-2428544 closes odoo#64360 Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Since 'move_line_ids' isn't inside the view, `account_type` is never computed and then, the accrual account is never displayed/editable on the view. closes odoo#64484 Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Steps to reproduce the bug: - Create a user with only access rights, Inventory = Administrator, Purchase = user - Enable feature Purchase order approval in Purchase > Settings - Agreement Type = Exclusive, lines of Agreement, Quantity of Agreement - Login as a new created user and navigate to a menu Purchase > Purchase agreement and create a new Purchase agreement, confirm it - From the button create two PO (having a total > 5000) - Cancel one of the PO first and try to approve another one Bug: A UserError was riased: You have to cancel or validate every RFQ before closing the purchase requisition. opw:2368999 closes odoo#64417 X-original-commit: dfee34b Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
This is mandatory for PA customers, and required by several enterprise customers as well. Related Ticket: 2425845 closes odoo#64434 X-original-commit: bb898e6 Signed-off-by: Josse Colpaert <jco@openerp.com> Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Do not update the date_planned of section/note purchase lines when the date is changed on the order. Based on f3ebab6 opw-2429853 closes odoo#64430 Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Consider a model with a field F and a computed editable field G that depends on F. Assume we open a form view, and both F and G have a default value. The first onchange should return F and G with their respective default values. In other words, the field G should not be recomputed even if its dependency F was assigned a default value. The use-case that showed the issue is batch payments. When adding a new payment in the one2many field of a batch, the new payment should use the batch's payment method by default. The default value for the payment's method is assigned by context on the one2many field in the view. Before this patch, the new payment's method was given by the computation of the field, and its default value was ignored. Side note: another test was fixed, but that's because the test was not consistent with the way Odoo 14.0 manages defaults and onchanges.
…text value This partially reverts commit 1ec887b, which was a hack to deal with the issue. From now on, the first call to onchange() no longer computes editable fields when they are given a default value.
task-2414811 closes odoo#63785 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps:
- Install website_sale and payment_authorize
- Set up a tunnel (e.g. ngrok)
- Log in to Authorize.Net backend
- Go to Account > Response/Receipt URLs > Add Url
- Enter the tunnel URL
- In Odoo, go to Website > Configuration > eCommerce > Payment Acquirers
- Edit "Authorize.Net"
- Credentials tab:
- State: Test Mode
- API Login Id, Transaction and Signature key
- Save, then Generate Client Key
- Configuration tab:
- Payment Flow: Payment from Odoo
- Stop the server
- Replace https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/payment_authorize/models/authorize_request.py#L46 with `resp = {'messages': {'resultCode': 'Error', 'message': [{'code': 'E00027', 'text': 'An error occurred during processing. Call Merchant Service Provider.'}]}}`
- Restart the server
- Go to "Website" > "Go to Website" > Shop
- Add a product to the basket
- Check out the basket
- Choose "Credit Card (powered by Authorize) Test Mode"
- Pay Now
- Enter any card data (e.g. 4111 1111 1111 1111 - 01/22 - 900)
Bug:
When the Pay Now process is done, the customer is redirected to
`/shop?error=invalid_token_id`. No errors are shown.
Explanation:
The patch simulates an error from Authorize.Net happening during their
process. Using the special card numbers won't trigger the wanted
behavior.
When getting an error from Authorize.net, a `UserError` is raised. This
error is then caught in the controller to return a formatted message.
However, returning a dict in this part of the code embeds it inside
`{'result': [...]}`. The error message is, thus, not blocking the form's
redirection and the user gets redirected to the form action, i.e.
`/shop/payment/token`. This route requires `pm_id`, but, in this
scenario, it's an empty string. This leads to another redirection to
`/shop/?error=invalid_token_id` as seen here:
https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/website_sale/controllers/main.py#L938-L941
Letting the error bubble up forces the backend to return a blocking
error response. This makes the fronted display the Authorize.Net error
underneath the provider selection, and prevents it from redirecting.
opw:2419260
closes odoo#64462
X-original-commit: c7a387b
Signed-off-by: backspac <backspac@users.noreply.github.com>
The picking_type and currency were taken from the current company, even if the purchase order is created in another company. Fixes odoo#35026 closes odoo#64469 X-original-commit: d080a5e Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The issue was triggered by the fact that editable fields are no longer computed when they have a default value. closes odoo#64359 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
…ing amount check for more advanced cases Reconciliation models can now create partial payment on invoices. Because of that, the default behavior is not anymore to fully pay the invoice and create an open balance write off. In some cases, though, this is what we want (exchange difference, ...). The solution for that is to create a reconciliation model with write off lines (telling it it must only apply if there is a 90% percent match on the amount, for example), and then create another one not checking the amount to just match the things to reconcile partially by using the partner. However, as it is now, reconciliation models always bypass the check made on the amount in case the statement line's label matches the invoice's payment reference exactly. This can lead to cases where we are matching elements we shouldn't with the rule doing the write off. Example: - use only two 'invoice matching' reconciliation models, in the following application sequence: - model 1, matching partner if with amount matching percentage is 90%, and doing a write-off for the unmatched amount - model 2, matching partner with no amount matching percentage, and no write off - create an invoice with payment refrence INV1 for partner A, amount: 100 - create an invoice with payment refernce INV2 for partner A, amount: 200 - create a statement with two lines: - line 1, with 99 for partner A, label= INV1. - line 2, with 1 for partner A, label= INV2. - Open the reconciliation widget ==> Before the fix: model 1 is applied on both statement lines, as their label match payment references. This is what we want for line 1, but probably not for line 2, which will create a write off of 199, while we'd have wished for a partial payment, leaving the invoice with 199 open. ==> After the fix The behavior is the same unless the config_parameter is set. If it is: - line 1 will be matched by model 1 (as 99 - 9,9 < 100 < 99 + 9,9). INV1 will be paid with a write off of 1. - line 2 will not be matched by model 1 (as 200 is not between 1 - 0,1 and 1 + 0,1), but it will be by model 2 (since line 2 and INV 2 share the same partner). So, INV2 will be partially reconciled with line 2. OPW 2419030 closes odoo#64409 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Summernote uses execCommand and, worth, obsolete queryCommandState function to customize the edited content. Here we try to hack the function to solve some problems by making the DOM and style easier to understand for the base functions for the duration of their executions. This won't obviously solves all problems but this is an improvement while waiting for the new Odoo editor coming in future versions. The original problem this solves is handling bold text in blog posts. Posts are using font-weight: 300 which is enough to confuse summernote. Hitting bold on a selected paragraph wraps its content in a <b> tag but hitting bold again does nothing... having a <b> rendered as fw-400 is enough to break it. What this commit does is: before any execCommand or queryCommandState being used to modify the DOM or retrieve its state, the whole DOM is forced to fw-400 and <b> elements to fw-700. This also solves issues in some base snippets. closes odoo#64472 X-original-commit: 424d966 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If a user has no access to Invoicing module, he can not send and print his invoices. To reproduce the error: (Need sale_management,account) 1. Connect with admin account 2. Settings > Users & Companies 3. Create/Edit a salesman - Remove access rights to Invoicing module 4. Connect with this user 5. Create & Confirm a SO 6. Edit the SO and fill in the "Delivered" field, Save 7. Click on "Create Invoice", "Create Invoice" 7. Connect with admin account 8. Invoicing > Go to the previously created invoice 9. Confirm it 10. Connect with the user account 11. Sales > previously created SO > "1 Invoices" => The user can read the invoice, but he can not send and print it. This is an error. OPW-2389428 closes odoo#62188 Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
When the name of a partner contains a regular expression operator, such
as grouping parenthesis, +, *, brackets... the resulting regexp may
match wrong names or worse be invalid and lead to an exception.
With this commit, we create a regular expression from only the words
formed from at least 3 of [a-zA-Z0-9], ignoring all other characters,
including those who may have a meaning in a regular expression.
This avoids these issues:
- regexp injection (security issue)
- punctuation resulting in erroneous regular expression ("ABC + SPRL"
resulted in "(?=.*ABC.*)(?=.*+.*)(?=.*SPRL.*)" which is invalid at
the ".*+" part)
- false positives due to words that are too small (\b were added, and
the minimal matching word size is 3)
- accentuation mismatch (both sides are filtered through unaccent)
- special cases in unicode that have a special behavior with lower().
See the discussion on odoo#63145 for a detailled explaination about
these issues.
OPW-2360687
Signed-off-by: wan <william-andre@users.noreply.github.com>
WHY: it's computed field that is not supposed to be editable. In previous task it was asked to make it visible, not editable. closes odoo#64521 Signed-off-by: William André (wan) <wan@odoo.com>
Allows customization for enterprise. Task ID: 2347640
Allows customization for enterprise. Task ID: 2347640
If an email was sent with empty "To:" and a proper alias in "CC:" (or any of the similar valid headers that conform the `rpc_tos_localparts` array), before 40ae36b the email wouldn't get rejected. After that commit it would get bounced. This comes from the not-so-obvious new python idiom used, `all()`. Check this out: ```python >>> all([False]) False >>> all([]) True ``` So, apart from the fix introduced in that commit, which seems valid, we have to make sure `email_to_localparts` actually has contents. Otherwise we are producing false bounces here. @Tecnativa TT23437 closes odoo#64522 X-original-commit: 8f094d3 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In order to clarify the purpose of the account_lock module, slightly update its description. Task id #2382740 closes odoo#63394 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Since odoo/enterprise@937b921 module 'studio_customization' has a dependency on module 'web_studio', in order to automatically remove customizations when uninstalling 'web_studio'. As a side effect, this marks 'studio_customization' to be upgraded when 'web_studio' is upgraded. An error is logged, but the module stays in state `to upgrade`, thereby blocking the execution of cron jobs. The fix simply adds an explicit (though not very elegant) condition on the module name to filter out module 'studio_customization' when marking modules in method `button_upgrade`. A cleaner fix would be to use the `imported` flag, but we don't want to risk breaking existing features in stable and will be done in master instead. Slightly linked to closed odoo#43880 closes odoo#64534 X-original-commit: 572e052 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This merge prepares the ground for the restoration of the "backbutton" support for OWL components in enterprise in odoo/enterprise#15731. Related to task ID: 2347640 closes odoo#64465 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Impacted versions : - 14.0 and higher Steps to reproduce : ``` 1. generate an odoo.exceptions.RedirectWarning 2. click on the primary button ``` Current behavior : ``` 1. the action (argument of the RedirectWarning) is properly executed 2. the WarningDialog is not closed ``` Expected behavior : ``` 1. the action should still be properly executed 2. the WarningDialog should be closed ``` Tests : Added a test to ensure this behavior will not be overwritten in the future. The test is for the CrashManager service, and evaluates the following sequence : ``` Entry: CrashManager receives a odoo.exceptions.RedirectWarning (code 200) via rpc_error Asserts: - The RedirectWarning modal (WarningDialog) should be opened * Upon clicking on the primary button : - The modal should be closed - The action passed as an argument of the odoo.exceptions.RedirectWarning should be executed ``` Origin : the incorrect behavior was introduced with : odoo@b3d9647 Task ID: 2430100 closes odoo#64290 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Forward port of tests only of odoo#64477 (12.0) since the fix was already applied in 14.0 with odoo#40336 opw-2423215 closes odoo#64539 X-original-commit: 761319a Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com> Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Before this commit, once a field has the 'forecast_widget', the user is
redirect to the forecast report also when they clicks on the field.
How to reproduce:
- Creates/Opens a delivery;
- In Operations list, clicks on the reserved qty. field of one of the
line -> It opens the forecast report.
The wanted behaviour is the user is redirected to the report only if
they clicks on the widget's button, not on the field itself.
task-2415918
closes odoo#63258
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
…cking system of account.move.line The tracking system causes some performances issues, this fix will allow to bypass the tracking for heavy tasks. closes odoo#64561 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, the invoice date wasn't shown on the invoice report. opw-2424608
opw-2424608 closes odoo#64564 Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce the bug: 1) Enable Paypal on the Payment Acquirers and select "BE Company CoA" on the company 2) fill the email and enable the "Add Extra Fees" 3) create an invoice on the company "BE Company CoA" 4) preview it as a public user Bug: An access error was raised: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records. opw:2439896 closes odoo#65460 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
WHY: PEC server rejects default addresses, so you cannot test connection --- opw-2371431 closes odoo#62312 Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Steps to reproduce the bug: - Accounting - Journal Entries - form view - Print - Invoices Bug: A UserError was raised 'Only invoices could be printed.' but in the attachment, the PDF was generated. opw:2452278 closes odoo#65488 X-original-commit: ba32244 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com> Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Follow-up of odoo#65357 closes odoo#65512 X-original-commit: 38e78a5 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> Signed-off-by: backspac <backspac@users.noreply.github.com>
In case of bad translation that doesn't contain the placeholder Context: A bad Japanese translation was inserted #. module: mail #: code:addons/mail/models/mail_thread.py:0 #, python-format msgid "Create new %(document)s" msgstr "新しい%(ドキュメント)を作成する" The translation has been corrected but use the 14.0 syntax of _ method to include placeholders and fallback on the English source term in case of bad translation cf odoo#52155 closes odoo#65517 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Previously, when removing all the content of a snippet, that snippet would get automatically deleted. This was not the case for parallax snippets because we previously intended the user to drop the parallax snippet, empty it, and drop other content inside of it. Recently, we added the parallax option on all snippets, rendering the previous workflow obsolete. There is now no longer any reason to keep empty parallax snippets. This commit fixes that. task-2446008 closes odoo#64907 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug: - Create a blogpost in the the blog 'travel - Archive the blog 'travel' - Open the blogpost Bug: A traceback was raised opw:2444406 closes odoo#65204 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Modify manually for the languages where the language is not on Transifex closes odoo#64557 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
closes odoo#65468 Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, it was not possible to center a button using the editor option 'align center'. It is because, using document.execCommand(), the Chrome browser doesnt want apply 'text-align: center' on nodes with centered children. And the buttons have the boostrap class '.btn' which adds text-align: center. So the hack here is disabling the text-align property from the '.btn' class during the execution of document.execCommand(). task-2423935 closes odoo#65544 X-original-commit: d4f38c3 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal of this commit is to add tips when theme is loaded to encourage users to follow the tour (in Edit mode). task-2440450 closes odoo#65153 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the page can be set in cache with some data pre-filled. Now we don't cache anymore the contactus page if you have GET params. closes odoo#65538 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
…ubscription
Currently, the subtype checked selection is not saved when the user adds and
removes subtypes. Indeed either an addition is performed, either a removal
but having both is not correctly taken into account when updating an existing
subscription.
How to reproduce
* click on the pencil icon to edit the subscription of the follower;
* as an example default "Discussions" will be the only one selected;
* check "Notes" and save;
* -> this works;
* click again on the pencil icon and uncheck "Notes" and check "Activities"
then save;
* -> this does not work as only removal is performed (Activities is not
checked);
The problem only occurs when you unchecked subtypes and checked other ones.
This commit fixes that behavior by taking into consideration both new
subtypes and subtypes to remove.
LINKS
Task ID-2205643
Task ID-2241688
COM PR odoo#56775
X-Original-Commit odoo/odoo@d16b036
closes odoo#65481
X-original-commit: 9df7ff5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Shahista Pathan <sat@odoo.com>
… same in customer This below case is not working before this commit: when Bill to Ship to where Delivery address partner is not registered and not have GSTIN closes odoo#65270 Signed-off-by: Josse Colpaert <jco@openerp.com>
When retrieving company dependant values, the computed domain called search_multi method of ir.property as normal user. Since odoo/odoo@8f578637076d4b65 ir.property records are no longer readable by a normal classical user. To reproduce: Add a domain using a company_dependant field e.g. on res.partner, with purchase installed, modify the parent_id field in form view to <field name="parent_id" ... domain="[('property_purchase_currency_id','=',property_purchase_currency_id)]" /> When clicking on the parent_id with a low priviledge user, an access-right error is raised, as the user doesn't have access to ir.property records Fixes odoo#65450 closes odoo#65552 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
…now allows OCR to run automatically. Before this commit, account_invoice_extract and account_edi where independent in parsing files uploaded or added as attachment in an invoice. Some tricks where used to avoid clash, but they were not perfect and some bugs appeared like the OCR not triggering automatically or an attachment being parsed twice by account_edi when parsing failed. The goal of this commit is to unify the import of files between the two features and ensure that they will not clash. For more information about potential problems that appeared before : See odoo#61169 See https://github.com/odoo/enterprise/pull/15124/ closes odoo#65510 Related: odoo/enterprise#16138 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Manual backport of odoo/odoo@36c78e3 Purpose of this commit is to avoid the use of sets in convert wizard. This set is used to compute ids of leads to merge and to convert. Using a set make order impossible to predict. Using lists allows to have reproducible tests notably. Spotted when working on task ID-2086889 Backported in Task ID-2451339
…d fields Add tests related to lead / partner contact fields synchronization. Add tests with user input and/or partner synchronization to ensure editable stored fields work as expected on lead model. Warning: those tests are failing. Next commit will split computed fields into several methods in order to fix computation. LINKS COM PR odoo#65381 Task ID-2451339
RATIONALE
Stored editable fields receive their values either from compute either from
user input. If a user input is given to create / write compute method is not
called. If multiple fields are computed through the same method giving one
field value discard call to compute method and other fields are not called.
SPECIFICATIONS
Split ``_compute_partner_id_values`` compute method so that partner related
fields are independent :
* have a method for address fields as those are computed in group. Indeed
either we take all from partner either none. Otherwise it would create mixed
addresses that make no sense;
* have a specific computation for partner_name and contact_name coming
from ``_prepare_partner_values``;
* have other fields separated (function, title, ...) acting like related on partner
if not set by user;
LINKS
COM PR odoo#65381
Task ID-2451339
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When syncing with a Google account, if user's email is different from Google account, the server creates a new partner. Moreover, the synced event are not linked to the current partner. To reproduce the error: 1. Have two Google accounts GA01 and GA02 2. With GA01, add an event to Google Calendar and add GA02 to guests 3. In Odoo, sync with Google Calendar using GA02 - The partner linked to the current Odoo user must have an email different from GA02's email Error: The calendar is synced, but the user needs to check "Everybody's calendars" to see the synced events. A new partner has been created using GA02's email. The synced events are linked to this new partner instead of current user's partner (`self.env.user.partner_id`). Moreover, Google event's organizer is always added to attendees but, if it this is indeed the case (so if the organizer is also an attendee), `google_event.attendees` already contains this organizer. OPW-2440033 closes odoo#65216 Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
task-2453463 closes odoo#65592 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps:
- Go to Inventory > Configuration > Warehouse Management / Operations
Types
- Edit Delivery Orders:
- Show Detailed Operations: Checked
- Go to Overview
- Create a new Delivery Order:
- Detailed Operations tab:
- Add a product (1)
- Operations tab:
- Add the same product (1) and make sure it has a description
- Save
Bug:
Traceback here:
https://github.com/odoo/odoo/blob/82b188a090aa34c258840343cbf594969489dd6b/addons/stock/models/stock_move.py#L807
TypeError: '<' not supported between instances of 'str' and 'bool'
Explanation:
A detailed operation has no description. Calling the description returns
`False`. When trying to save the delivery order with both detailed
operations and "normal" operations, the system tries to sort them out.
You cannot sort between different types (here, `str` and `bool`).
opw:2447720
closes odoo#65452
Signed-off-by: backspac <backspac@users.noreply.github.com>
closes odoo#65616 X-original-commit: 4a08c12 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Follow-up of odoo#64942 Explanation: When computing the total quantity, summing negative and positive values can sometimes lead to zero even if the scoped quantity is not zero. E.g.: Warehouse 1 has 10 items and Warehouse 2 has -10 items. Scoping on Warehouse 1 results in 10 items but the total quantity is 0. This commit also takes into account float precision. Inspired by: https://github.com/odoo/odoo/blob/d9b409247303c6b165a7df381169f2480a19900f/addons/stock_account/models/stock_quant.py#L36-L38 closes odoo#65609 Signed-off-by: backspac <backspac@users.noreply.github.com>
The Lesotho Loti has the symbol M and not L Example of use: http://lestimes.com/businessman-xie-in-m27-million-scandal/ http://lra.org.ls/sites/default/files/2020-10/LRA%20Integrated%20Annual%20Report%202019.pdf Fixes odoo#62807 closes odoo#65647 X-original-commit: f6b55a4 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
such fields have store=True, but they don't exist in table. --- odoo#65232 (comment) odoo@0241729 closes odoo#65665 X-original-commit: 2eee717 Signed-off-by: Raphael Collet (rco) <rco@openerp.com> Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When using command "6" (SET), the one2many field's inverse was not assigned on the lines. closes odoo#65656 X-original-commit: 330b885 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
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.
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