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.
Bootstrap handles the primary color in a different way than the other
colors. So to not break the backend UI, the o-create-color-classes
mixin has to consider this difference.
Notice that colors management should be further improved in the future.
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.
Allow users to define a percentage on shipping price, in order to cover
up differences between rating and shipping actual price.
Authors:
Barad Mahendra <mba@openerp.com>
Parth Mehta <pme@odoo.com>
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
Christophe Simonis