The `geoip` is not always defined in the session,
and therefore one needs to check it's defined before
attempting to use it.
The same is done at different places in the code,
through the different modules.
opw-687783
It was doing something before but the useful line was removed at 908f4165
The method is no longer useful and can be removed.
It was error prone has it had not the same signature as the one on project.
Fixes#13402
If your create an order in backend and you make payements, they remain opened while the POS session isn't closed, which may seens counter-intuitive. The payment in taken into account afterward and the reconciliation is made with the invoice (if applicable)
We shouldn't let people create POS orders from backend. And while we're at it, we should do the same with sessions. They're opened and closed from the dashboard.
Without the @api.multi property,
the method is considered as taking only one parameter (self?),
while it takes multiple parameters.
This prevented to change the quote template on a sale order,
if the quote template had some order lines, due to the below error
`TypeError: product_id_change() takes exactly 1 argument (19 given)`
opw-687797
Commit f30ec302 defines the messages sent thanks to the channels as
plain text. This is true for all cases but one: the notification
(e.g. @user). Therefore, the notifications links are broken.
opw-687781
From Odoo 9.0, en_US is not always activated in Odoo. As a fallback, if
the search for a language does not find company language nor English US,
we use the first available language (there is always at least one).
In order to reproduce this behavior, eg: you can set the language of
your company's partner to en_US, then load another language, then
disable en_US from your database. Try to open the "Accounting" dashboard
and you will get a traceback.
There already is a redirect implementation in the chat_manager
which closely matches the on_redirect implementation in chatter.js,
however the former has the advantage of calling get_formview_id
to ensure that the view is correct.
This fixes a faulty behaviour when some models are referenced from
chatter message using data attribute data-oe-model and data-oe-id.
For example, linking invoices in the chatter would always open them
with the 'vendor invoice' view; from this revision on the correct
view will be used (assuming get_formview_id is implemented on the
model).
The default behaviour of the chat_manager when a user clicks on a
partner record is to open a channel if the partner has a user then
return a callback passed as a parameter (usually to open the channel
as a popup or in the discuss app). To keep the old behaviour
of the chatter followers list widget (i.e. open the partner form
when clicking on a follower), a small change has to be made on the
redirect implementation: when no callback is provided, do not create
the channel (instead a returning an empty callback).
The default order on `sequence` was not specific enough,
causing semi-random selection of picking type and warehouse
when several types exist with the same sequence.
The problem was made more likely by the fact that
warehouses create their own picking types.
The algorithm to determine the sequences for the
new types was not handling properly the case of
a NULL sequence.
The patch fixes both issues: the selection of the
default picking type (e.g. for purchase orders),
and the algorithm for choosing the sequence for
new picking types.
* Replace mail theme/template system with a cleaner one which only
allows to change a class on the main container of the mail
* Improve snippets
* Improve snippet options
* Improve web_editor UI
* ...
* Remove mass mailing template switching system (lemon, airmail, ...)
and replace it with a theme selector which only toggle a different
class on the body.
* Lint JS files.
* Change the way the editor is overridden by mass_mailing in a more
odoo way (put the JS in assets and check on runtime if it must be
applied.
+ fix editor style
+ remove useless code
+ remove odoo template
Instead of showing the columns delivered/invoiced qties on SOs
by setting a special key in the view's context, let's do the opposite
and hide them for a sepcial key instead.
The rationale behind this decision is that when a user wants to see
a SO from another place in the system, it is often a SO and not a quote
(i.e. accessing from an invoice's chatter message, from a subscription,
etc.). The default should then be to show these fields unless otherwise
specified in the context (and not the opposite).
`product_id.product_tmpl_id` expects ids of `product.template`
while `products.ids` are ids of `product.product`.
This is an oversight during the migration to the new API of this
module in the below revision:
b9853db8b5
opw-687444
This commit is a port of a17c09af to master
The email templates may contain non-html content (mako) which should not be
sanitized.
Changing this attribute to sanitize_attributes made the translations to be split
when translated.
Double tap
* fix wrong group xml_ids probably introduced when rebasing the branch
removing workflow after xml-id-pocalypse
* fix wrong group used for buttons, should be for Billing users
There is a traceback when we are trying to install module from the list
view and clicking on the button 'Module Immediate Install'.
This traceback appears because of a server action that has not been migrated
during the rev https://github.com/odoo/odoo/commit/d465346f1
To fix this, we've converted the server action in new API.
When we create a timesheet activity, it create an analytic line that allows to re-invoice the costs from the employee. If the account_id is not set on the analytic account line, the employee cost is not passed correctly on the Analytic Entries, which is not the behavior we should expect.
This commit simply adds a account_id on the employee and this account is returned with the cost and the uom by the method `_get_timesheet_cost`
Indeed currently it is only visible in edit mode. However we noticed
people did not trigger the edit mode to find fields they do not expect
to find. Making them visible helps understanding projects can be used
notably for tasks and issues.
* Number of emails should not take into account internal notifications
* Remove Channel and Tasks from issue report as those are not really
used anymore
* Remove New filter as it can be done through stage filtering instead
of using a not obvious heuristic based on stage sequence
A new view is dedicated for that kanban view. It is based on the standard
issue kanban view but using the group_create=false attribute to disable
the ability to create new columns.
It is done using a different view because standard issue kanban view
requires this ability. However it is not possible to achieve that goal
using conditional attributes.
RecordSets were not preserving order when combined
with AND/OR set operators. Order was lost as well
through mapped().
This caused various recurring "heisenbugs" during
tests executions on runbot, specifically comming
in the test of stock_landed_costs.
Using OrderedSets instead of basic Sets to resolve
these operation avoids the indetermination.
This required an implementation of __or__ / __and__
for OrderedSet.
- As of v10, manifest files should be named `__manifest__.py`
- For backwards-compatibility, __openerp__.py manifest files
will still be supported for the time being
- Limited refactoring, to add support for the 2 different
naming conventions
- All textual references to __openerp_.py updated in
documentation and examples
Manifest files are literal Python dictionaries, and
aren't supposed to contain expressions that require
a full-fledged eval.
`literal_eval` is therefore sufficient *and* safer.
This parsing method was already used when listing addons
during startup of the Root controller (http.py, load_addons())
Since the below revision:
293c1c06e6
The "Suggested products" tab on the sale quote template
form has been doubled. This is an oversight when adding the field
`layout_category_id` to it.
opw-687633
When consuming products tracked by unique serial number, no check is
done on the quantity consumed for a given serial number. It means that
negative quants might be created without any warning to the user.
We implement a simple warning thanks to a onchange.
opw-687129
Denis Ledoux