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.
Sometimes, a default_get returns a create command for a one2many,
with a dict of values containing value 'false' for a many2one. This
is strictly equivalent to the case where the many2one field isn't
in the dict of values, but we have to handle both cases, and before
this rev., we only handled the latter one.
This happens for example in Sales > Leads (must be activated in the
Settings) > in the list view, check several leads > in 'Action',
click on 'Forward to Partner' > crash.
The value for one2many fields returned by default_get may be a
list of commands, or directly a list of ids. These cases were
correctly handled. However, it seems that the value can also be
false, and when this happened, it crashed. For instance, go to
Sales > Leads (must be activated in the Settings) > in the list
view, check several leads > in 'Action', click on 'Convert to
Opportunities' > crash.
Let's assume the following situation: we have a one2many field
displayed as a list in a form view. The list isn't editable, so
when a subrecord is clicked, it is opened in a form view in a
dialog. In this form view, there is a relational field X that is
not in the list. In the main form view, there is a field with an
onchange. When its value changes, the onchange returns a new
value for the one2many: a command 5 (delete all), and a command 0
(create) with a dict of values containing a value for X. However,
as X is unknown as long as no subrecord has been open in the dialog,
the value for X can't be processed (we don't know the type of X,
so we don't know how to process the value).
Before this rev., when this happened, we discarded the value of X.
This caused an issue for example in the Quotation form view (with
website_quote installed):
- create a new Quotation
- set PartnerShip Contract as quotation template -> the onchange
returns two 'create' commands for the order_line one2many
- click on one of the two subrecords in the one2many -> error.
This rev. ensures to keep changes on unknown fields. We keep them
unprocessed, and once the form view is opened, we process and
apply them.
Since the revenue computation is an automatic system
action, it should be done in sudo(). This avoid access
error.
Indeed, if a company creates and confirms a SO, a task
can be created in another company project. Logging
timesheet from the project company is thus impossible
since the user can not access SO line of the origin
company.
Adding sudo() seems better than givin read access
to 'all' so line for timesheet user.
It happens because the function still use the old fields
utilized before refactoring introduced by commit b3180c8411
This commit adapt the function by using quantity instead of qty.
partner_id was either a recordset (in create mode), either an id (in edit more)
in the `_checkout_form_save` method.
An id is expected as the result is used in the ORM method (4, partner_id)
Closes#18533
Fine tuning of this commit: b795d69ce8
Steps to reproduce the bug:
Leaves > List view > Go into any validated leave > Get Odoo Server Error on access rights
opw:693536
Custom fields are duplicated because the cache of method `_existing_field_data`
is invalid at the time the model is reflected: it does not contain the field
that has just been created. Simply clear the method caches before reflecting
models and fields.
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
Yannick Tivisse