The action object, and in particular its context, is modified by the Action
Manager and by some views (e.g. sales_team_dashboard Kanban). So, as the action
is stored in cache, the same object was returned each time the action was
requested, and previous modifications of its context still applied.
This produced a bug with the sales_team_dashboard when following those steps:
- click on the link to today's activities, it opens an action with
'search_default_today' in the context,
- come back to the dashboard
- click on the link to this week's activities, it opens an action with
'search_default_this_week' in the context, but the formerly added key
'search_default_today' is still there as well, so the domain is wrong.
Context:
Source document on invoice created through a credit note with the modify option
Current issue:
create an invoice from a sale order,
validate it,
Create a refund with the modify option
The first invoice is reconciled with the refund
The new draft invoice doesn't have a source document and can't be reached from the SO
Expect result:
The new draft invoice should have the sale order as the source document
1/ On create new record focus field should select already existing value of field,
So user doesn't have to remove the old value first and then enter new value.
2/ Forget about it
This reverts commit c43a97f353.
If you use a setTimeout in your js code, you might want to have a
serious look at what you are doing. You are almost certainly doing it
wrong.
If you chain a deferred with the number returned from a setTimeout, you
definitely don't know what you are doing.
If you try to fix editable list view by magically adding timeout,
potentially inversing the order of execution, and without understanding
how deferred works, it is clear that you are just changing stuff until
your particular bug disappear in your particular case, and that you have
no idea what other bugs you just introduced.
Please study how deferred works, how the basic JS methods works, learn
what setTimeout returns. Also, you might want to have a basic
understanding of how and when expressions are evaluated. For example,
if you cannot explain why a if statement cannot be replaced by a
function, you might want to stop what you are doing and educate yourself.
Rev. 93e9a4dce7 tried to speed up
the 9.0 name_get() of res.partner by only calling fields_get()
once for the whole name_get, instead of calling it lazily.
This may have worked for name_get calls on multiple unnamed
addresses (name is NULL), but this is a rare occurrence
in practice - while now every single name_get() call would
incur the full cost of the fields_get() call.
That fields_get() call is O(n) in the number of fields,
and there can be quite a few for res.partner.
Calling it only for the specific 'type' field can easily be
about 40x faster than without it.
And since name_get() is called for each Many2One field
of each record being read (due to convert_to_read()), reading
a batch of records with partner fields had become quite
a bit slower!
Avoiding this cost entirely with lazy fields_get() calls
saves quite a lot of time for the common cases. And now
that fields_get() specifies a single field, it is cheap
enough to be called within the loop.
Non-scientific benchmark: account.invoice.search_read() in
the list view of invoices took 500ms for 25 invoices
_before_ this fix, and 90ms after!
HTML content should be escaped before being sanitized. Any content (link, image,
code,...) that is acceptable in usual mail.message but should not be interprated
when posted on a comment of the forum.
Fixes#3737
If we take the below facts:
- The country select is set as disabled
when Shipping is set to "Ship to the same address"
- The disable property of select inputs is
removed when shipping is set to
`create a new address`:
In `website_sale.js`:
```
$selects.attr("disabled", value <= 0 ? null : "disabled" ).prop("disabled", value <= 0 ? null : "disabled" );
```
We can safely assume that the select input "State / Province" was supposed
to be set as `disabled` in the first place, not as `readonly`
Before this revision, State / Provice was greyed when choosing
"Create a new address" for shipping, and selecting the United States
(but the select input was still usable, though, it was just greyed)
opw-675739
1/ On create new record focus field should select already existing value of field,
So user doesn't have to remove the old value first and then enter new value.
2/ Avoid the double empty line creation when pressing enter
step to produce
1 Menu Point of Sale > Configuration > Point of Sale switch to form view
2 Tick the box "Cash Control" , the one2many field will be visible
3 Press the "Tab" from keybord , control jumps to "Add an item" button
4 Press "Enter" from keyboad
5 You will see one extra line will be added..
because of a previous refactoring, the function send_notification stopped working
at all. It was not using the instance of the bus, but the module containing the
bus instance.
PURPOSE:
The source document should be in the chatter and clickable
NEW MAIL TEMPLATE:
mail: new template 'message_origin_link' with clickable link to origin
Variables to pass:
- origin: the record from which the current record had been created
- self: The current record
Optional:
- edit: If true, the record has been modified. Otherwise it has been created
from the origin
SPECIFICATION:
Source Document is available in following models
1) After creating SO then Sale to Invoice -> Source Document (After creating Sales Order and then clicking on Create invoice)
2) When procurement is created after SO or MO or Order Point(procurement.order) - > Source Document
3) Stock.picking -> Source Document ( After Creating SO or PO)
4) When Manufacturing Order is Created (mrp.production) -> Source Document (Coming after creating a sale order of product)
5) Event -> Attendees(event.registration) -> Source Document
6) Request For Quotation -> Source Document (After creating Purchase Tender, SO)
7) In Purchase Tender(purchase.requisition) -> Source Document (When a new Purchase Tender is Created)
8) After creating PO then create invoice(vendor bill)-> Source Document
9) After creating Invoice from contract (subscription) - > source Document.
10) Refund invoice from Invoice --> Source Document.
11) Return picking from picking --> Source Document.
12) sale use POS to create invoice and picking --> Source Document.
MESSAGES TO DISPLAY:
-In Customer Invoice, there is a source document of Sale Order.
"This Invoice has been created from Sale Order(s): SO001, SO002"
-In Procurement, the source document can be either of Sale Order or Manufacturing Order or Order Point.
"This procurement is created from: SO001 or MO0001 or OP/0001"
-In Stock Picking, the source document can be either of Sale Order or Purchase Order.
"This transfer has been created from sales order(s): SO001 or PO0001"
-Create new Sales order of manufactured product , there will be Source Document with that Sale Order number
"This production has been created from procurement(s): WH: Stock -> CustomersMTO"
-When registering for Event from website, Sale Order is Created and it is stored in Source Document,
"The attendee has been created from Sale order: SO001"
-In RFQ, the source document can be either Purchase Tender or Sale Order or Order Point,
"This purchase order has been created from purchase requisition(s): TE0001 or SO001 or OP/0001"
-In Purchase Tender, the source document can be either of Sale Order/ Manufacturing Order/ Order Point.
"This Purchase Requisition has been created from: WH: Stock -> CustomersMTO"
-In Vendor bill, there is a source document of Purchase Order.
"This Vendor bill has been created from Purchase Order(s): PO0001, PO002"
-When creating refund of invoice
"This customer invoices refund has been created from customer invoices: INV/2016/0001"
-when create invoice and picking form pos.
"This invoce has been create from point of sale: MainXX"
The field `bom_count` is added in the view for group `group_mrp_user`.
Therefore when extending the view, we should make sure to restrict the
access as well.
opw-679172
When the user visited a view for the second time, the extra actions in the sidebar
were broken. The reason is that the sidebar code modified in place the
fields_view information.
Note: This was not a problem before, because the field_view_get call was done each
time the view was loaded, but now it is cached.
* price_average is now always positive regardless of the invoice type, because it's an average and there's no point in summing those values
* price_total is now computed by using ABS() because of a migration bug of price_subtotal_signed introduced in saas-6, where in_invoice and in_refund invoices were set with a negative value while on the help tooltip it was saying that in/out refunds are negative and in/out invoices are positive. That bug was only revealed in v9 -since saas-6 wasn't using that field at all-, with the effect of having wrong values in report for migrated databases. This workaround using ABS() will be removed in a further version with a migration script to fix people's databases.
* residual field is now negative for in_invoices and out_refunds.
* These 2 points ensure that we can group by invoice type and sum the price_total or the residual fields to get the gross income of a month for example.
When event is created/finished/cancelled, event registration page shows same error message.
It shouldn't be same. So changed error message for finished/cancelled event.
Since the revision bc23c92c3e,
the inventory value of the produced items could
be doubled, because the list
`total_consume_moves` could contain several time
the same move ids, e.g. when it was added by
`total_consume_moves.append(raw_material_line.id)`
and
`total_consume_moves += already_consumed_lines.ids`
The list is replaced by a set to ensure a same move
cannot be counted twice.
opw-678727
Also:
- keeps unticked filters unticked when deleting a filter or adding a new one
- correctly tick filters when clicking on the partner's name (that code was
broken)
- remove reference to instance.web introduced by a forwardport
- wrong use of self in CalendarView's init()
When loading a calendar view with a partner_id in the context, the sidebar's
filters should be disabled by default to only display events related to that
partner.
Before this rev., the events were loaded twice:
- once with the date range as domain (and optionally the content of the search
view),
- once with the date range and the partner_ids of the sidebar's filters (and
content of search view).
The first loading was therefore useless, and might also be very costly.
When subscribing a user to a mailing list, the `mail.mass_mailing.contact`
created is processed to identify it's name and email from the address (method
`get_name_email` called in `add_to_list` and `name_create`).
For a better consistency, the search of existing contacts should also be done
using the method `get_name_email`.
This avoids that subscribing twice `Example <example@example.com>` fails to
detect duplicates and creates two subscriptions.
Closes#12265
When computing the amount_currency, the ratio is 1.0 if the difference
between amount(computed like this -sum([x.balance for x in move.line_ids]))
and the amount set in the statement is not greater than the currency rounding.
opw:678588
- Werkzeug's HTTPException are useful while dispatching HTTP requests,
in order to return a custom error page with an appropriate status
code. The http stack should let those exceptions bubble all the way up
and return the body of the exception as the HTTP response.
- openerp.http.AuthenticationError may be useful while dispatching JSON
requests, because the JSON error result will have error code 100
instead of the usual code 200, making it easy to distinguish
in simple JSON client code.
- Also slightly improved the fallback for unknown exceptions occurring
during "safe evaluation", to explicitly mention the original exception
type in the generic ValueError that gets raised.
Rev. 253437f81f meant to
avoid the creation of duplicate entries during translation
import, caused by existing translations created with an
empty `module` field.
But the fix was over-zealous and caused an extra side-effect:
the creation of missing translations (the blue flag icon)
now creates duplicate translations if other translations
exist with different `module` values.
(This could happen because translations are provided by
several modules, or due to manual translation entries with
no module value, etc.)
Aaron Bohy