When we are creating a database with a country code from the database manager,
the country is not set in the company, so when we install the accounting app, there
is no chart of account installed by default. We have this bug because
we are trying to put a country id in a field that should receive a
'res.country' record.
To fix this bug, we change the call of function read_search by a search
that will return a recordset.
Bug introduced in rev https://github.com/odoo/odoo/commit/1b59643d4b96195edcdbe1b1168a11a3b6d85483
The action was never there but added by overwrite in sale_teams which (wrongly)
shared the same ID. After 11812b0 which splits the menus, this menus had no
longer an action added by sale_team module.
When we create a 'product.product', the 'lst_price' entered is
not saved. This is due to the 'inverse' function of the field
named '_set_product_price' which is shared with 'price' and
'lst_price' and uses 'price' to set the value, even if its called
by 'lst_price' field.
Before the migration in new API, it was possible to have the same
inverse fucntion for different fields because the value was passed as param
to the function. In the new API, we cannot because we have to get the
value from the field.
To fix this error, we had to duplicate function '_set_product_price'
in 'set_product_lst_price' to have on function by field, and use the
value correspondig to the field.
Introducied in rev: https://github.com/odoo/odoo/commit/1aa5bc0fdfa402ac7cccbc3a7203ec5050f6339b
When users switch from one version to another, the localstorage is not
cleared and users can get errors because the tour manager is trying to
load steps (according to the localstorage content) which could not
exist anymore.
This could also happen when a module which extends another module tour
is installed.
The view `sale_team_dashboard` (which extends kanban) has been removed
and replaced by a default kanban view.
To use it in the ViewManager, an option `js_class` is added
on the arch description and this class be used as the View.
This avoids creating a new view type just for one view.
* use a special arg in odoo.py
* note that the previous implementation was relying on the fact that
the openerp-gevent file was located in the same directory than the
odoo.py file. This was no longer true since rev a0eb172cab
This commit brings back this behavior.
fix error introduce in commit 7596fa3ee3
The get_format_currencies_js_function return javascript code and the openerp.web should not have been replaced by odoo.web. The result is that reconciliation view was broken.
* Add the ability to define palettes custom selection.
* Add the ability to define a custom title for the colorpicker dropdown
* Define a custom layout for single (unique) palette layout
* Define overlay color options based on new colopicker for
Cover and Banner text containers
* Define default palettes
PURPOSE
=======
For each and every Hr application there should be one user category (One app = one category).
SPECIFICATION
=============
HR remains as it is : Employee, Officer, Manager
Each Application should have 2 access rights: User and Manager. Example for Recruitment:
- The user has access to the recruitment process
- The manager has access to the job position configuration
Each Application should grant the employee user access right (Namely the 'HR Officer')
Now the porperty product pricelist is computed automatically.
Based on the res_country of the res_partner, and the pricelist available
for this country.
It is always possible to force another value (property) that the computed.
Now that property is computed automatically.
In some case, the compute will take the first on available.
So, the order (sequence) allow to specify the priority.
Test from point of sale are base on currency $,
So we force for the test to use a pricelist in dollard (My company, Chicago)
Now, the user can choose on the pricelist if the price should be displayed as a
discount or not (price striked red).
cart_update and confirm_order recompute unit price by default.
So we need for website_event_sale to be able to ask to don't recompute the price.
Else the price of product will be used instead of the price of ticket.
In 8.0 private fields have been recently set as visible only to employees
at commit b226510840.
However between v9 and v10 two new payment acquirers have been implemented
payumoney and stripe. Those addons now have their credential set as private.
Methods using the acquirers have been sudoed accordingly to avoid access
issues when rendering the buttons. Other payment modules will be updated when
the forward port from 8 to 9 and pre-10-master will be done.
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.
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
Pierre Masereel