Test, don't merge (10.0 test update 20170413) - #793
Closed
StefanRijnhart wants to merge 1736 commits into
Closed
Conversation
- Create Product A with a BOM which depends on a product with tracking "By Unique Serial Number" (Product B). - Create a MO for Product A - In the "Register lots" wizard, add two lines for "Product B", with the same serial number. Nothing prevents the user to do it, even when the inventory is posted. opw-709888
We sometimes use in Odoo a One2many field with an inverse Integer
field instead of a usual Many2one.
This allow for example in several instances to have a "Many2one" which
can be reference from several models, eg:
Model Ranking:
name = String field
res_id = Integer field
res_model = String field
Model Toy:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Toy]
Model Tool:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Tool]
This enable us to have a shared feature between otherwise unrelated models.
But there was several issue when searching on these One2many:
1) if the Integer Many2one was not stored (eg. it came from an inherits) on
the searched model, this could lead to an error.
2) when we searched:
- by IDs (rank in ['55']) with at least one id not respecting the domain
- by IDs with a negative operator
- with a negative operator on unfound string (rank != "no rank has this")
- with a false value (rank = False)
we would not apply the One2many domain (eg. res_model == Toy) and thus
possibly getting Toy 3 errenously because a Tool 3 was found without
the domain being applied.
This fix modify the search on One2many and for:
1. if the inverse is an Integer not stored field instead of Many2one
manage it.
2. if the field is an Integer field instead of Many2one and there is a
domain on the One2many: apply the domain on the inverse model found.
So only some search on One2many with a domain whose inverse field is an
Integer could be impacted.
This would also be nice to have for all One2many with a domain but the
probability of it being useful versus risk for performance is not judged
high enough.
opw-710508
- Create a stockable product, create a SO selling 1 unit. - Confirm the SO, validate the Picking 1 => delivered qty is 1 - Return Picking 1 and validate Picking 2 => delivered qty is 1 - Return Picking 2 and validate Picking 3 => delivered qty is 2 The delivered quantity should remain 1. opw-715685
- Create a product with price tax included - Create Repair order - Add the product in tabs "Operation" or "Invoicing" The tax is added twice in the total. opw-709608
In some cases, the description fails (unknow printer, udev issues,...) and while the printer works fine, the description fails. This is a cherry pick of 994d45f to 8.0 (as the posbox is built on top of it)
It is still possible to have negative and positive quants in the same location because of returns: if you send something to the customer that is not there and you return it, you will still be able to reserve the returned goods to send to another client. Before, if you would do an inventory adjustment, it would not take into account these returned quants and their negative counterpart, which made them difficult to get out of the system. This fix takes them into account by creating two movements for one inventory line: move the positive counterpart to the inventory location before getting back from this location the same quantity. This way, even if you have 0 as quantity on hand but you have those 2 quants, it will eliminate them. (if you are increasing the stock, part of the process might have done it automatically already). Test cases contributed by @jir-odoo
The transcoder (which transforms stylesheet rules to inline style) did
some compression of the padding and margin css properties to not always
have margin-top + margin-right + margin-bottom + margin-left.
This could cause an issue when the value of margin or padding contained
an initial or inherit value because browsers (at least firefox and
google chrome) doesn't allow it. Thus the preview could for example have
bigger veritcal spaces arround `<p />` tag than what was seen when
editing.
With this fix instead of invalid:
margin:initial initial initial initial
we have:
margin:initial
And instead of invalid:
margin:initial 5px 6px 7px
we have:
margin-top: initial; margin-right: 5px; margin-bottom: 6px; margin-left: 7px;
opw-706535
Fullcalendar expect as `start` and `end` property of an event object: > When specifying Event Objects for events or eventSources, you may > specify a string in IETF format (ex: "Wed, 18 Oct 2009 13:00:00 EST"), > a string in ISO8601 format (ex: "2009-11-05T13:15:30Z") or a UNIX > timestamp. (as seen in https://fullcalendar.io/docs1/event_data/Event_Object/) Before this commit we could for example in arabic provide an invalid date string "٢٠١٧-٠٣-١٦ ١٦:٠٠:٠٦" instead of "2017-03-16 16:00:06". This commit solves this by always providing fullcalendar an ISO8601 date string. opw-705752
When using the iframed editor with multilang selector (present if there is another lang installed than en_US) an "English" language was present before each translation language. opw-696891
- Create an invoice with two products - Each line has a long description (spread on 2 lines) - The second line has a negative value - Print the invoice (PDF) The amount spreads on two lines, split as: $ - 1,000.00 This is due to the wkhtmltopdf version with patched QT. Unfortunately, upgrading to the latest version 0.12.4 doesn't solve the problem. The solution is to replace the '-' by a non-breakable hyphen. opw-711002
This commit partially reverts 5b4f7c1 where `fields_view.fields` had been replaced by `fields`, which could have been set to all fields in the model. This modification can sometimes lead to a problem, during the fields value transformation. The ID, which wasn't given previously is now parsed. When creating a new record, the field ID is not an integer but a string (representing the virtual ID). If the field is in the arch, it will be postprocessed (see https://github.com/odoo/odoo/blob/saas-11/addons/web/static/src/js/framework/data_manager.js#L201) and its type will become `id`. As this postprocessing is not done if the field in the view, the parsing was on the original type (integer) and not the special id type.
Commit 906875f (followed by commit 76be5ee) tried to tweak to copy/paste functionality of the editor. Indeed, in PDF file, when copying a paragraph, a line feed is added at each forced line break (page width end). This forced a line feed and a new paragraph in the pasted text. The goal was to get rid of those useless linebreaks when pasting. The ideal solution would be to detect that the text was copied from a PDF but it is not possible. However, this commit improves the heuristic: if this is not plain text, then nothing is done, the content is pasted normally. If it is plain text (like when copying from pdf), then each line break which is surrounded by letters or numbers is considered an useless line break and replaced by a space. This is obviously not perfect but the previous implementation was really wrong (it was removing line breaks which were not preceeded by punctuation in all cases, which was removing lots of useful line breaks). Note: this commit also fixes a bug -> text was not able to be pasted with Internet Explorer. opw-715920
The field email is no longer present on the crm.lead object opw-725112
- Define a user with accounting rights "Billing" - Create an invoice or vendor bill - Add an invoice line without product It is impossible to save because the mandatory field "Account" is hidden and empty. This is because of an onchange which overrides the default method. opw-716208
Steps to reproduce: -Create a new journal called VISA of type=bank -Allow the reconciliation on debit and credit account -Create two expenses (700$ each one)paid by company with the VISA journal -Submit to manager, validate and post the entries -Create a bank statement of -1400$ on Bank journal -Click on reconcile button Bug: the two account move lines linked to the expenses are not available to be reconciled with the statement. In 9.0, it was possible but due to this commit: 9188d01 the two aml were not available because this two aml had a payment_id, no statement_id and were with an account_id different of the bank journal (not in reconciliation_aml_accounts) because they had been paid with VISA journal. So they were rejected with the domain_reconciliation due to the account_id on VISA journal and they were rejected with the domain_matching due to the payment_id not False and statement_id False. In 9.0, they were accepted with the domain_matching so the same behavior has been done in saas-11. opw:709861
A recurring event with a start date and a time duration had a wrong start and stop date computed. Introduced at 76b7242. Previously the r_date contained only the start_date but now it contains both start and stop dates. This implies that the method 'get_recurrent_ids' could use 'get_search_fields' with a stop_date (depending on the domain order) and returns incorrect dates. This commit ensure to launch the get_search_fields with the start date. Closes #15922
- Create a PO, receive products (1.0 unit) - Create corresponding invoice, validate => Billed Qty = 1.0 - Refund invoice => Billed Qty = 2.0 opw-724474
In a form view, when a field onchange lead to a change on a x2many, there was two different behavior: - if the x2many had an embedded view (eg. a tree view inside a form view) the onchange would notify that it expected the x2many field in this embedded view to be changed and handled the changes correctly. - if the x2many had a default view, the onchange ORM would not be aware the x2many could be modified and would not sent the changes back causing blank or not updated x2m lines and error on save. --- Two solutions were birthed to solve the second point: => PR #10557 = solving everything With this PR the onchange in the ORM is aware of every fields in the current view (even field in a x2m in a x2m in a x2m in a form view) and if any of these are change the javascript gets back the value of the fields present in the view. This PR has currently not been merged by fear of changing too much and anyway could only be done in master. => PR #12249 = if no field for x2many, send its form view fields With this change, if the ORM onchange is not aware of the fields in the x2many widget to returns, all the field in the x2m default form view are returned. This was merged in bbdf960 but introduced a number of other issue: - in most situation the x2many is represented by a list view, which may have fields missing of the form view, so the original is still present. - the view used may differ from the default form view in other way (depending on value in context or other possibilities). - the form view could have fields not present in the form view which could end up in `write` on fields which should not be written to. --- This commit reverts bbdf960 and adapts a small part of #10557 so the x2many with default view works as an embedded x2many. For more than one level (eg. a x2many in a x2many) this would still not work but it is only solvable by a PR such as #10557 which could only be targetted for master. With this commit: - the list of fields sent to ORM onchange is computed at the first onchange - the fields from a x2many field default view is sent for onchange - the initial onchange on record creation is delayed to when x2many are loaded closes #12249, closes #15336, closes #15890 fixes #11236, fixes #12249, fixes #15129, #15419 opw-705965 opw-716095 opw-715619 opw-710440
In f65475d one2many fields of default view in a form view were propagated to the ORM so the value received from an onchange was not empty. These new steps test this on a tree view embedded in a form view, or a tree view originating from a default view by testing onchange adding row or updating values of a one2many.
In a form view, when a field onchange lead to a change on a x2many, there was two different behavior: - if the x2many had an embedded view (eg. a tree view inside a form view) the onchange would notify that it expected the x2many field in this embedded view to be changed and handled the changes correctly. - if the x2many had a default view, the onchange ORM would not be aware the x2many could be modified and would not sent the changes back causing blank or not updated x2m lines and error on save. --- Two solutions were birthed to solve the second point: => PR #10557 = solving everything With this PR the onchange in the ORM is aware of every fields in the current view (even field in a x2m in a x2m in a x2m in a form view) and if any of these are change the javascript gets back the value of the fields present in the view. This PR has currently not been merged by fear of changing too much and anyway could only be done in master. => PR #12249 = if no field for x2many, send its form view fields With this change, if the ORM onchange is not aware of the fields in the x2many widget to returns, all the field in the x2m default form view are returned. This was merged in bbdf960 but introduced a number of other issue: - in most situation the x2many is represented by a list view, which may have fields missing of the form view, so the original is still present. - the view used may differ from the default form view in other way (depending on value in context or other possibilities). - the form view could have fields not present in the form view which could end up in `write` on fields which should not be written to. --- This commit reverts bbdf960 and adapts a small part of #10557 so the x2many with default view works as an embedded x2many. For more than one level (eg. a x2many in a x2many) this would still not work but it is only solvable by a PR such as #10557 which could only be targetted for master. With this commit: - the list of fields sent to ORM onchange is computed at the first onchange - the fields from a x2many field default view is sent for onchange - the initial onchange on record creation is delayed to when x2many are loaded closes #12249, closes #15336, closes #15890 fixes #11236, fixes #12249, fixes #15129, #15419 opw-705965 opw-716095 opw-715619 opw-710440 note: already present in 10.0 (with a test) as f65475d
Done at #15929
Done at #15926
When the scheduler is run, the reordering rules of archived products are selected. opw-728316
Step to reproduce the bug: 1.Create a product with a customer tax(15%) for a price=100 2.Create a customer invoice with this product 3.Change the amount of the tax to 10(instead of 15) 4.Validate the invoice 5.Click on "Refund invoice" 6.Select the refund method "Modify: create refund, reconcile and create a new draft invoice" Bug the new draft invoice has 15 as amount of tax Now all the taxes from the invoice when preparing the refund in function _prepare_refund, in this it keeps all the modified taxes. opw:726491
Steps to reproduce:
-Create a product P with a standard price = 0 and its internal category
is in perpetual valuation
-Create a SO with an analytic account and a line with one product P
-Confirm the SO
-Create and validate the invoice
Bug: The delivered qty on the SO was equal to 2 instead of 1 because two
analytic lines are created by function create_analytic_lines with amount=0.
So in function _compute_analytic, the domain was [('so_line', 'in', self.ids), ('amount', '<=', 0.0)]
and it summed the two analytic lines for these two lines. Now analytic lines with amount=0 and linked
to a move line are summed if the they are linked to entries for an account of type "Expenses"(user_type_id).
opw:727302
We do not want to allow the change of a related config via a pos.order and in case the pos.order is done or invoiced we should not be able to change the user_id anymore and the fiscal position should never ever be changed after the order is not in draft anymore. User editable introduced at dca370d. Closes #16372
This is a backport of rev 3481f0f.
Typo error opw:728334
- Create 2 stockable products (A & B). - Sell these products in the POS, but leave the qty of Product A to zero. - Validate and pay - In the backend, return the products and register payment Two pickings are created, and one of them is empty. Products with a quantity of zero are not included in a picking. Therefore, we should ignore them when the pickings are created. Fixes #16292 opw-728101
The price of the product was not updated according to the pricelist when changing the qty of a product in the cart because the context of the product was not correctly set before calling function _get_display_price in _cart_update. But this part of code seems to be redundant with _website_product_id_change. opw:728312
- Create a product invoiced at delivery (A) - Create a SO with Product A, confirm => the invoicing status is "Nothing to invoice" - Create a down payment => the invoicing status is "To Invoice" Since the down payment is added as a product, its invoicing status influences the global invoicing status of the SO, while it shouldn't. opw-727936
Closes #16367 opw-728387
This allows to remove a custom model without checking all views.
This commit prevents from erasing the origin part of the url when the tour manager does a redirection. This was an issue in phantomjs if it allows local url as in this case, it will try to load file://<tour_url> instead of <origin><tour_url>.
Issue: when a field is computed on a new record, the record is not marked as "being computed", and it could therefore be invalidated. The fix consists in using the standard method that marks records before calling the compute method.
In 599bd50 for inline image in a mail the `Content-Id` of the attachment was used as the file name to avoir an issue of several inline images with the same name only displaying the first one. This solved the issue but with it the file name when downloading the image were lost as well as the extension which can be an issue. This changeset refactor the code so the behavior stay the same but the original file names are kept. opw-725305
Member
Author
|
Closing as tests have run (and pass). |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
This is a rebase of #789 onto #792 to see if tests stay green.