Purpose
=======
We want to clear the accounting access groups when only the Invoicing application is installed as follows:
If only Invoicing is installed, we should only have 2 groups: `Billing` and `Billing Manager`
If Accouting and Finance is installed, we should have the current groups: `Billing`, `Accountant` and `Advisor`
Specification
=============
1/ If we have only Invoicing the should have the following hierarchy:
group_account_manager (Billing Manager) ---Implies---> group_account_invoice (Billing)
group_account_user (Accountant) is a technical group out the Accouting groups hierarchy
2/ If we have Accouting and Finance installed, we should then have:
group_account_manager (Advisor) ---Implies---> group_account_user (Accountant) ---Implies---> group_account_invoice (Billing)
The reason we want to keep the group_account_user is that we will hide the accouting fields (account_id,...) with this group, allowing the consultants to show the accouting related information on support.
9a07a459 added "override=True" to silence a Sphinx warning in about
the address node already existing, however the override=True parameter
was added in Sphinx 1.4 (alongside the warning), so this breaks in
1.2.
Only pass in override=True if we're in 1.4 or later.
Closes#18232
There was a problem with the new `ajax.loadXML` implementation
introduced with 417a664f16
Indeed the following case was buggy:
```
ajax.loadXML('URL1', qweb);
ajax.loadXML().then(function () {
ajax.loadXML('URL2', qweb);
});
```
With this code, 'URL2' is scheduled to be loaded when 'URL1' is fully
loaded. The problem is that the deferred returned by the call to
`ajax.loadXML` without argument was resolved before the internal
`isLoading` variable was reset to `false`. So, the loading of 'URL2'
was indeed scheduled when 'URL1' was fully loaded but its loading
never started because the `ajax.loadXML` loading loop was still marked
as running (so it was not started again as it should have been).
When deciding to prefetch records (getting records from the cache with
no value for the field being fetched), if the field was computed
`determine_value` would just get all records, not limited by the normal
prefetch limit; for large recordsets this would generate gigantic
prefetch lists for records we may not need at all.
Fix by applying the `PREFETCH_MAX` limit to records from the cache as is
done in `_prefetch_field`.
Complementarily, when traversing related fields the prefetch
environment would be lost and every record would get an empty prefetch
environment, so the values would ultimately be read one by one.
Example: select (search) 1000 product.product records, access a
related field (e.g. categ_id) in a loop, on the first iteration the
system would first read 1000 templates, then it would read each
categ_id individually, resulting in >1000 SQL queries rather than the
~2 we would expect.
Fixes#18511
A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).
Commit 7cd2f6370 (in 10.0) recently added attribute special='cancel'
on the 'Cancel' buttons of the Settings views in Odoo. The attribute
wasn't really supported in this case by the old web framework, so
this commit also slightly adapted it, and made it reload the whole
webclient when such a button is clicked.
This commit now needs to be forwardported in saas-16, so we have to
handle the case in the new views as well. Before this rev., it
crashed, because the BasicModel tried to reload a new record (the
one of the Settings form view), so basically it performed a 'read'
RPC on a virtual ID like 'virtual_123', and the server didn't really
appreciate.
This rev. handles the case where a new record is reloaded, and
simply performs a 'default_get' instead of a read. Bonus point:
with the new views, we don't have to reload the whole webclient.
IE11 seems to be always using cache when doin an XHR request with the
same GET request.
It can be changed in several ways:
- returning a header: "Cache-Control: no-cache"
- altering the GET request with a nonce
- using the POST method instead of GET
to solve it, in this change the HTTP header is added on the response.
opw-752270
closes#18787
fixed cases:
1) having more than one account.move.line with a residual amount. This can easily be achieved by
-make a first invoice
-partially pay it
-make a second invoice
-partially pay it
-make a payment of the remaining amount
-reconcile the lines together
2) having more than one foreign currency involved, with several ecxhange difference to book
Purpose
=======
Issue: Product_id field should be visible only when product has more than one variant
Here's how it can be reproduced,
Assign user with group group_product_variant
Create a product without any variant
In this case, the product_id field won't be shown in product.template's internal form view for product.supplierinfo, that's working fine. But, now, as this fix is reverted, the product_id field will be visible in product.template's internal tree view for product.supplierinfo.
Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".
This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.
Computation of the field 'Difference amount' was wrong as it was converting amounts in base currency in the following use case:
- company currency USD
- invoice currency EUR
- payment's journal currency USD but payment's currency EUR
- invoice of 100€, payment of 20€: difference was not 80€ because it was converting to USD
*account_asset
When a button of type 'action' is clicked (execute a given action),
special keys must be set in the context (active_id, active_ids and
active_model). They must be computed regarding the record containing
the clicked button, i.e. if we are in a modal, it must be the id
and model of the record displayed in the modal.
Before this rev., we always sent the id and model of the record
displayed in the background (i.e. the id and model of the url).
This caused a bug in MRP that could be reproduced as follows:
- open a manufacturing order in form view
- click on edit
- click on one of the line of the one2many, and click on the green
icon to edit a product
- click on the update product quantity button on top of it
- the product field must be correctly filled, which was not the
case before this rev.
Date fields have magic grouping methods to specify how to group on
them like date:month, date:weeks, date:days for example. It needs
to be handled properly since date:month is not a valid field name
but date is.
Steps to reproduce the issue:
- Go to Sales/Dashboard
- Click on My Pipeline
- Group by "Creation Month"
Basically, this can be triggred from any view which has a search
view which defines a group using the magic date grouping methods.
Backport of 0de067cae9
(and 9b8bc5e5a1)
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
Adapt sale.order model in order to use the recently introduced portal
mixin :
* website_url field is replaced by portal_url field defined in portal
mixin; _compute_website_url is replaced by _compute_portal_url that
does basically the same computation;
* get_mail_url method used in emails now uses the get_share_url of
portal mixin;
This mixin holds the replacement for website_published.mixin
website_url field. This field is called portal_url to avoid confusion
with the website and enforce the new portal use.
It also contains get_share_url method that will be used to generate
the URL to use in emails or various communication for customers.
Purpose
=======
Terms are confusing in the deferred revenue app.
Specification
=============
- Rename label "Depreciation" -> "Revenue" in Deferred Revenue Lines wizard
- "Time method" in asset.categories shouldn't show "Number of Depreciation" but "Number of entries" instead
- In Customer Invoice visible field "Deferred Revenue Type" without developer mode
- All the menu related revenue will have same menu name "Deferred Revenues"
- Module name change to => "Deferred Revenues"
- Change module name : "Deferred revenue management for contracts" to "Deferred Revenues Management for Contracts"
- Change the label in time method 'Number of Depreciation' -> 'Number of entries'
- Also change the tooltip on Time Method
- Show Product(product.supplierinfo) field when product has more than one variants.
- Improve tooltip on Product(product.supplierinfo) and 'Cost'(product.template) fields.
- Hide 'Cost'(product.template) field when product has more than one variant
Purpose
=======
1. There is some confusion between the vendor price and the cost price of a product. The goal of this task is to clarify it for users.
2. Some users would like to set up vendor prices specific to a variant, the goal of this task is to allow them to do that.
Specification
=============
- Add a clear tooltip on the Cost field (standard_price) : "The cost price is used to valuate your inventory."
- When creating variants, it is impossible to set the cost of the product variant, it always resets to 0. It should be hidden if the product has some variants
- Add product_id o2m in vendors form, tree view on product template, and same field should be displayed on variant form view (the field is not required)
- Product_id field visible only when product has more than one variant
- Add a tooltip on this field : "If not set, the vendor price will apply to all variants of this products."
- Vendor price calculation for automated generated RFQ (should be based on sequence: take the first vendor price that matches all the conditions)
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
Yannick Tivisse