With this commit, actions can have a type=fullscreen. This means that
the navbar will be hidden, for the action and for all subsequent actions
open in the breadcrumb
There is no real security behind this, this is just a feature for
convenience, so users can bookmark an url an open some action in a way
that they are not distracted by anything. In short, this is some kind of
light 'kiosk' mode.
Classname 'oe_right' was overriden by 'oe_avatar' before rev. 6768bbf, and thus
the images were displayed on the left of the sheet. Since rev. 6768bbf, the
'oe_right' takes the priority over 'oe_avatar' as it should. This commit
restores the layout of these two form views as it was before 6768bbf.
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
In web, mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
Minor tweaks in some other addons to make them work with this new structure.
The POS interface instantiates a web_client and mimics its layout for the
action manager to correctly append the action. This needed to be changed due
to preceeding large refactoring of web, as the actions are now appended in
a div with classname 'o_main_content'.
File variables.less is located in web/ in the community edition, but in
web_enterprise/ in the enterprise one.
This fix uses the template 'web.less_helpers' containing the correct version of
variables.less instead of directly include variables.less and utils.less.
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
Mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
When computing the domain to find the product available data, a special case
is currently managed when doing a child_of in locations. Indeed computing
product available data requires to check its related quants. It is possible
through the context to limitate the search to a given set of locations.
The location_id field on stock_quant model is set as auto_join. However the
use of auto_join with the child_of operator is currently not supported by
the ORM. Those parts are converted into (id, in, ids) equivalent domain leaf
that can be costly due to quants table being quite large. The existing code
in product.py therefore tries to manually optimize the quant computation
by computing manually domain with child_of, using parent_left and parent_right.
However there are some cases when parent_left and parent_right can be 0
notably in update mode. However the current code does not correctly take
into account some location not having parent left / right and other having
a parent left / right being still 0 because still not computed. This commit
fixes that, allowing the correct computation of available product data in
update mode.
This limitation has been spotted when migrating stock to the new API. Indeed
unit tests have been added. In those tests product available info was not
correctly computed. Those tests will come when merging the new API version of
stock.
pos.config had a special state field that mimiced what we usually do
with an 'active' field. The concepts of 'inactive' and 'deprecated' seem
to have never been fully worked out, as both of them resulted in the
same behaviour.
Before this the table edit handles where quite small. This was no
problem when editing a floor layout with a mouse or perhaps with a
stylus on a touchscreen. It was however very difficult to do with your
finger on a touchscreen.
This increases the size of the handles by a factor of 3. To make room
for this the 4 handles on the sides (non-corner ones) have been removed
on square tables since you can technically do any operation you want
with just the corner handles. The only functionality we lose is resizing
a table while constraining it's width/height, but if such fine grained
control is needed then the tables can still be edited in the backend.
Change the label of active state label from Activated to Confirmed. Indeed
it indicates the user logged itself at least once. Active / Inactive is
controlled through the active field. An user that logged once is non labelled
as confirmed.
[IMP] account: d'ont create journal items for invoice lines with quantity 0 (not amount because of tax)
[IMP] crm: usability kanban view and schedule an activity
[FIX] crm: schedule an activity bug when no activity yet
[IMP] website: app for website (not a menu in website admin)
The possibility to choose a subtype when logging a note was added with the
activities mechanism in CRM. However as the user should not use the chatter
but a dedicated wizard in order to do this, the dropdown is removed.
The internal subtype mechanism is kept. Only the possibility to log something
else than a note through the chatter UI has been removed.
When publishing a slide, a message is posted using a template defined on the
channel. This commit uses the template subject to form the message
subject instead of having a generic 'Re: <slide>' as subject.
This code was used to automatically configure a fetchmail server, according to
a model. This followed a name convention, like 'module_', 'group_', ...
This mechanism was replaced by mail.alias system, and it not used anymore
by odoo modules.
It is time to remove this old hacky stuffs : fetchmail.config.settings
model is removed.
The tests constits of creating an employee and give him a contract.
These are not smart tests. This module uses many base action rule,
but they are already tested in base_action_rule module, so removing
the tests seems better.
The short code is always required for the following reasons:
- The auto-generated code is useless for search purpose because user
cannot choose it (BNK or CSH is maybe not meaningful for him)
- If the system cannot generate an unused journal code, the user is
stuck since the field is read-only in the interface.
However, the code can still be auto-generated, although it is required
in the interface. This is to avoid breaking modules that would expect
this feature. At the same time, the logic has been improved to reduce
the number of search requests.
opw-674485
Géry Debongnie