In Odoo 7.0 & 8.0, this was possible to translate
a field label, from `en_US` to `en_US`. It was
used as an easy way to change the fields label,
instead of creating an inherited view changing
the string attribute of the field everywhere it was needed.
This was no longer the case in 9.0,
following the revision 9593a29.
The translated terms for `en_US` have been
excluded, for performance reasons
as it was considered not possible to have
translated terms for the `en_US` language.
The fact is, this is very possible: Nothing
prevents to add a translated term
in `en_US` for a translate-able field,
as this is the case for the fields label,
as mentioned above. This field is then
used as the display value instead of the source
term when being in the `en_US` language.
Besides, the above revision was mainly to
give the possibility to sort a model records
on a translated field, using a join on the translations
table. It was then considered that the join could
be avoided, in the case where the user language was `en_US`,
for performance reasons, but, as this is possible
to give another value to the field value trough
the translations, it should actually be done, even
for the records sorting.
opw-670814
Test to bind save and discard buttons of an editable tree view are done
only once when initializing it.
But if the view is by default grouped at the beginning, it will be then
"not editable" but only removing the groupby will change this.
So this commit add a case so if the view is grouped when initialized,
the buttons are always bound.
closes#11198
opw-666794
In the POS we use a touchmove event listener to stop undesired
rubberbanding (in Chrome.disable_rubberbanding()). Elements which should
be scrollable by touch should have the touch-scrollable class. The
receipt screen is obviously one of those, because otherwise you won't be
able to scroll down if you have a long receipt.
opw-670899
When a bank account is set within another currency
than the company currency
(the currency of the journal is set and is different
than the company currency),
the balance displayed was the amount within the company
currency, instead of the amount within the bank account
currency (despite the fact the currency displayed
was the one of the journal).
opw-670815
Convert the domain to display only the sale / purchase
taxes in the taxes list to a default filter doing the same thing,
but which give the possibility to remove the filter
and see taxes with the scope `None`.
opw-670737
When printing a BOM structure using a variant,
the specifications of the variant were not
displayed in the BOM Structure lines,
making it different than what can be found
in the BOM structure form, and therefore
making it impossible to know which variant
has to be used for this BOM structure
from the report.
opw-670448
When printing the production order, the name
of the product did not include the variant
specifications, making it different then what
is displayed on the production order form,
and preventing to know which variant was produced
for this production order.
opw-670448
When the user converts the lead into an issue, an error occurs: "Form
view couldn't be loaded". This is because the web layer tries to refresh
the data related to a deleted record.
Instead of deleting the lead, we archive it.
opw-670259
When a lead/opportunity is created, the probability must match the
probability associated to the stage, as introduced in commit b2733391.
However, the call to `_get_default_stage_id` looses the context, which is
an issue since the method `stage_find` will inspect it in order to find
default values to build the search domain. The result is that the manual
call to `_get_default_stage_id` might return a different result than the
automatic call from `get_default`, and therefore the probability does not
match the stage
opw-669960
When the user click on save, 'is_valid' is called on each field.
The o2m test all sub-field (apply modifier and check value).
But, if a modifier change the read-only attribute, the field is reinitialized and call 'render_value' without check 'no_rerender' value.
The relational fields call the db in render_value, and the x2m is invalid because a request is pending.
(change X2ManyListView to keep the 'no_rerender' initial value)
opw-653120
Therefore, the template could be seen from
the Discuss module, when clicking on "Send Mail",
but, when attempting to use it, it failed
(as it was not applied on the right model).
opw-670546
When an analytic account is specified in the reconciliation, the
analytic lines are not created. This is because the account move is
posted before the account move lines are actually created.
Fixes#10951
opw-670110
In an environment where multiple database are available the company_logo
controller in the web module will return a placeholder logo (the Odoo
logo) if it can't figure out what db the request belongs to. This logo
is used on the ESC/POS receipts.
Because we load the logo with an anonymous CORS request there is no
authentication on the request. This is necessary because the POS tends
to not be served over HTTPS whereas the rest of Odoo is. Without this
crossOrigin attribute we could potentially end up in a situation where
the canvas is considered tainted by the browser which would prevent us
from extracting the canvas' data with toDataURL(). So removing the
crossOrigin attribute is not an option, specifying the db is the next
best thing.
opw-670471
note: in >=9.0 session is a variable defined in the js module instead of
a property on PosModel, so 'self.session.db' should become 'session.db'.
Moving a whole package (option "Allow moving packs") results in a
traceback. Indeed, the method `_get_all_products_quantities` returns
product ids, while `_create_extra_moves` expects browse records.
opw-668180
When counting the 'activities' on each opportunity/lead,
this view only considered messages with a subtype that
matched the subtype of a specific crm.activity.
This was not consistent with the crm.opportunity.report
which counted *all* messages on an opportunity as
"activitiy entries".
The latter is considered better because any entry,
(even automated one for tracking field value changes
or automated system responses) corresponds to an "action"
taken on that record.
This patch makes crm.activity.report consistent with
this decision: it will now count all messages.
+ also convert the incorrect `left join` to a plain
[inner] `join`, as we don't want deleted leads to
appear in case orphan messages were left around
(which should not happen anyway).
Using a subselect is more efficient than constructing
a complete temporary table of all messages, and then
joining them. This way only messages or relevant
opportunities are used, as most of the time the
report is accessed for a specific subset of opportunities
(by date, salesman, stage, etc.).
The query planner can then use the dedicated index
to quickly access the corresponding messages.
On a sample database with 1 million crm.lead
entries and 10 million mail.message entries
this brings the time for a typical read_group
call on crm.opportunity.report down from 300s to
500ms (600x faster)
Copy/paste mistake and the comma stays at the end of the line. This
causes a wrong affectation : indeed, `index_content` gets a tuple with
the desired value. This does not cause crashes, and the representation
of the tuple is correctly stored in database, but this is not the
expected behavior.
get_template should accept ids or xml ids. However the id or xml_id is given
to IrUiView.get_view_id that waits for an xml_id. get_template crashed if it
received an id.
This commit solves this by setting view_id to the given id, or resolve the xml_id
through get_view_id.
From issue 660592. (already fixed in v9) When products are received from a purchase line
with taxes included, the cost for the stock valuation (on the stock move) on reception
should be without these taxes included.
Checking url_list for duplicates is O(n).
Use url_set instead of url_list to improve to O(1).
Otherwise sitemap generation even for a million products will never finish.
Close#11106
This function is there to avoid creating link modules, it is extended
by account modules and should be called by methods that create invoices.
This call was missing in sale.
The function _set_additional_fields is used to avoid creating a ton
of auto-install modules; account extension extend this function and
modules that create invoices call it.
But when calling this function, it would be better not to overwrite
existing values; hence this check.
Been in there since the introduction of the module at 04fb3dfc. Didn't
really affect anything as long as you don't have developer tools open
while you're printing a ticket on the POSBox. This explains why it has
remained unnoticed for this long.
The `purchase_price` is filled in automatically thanks to the onchange
method `product_id_change_margin`. However, when a SO is created
programatically, it is necessary to call manually the method in order to
fill in the field. This is not convenient since the module sale_margin
might not be installed, and crappy workaround (such as the use of
`hasattr`) are necessary.
To avoid this, this fix automatically computes the purchase price at
creation if no value is provided.
In FF, there cannot be a clickable element inside a button tag. So the
tip on the icon in a button_box button was not able to be dismissed.
The tip selector is changed so that the highlighted element is the
button itself and not the icon it contains.
If an event is private, a bunch of fields
are hidden for the users not being
the owner of the event, even for sudo.
The fields on which depends the `rrule`
computation were part of the hidden/private
fields.
In addition, the `rrule` is always computed
as sudo. See `_get_rulestring`.
Therefore, the `rrule` of recurrent private events
was not correctly computed when the owner wasn't
the administrator.
opw-670295
Denis Ledoux
