When we compute the discount of a product to display (result of product_id_change), we compare prices in the currency of the product while we expect prices in the currency of the pricelist. opw 606188
In some rare cases database records have negative IDs,
so the slug URL could look like /foo--20. This could
be mistaken for a slug ending with a `-` and a positive ID.
The latter is not supposed to happned as final hyphens
are stripped by slugify, but has been used in the past
and may be used in old links.
Otherwise all templates are displayed and this will lead to some issues.
Also added a description on event.registration, because currently its
displayed name is Email Thread.
There is no reason to propagate the context in those buttons.
Besides, it leads to issues concerning the email template, rendering the wrong res_id because the active_id was wrongly propagated
tooltip stuck visible should be removed on click + remove tooltip container except for modal in order to prevent them for staying visible in some rare occasion
Sometimes, when you send an email in the chatter, a pop-up is displayed to fill the partner details
This case happens when the email address you send the email is not associated to an existing partner
In such cases, in lead, we use the company name and contact name to fill the partner name
During the conversion of account_invoice.py to the new API, the date_invoice written on the invoice has been moved in the end of the action_move_create method.
But, the method _get_analytic_lines needs it sooner.
When we duplicate a project, the related phases need to be duplicated as well but keeping references between each other.
e.g. 'project 1' with 'phase A' follwed by 'phase B' should become 'project 1 (copy)' with 'phase A (copy)' followed by 'phase B (copy)'.
Fixing bug lp:1212860, opw 607062
When we cancel a voucher, we may be trying to unlink a reconciliation that was already removed on another move (just looking at the version in cache). In such cases, the unlink would fail with traceback. opw 610287
In Settings > Sales, the onchange_timesheet ensure that if you check timesheet, it checks module_account_analytic_analysis.
Therefore, if module_account_analytic_analysis is installed, timesheet should be checked by default
Until now, it worked "luckily", because the onchange_timesheet of the field module_account_analytic_analysis was triggered before the onchange_timesheet of the timesheet field. Nevertheless, we shouldn't trust the onchange calls order.
* remove old 'day', 'month', 'field' and replace them by the actual
date/datetime field
* remove weird cast to char when creating the view to prevent crash
when grouping on them
* remove duplicates (such as 'creation_date' and 'create_date')
* fix typing errors (field type date defined as a datetime in the
postgres view)
* fix search view definition
opening_date and date_closed were cast to char but are supposed to be
dates. When you try to group crm_lead_report by one of them, postgres
was not happy. Now, it properly tells postgres that they are of type
date.
* add a 'total' foldable button to allow the user to control the column
in pivot table view
* in the dropdown menu, add all fields from the model instead of only
those from the search view groupbys
This was added in master-apiculture at f1f16a8 to
permit special function fields that return
structured JSON-like data.
This is unnecessary and caused typing problems, for
example for the type field of ir.model.fields, or
when you decide to store them.
It is simpler to explicitly declare these fields
as fields.Char and have them serialize their results
to JSON strings, or to declate them as fields.Binary
and return any opaque data they want.
function start, line 783, filters_ready waits for fields_view_get deferred to be resolved before calling prepare_filters, which prepare the view filters.
The thing is that, at line 416, if this.headless boolean is true, the searchview is marked as ready (by resolving the this.ready deferred), and the fields_view_get deferred will never be resolved, as it is resolved in the else case, where the this.headless boolean is false.
Therefore, in this.headless true case, this prevents the deferred $.when(this._super(), filters_ready) to be resolved, as the deferred filters_ready will never be resolved. Therefore, the deferred returned by the start function is never resolved, and the searchview will never be regarded as ready neither.
In views.js, the ViewManager is marked as ready when the deferred manager_ready = $.when(searchview_loaded, main_view_loaded, this.view_completely_inited) is resolved. In the this.headless true case, as the searchview is never marked as ready, the manager isn't neither.
This leaded to some issues, like the action buttons in form views being disabled on click, and never re-enabled once the action/wizard executed. See opw-610723
Users don't care for the backorder picking precisely because they can't process it, whereas they may have to do some more things on the picking they processed: invoice it, print delivery orders or transportation stickers..
Refresh the browse record after changing the name to avoid the need to rebrowse.
Fixes#1372
When creating a new message, we need to reset the default_type key to avoid context propagation (e.g. invoice menu).
However we used to compare the key in context (char) with the list of selections (tuple) so it was never matching and always reset.
In the Employee form, a remaining legal leaves field is available, which shows remaining validated leaves from allocation requests
As this is not allowed to delete a validated allocation requets, it shouldn't be possible to reduce the validated remaining leaves of an employee.
To reduce the remaining leaves of an employee, the user should cancel and remove the allocation request
- display_name uses name_get and not the other way around:
name_get should not call _compute_display_name, _compute_display_name should call name_get.
The previous behaviour was not backward-compatible with the old api.
All the models redefining name_get would have 2 different behaviors between name_get and display_name.
- Do not set an inverse function to display_name:
In most cases, writing on display_name writes on _rec_name (if any, not mandatory).
If the display_name computation is redefined, we need to redefine as well the inverse method to avoid unexpected behaviour
This required to also modify tests in base_import as readonly fields are avoided.
- Remove search method on display_name:
For the same reason as for the first point, it could be good that searching on display_name use name_search (and not the other way around).
However doing this would be very inefficiant (need to do the search, without limit, extract the ids of the name_get result just to generate
a subdomain ('id', 'in', [...]). As in most cases it would anyway mean to search on the _rec_name it's better to directly do so.
- Changing label to avoid mismatch:
In view displaying the list of fields or when a match is made on the label of a field (e.g. when importing csv file,
matching is made on both label and technical name), the fact that display_name field has '
Calling it 'Display Name' will avoid most errors.
- remove display_name definition from website_forum_doc,ir_model:
These fields are doing the same thing as the display_name of the new api, we can remove them.
We need to keep the one for res.partner as it's a stored field.
When searching on memberships, we use domain clauses in the format 'partner.x = y' where partner is a many2one to res.partner. The object res.partner has strict security rules for public users and this search will return zero result if not done with SUPERUSER_ID.
In addition, we need to access the list of products (membership_ids) in the domain to be sure we will retrieve only published membership (otherwise it would crash in the sort below).
The user_id is already set by the prepare_invoice method, which is called before the prepare_invoice_group (the user_id is already set, thus)
Besides, _prepare_invoice is overriden in sale_stock, to set the picking sale order salesman as user_id, and, without this correct, grouping invoicse by partner re-set the user_id to uid, which is wrong.
The state has been replaced by stage_id in the view, so the state is no longer used
Moreover, when doing an advanced search, the field state is visible and if used -> Traceback (because not available in the report sql table)
opw-609984
Due to the switch to Bootstrap 3.2 in this version, tooltip auto placement works erroneously (see https://github.com/twbs/bootstrap/issues/13897).
This is a workaround, waiting for a fix in Bootstrap assets.
(Closes#1341)
Purchase orders created with invoice policy 'Based on incoming shipments' were not keeping the reference to the account analytic distribution when invoiced. opw 607577
Databases with thousands of users would experience
poor performance during any change to a group during
an update/install, caused by the prefetching of
all database users when the browse cache contains
most of the groups in the system.
When a record is created, if it inherits from mail.thread, a message 'OBJECT created' is posted. 'created' is translated but the name of the model wasn't.
This fix uses the name of the linked ir.model which is already a translatable field.
lp:1262000, opw 611043
When generating reconciled moves in bank statement, use the amount_currency field instead of amount for currency conversion.
Otherwise we would endup with moves with an amount of 0.
Set the _rec_name for product.attribute.line model, as its column name wasn't defined, and therefore search on it wasn't possible (For instance, do an advanced search on product.product with "Product Attributes" "Contains" "Something" wasn't possible).
crm claims and helpdesk reports should be in Sales Report menu, not in project
The sales report menu is now defined in sales_team, which is a common dependance between crm and sales, instead of redefining this menu in each modules
The button should appear no matter the state of the sale order, to be consistent with the rest of the application.
This makes it much faster for the sales person to find out about orders in shipping exceptions or already processed.
Fixes#256
If somebody selects a delivery method not matching any criteria, the server would crash (500 for the user). This is due to error raised in get_price_from_picking which is triggered by the function field 'price' on the 'delivery.carrier' object.
To avoid this, add field 'available' on the carrier that will be False when no delivery gird is found or when the error is raised. In this case, the delivery choice is disabled. opw 610210
If an action unlink the current records (e.g. unreconcile on account.move.reconcile), trigger history_back to avoid errors when trying to reload inexistant record (opw 607883)
This is a partial backport of saas-4 code (rev c0db6ae, 162ad1c) and should not be forward ported.
When creating an invoice from a sale order, if the user choose to invoice a fixed price (deposit), he has the possibility to choose an advance product. As described in the help message, this product should be a service product. Therefore, we add a domain so only services are displayed in the dropdown list
If we try to generate twice entries on the same fiscal year, we can get completly unrelated errors ("You can only reconcile journal items with the same partner").
With this, we make sure people will first cancel the entries before regeneraing the entries.
Otherwise, active_id, active_ids, active_model params are propagated, and it leads to inconsistencies.
For instances, go to Sales > Customers, choose a customer which has quotations.
On the form, hit the "Quotations and sales" Button
Choose a quotation. Hit the "send by email" button.
The template preview should be displayed correctly. Now send the email, than
- Either, you have no traceback: The email sent is the email of another quotation, the quotation having as id the id of the partner you chose
- Either, you have a traceback: There is no quotation having as id the id of the partner you chose.
[FIX] product: user who don't use product variant can't edit the price of the product in product view. This behavior is not understandable. Add a function inverse to set the value (remove the variante price before change the list_price of the template)
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260