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
The alternate languages links set in the page `<head>`
were not translated in each language, but within the language
the user is browsing the website.
This leaded to SEO referencing issues, as these links leaded
to (30x) redirections if followed, to translate the URL slug
within the new current language.
e.g.
`/fr_FR/shop/product/bose-mini-bluetooth-speaker-7`
automatically redirected to
`/fr_FR/shop/product/mini-haut-parleur-bluetooth-bose-7`
And it was the first link which was displayed as alternate link
when being in another language than French, while it should
be the second (to avoid the useless redirection).
opw-669979
When we render the payment screen the current value of the current
paymentline is rendered to a string using
Paymentline.get_amount_str(). This conversion always rendered numbers
with a decimal separator of '.' because it just used
Number.toFixed(). This used to be fine but
5a10903e9b made the POS adhere to the set
decimal and thousands separator. Because of this, the POS now has to
parse the input with web.parse_value() which takes into account these
separators. When parse_value() parses a float it first deletes the
thousands separators and then replaces the decimal separator with '.'
before it gets cast to a Number.
In German (and other languages), the '.' is used as a thousands
separator which means that it will get deleted by parse_value() so
you'll end up with '12.34' being interpreted as '1234'. Because of this
it is important that we ensure that the default value that appears in
the input uses the correct separators.
The aforementioned issue only occurs when the user changes the default
value in the paymentline. Only then does a conversion take place from
String to Number. So just clicking on a payment method of type 'Bank'
and validating it would work fine, only when the payment amount was
updated would the issue occur.
Fixes#9395Closes#10952
note: this should not be forward-ported to >8.0 because later versions
use the rewritten payment screen which is completely different from the
one in 8.0.
When delivering a delivery order (`stock.picking.out`),
which generates accounting entries
e.g. thanks to the real-time stock valuation,
the date of the move set was the UTC today date, while it must
be the user's today date, using the timezone passed in the
context.
This prevented the delivery of the `stock.picking.out`
when the `Check date in period` boolean was checked
in the stock journal, and the user date is in the previous
month compared to the UTC date, as the date set on the move
entries were not in the selected period for these move entries.
e.g. When the user timezone is UTC -8, and his current time is
2016-02-29 18:00:00, the UTC date is 2016-03-01 02:00:00, the
period chosen is February (correct), but the date on the move
entries were set to 2016-03-01.
opw-670820
That will avoid to have the _logger.info at each print.
Now we fallback on lang of company and not en_US by default
If report lang was 'doc.partner_id.lang', we was looking for
lang code == 'doc.partner_id.lang'
instead of
code == eval('doc.partner_id.lang')
=> code == 'de_DE'.
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
The intrastat report period should match the accounting period of the
invoice. This might not be the case if the user manually chooses an
accounting period which does not match the invoice date.
opw-668827
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'.
Commit 516b1a6c72 fixes a bug with action buttons not being displayed when they
should in dialogs. However, it makes the assumption that either $node or
this.options.$buttons exist, which is not always the case (e.g. dashboard).
This rev. moves that logic out of the views to the view_manager, and protects
the call of empty() on this.options.$buttons.
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.
That way, we have only 2 ir.actions.todo executables on the common modules
(I don't count the configuration wizards in l10n_eu_service or oauth_ldap)
- 'base.open_menu' to jump on a frontend view
- 'theme_install_todo' to open the theme installation view
As the module website_theme_install is auto_install: True and so installed after
the modules like forum, slides, ..., the theme_install_todo is by accident
always the 1st chosen one, which was the wanted behavior.
NB: Remove the ldap wizard launcher
This makes it so people can pick one of the selected fiscal positions in
pos_config.fiscal_position_ids as their default fiscal position. When
creating a new order in the front- or backend the pos order will
automatically be assigned this default fiscal position.
Nicolas Martinelli
