* Use the theme class selector as root for the less file
-> Allow to style the editor as applied to the body
-> Split in editor/color/layout/snippets
* Create an assets to contain all mm themes so that the compilation is
made by the odoo system, and allow minification and variable sharing
between themes
-> Remove css files
* Reformat the LESS files content
website -> web_editor so that they are available for mass_mailing.
To allow setting margins on td elements:
As the above mentionned option allows to control the mt and mb classes
on the mass mailing items, the problem is that we would ideally want it
to be functionnal on td element as they are the main part of a mail.
As they don't support margins, there were many options to fix the
problem:
- Add more JS to place the mt and mb classes on children of td element
- Place the option on children of td element and not td element itself
but in that case, the width control of td would imply a lot of parent
option hierarchy, or the width control had also to be adapted to control
children
- Control padding instead of margin. This forces to add lots of
css rules like pt4 pt8, ... (or td.mt4, td.mt8, ...).
The last solution has been chosen. Padding is more supported than
margins in mail client anyway and the css rules will be isolated in
the mail editor anyway. Using td.mt4 instead of pt4 had the advantage
to not require any JS modification.
When there is no content in the mail, the user is now forced to choose
a theme. Once the choice is made, the theme introduces default content
(series of snippet to simplify user edition).
The default images are also changed when the theme is switched. To do
that, JS code was implemented so that on theme switch, all the images
are changed to check for images in the static theme folder or use a
theme related xml_id.
+ Refactore theme data management.
Before migration:
'phone': customer and customer.phone or lead.phone,
After migration:
'phone': customer.phone if customer else self.phone,
So if a customer exists and that it has no phone, the phone
on the lead need to be preserved during convertion in opp.
If a leave request is refused by the manager, the button reset to draft is displayed, but the employee cannot use it because he doesn't have the write access rights on his own leave requests
In 'refuse' state, all the form is readonly, but the employee should be have to reset his own leave to draft to modify it and re-submit it.
Some view extension (in this case mainly counters on partners, like
small Sales Orders counter badges etc.) should not be visible if you
don't have the relevant rights.
If an analytic account is not linked to sale order, do nothing (and do not return False which is not a valid value for a write ({} would have been valid)). We should allow the simple analytic accounting without sales order.
It often occurs that users get nasty error messages like "missing value
for column xxx" when trying to create objects. It can happen if the
objects uses a sequence as default value that is not defined in an
available company.
We try to give a hint to the glory support person who could be confused
by that.
This commit reverts the API change introduced in b3302398bc
that changes `ir.qweb#render()` to return a unicode string instead of a utf8
encoded bytestring.
Returning a unicode string is undoubtedly cleaner and a step in the direction
of python 3 but still is an API change that can break third party modules.
Let's wait the migration to python 3 before breaking other people's toys.
When a pad is created programmatically (e.g. through a project task or a
note), the pad is empty when it is first displayed. It is necessary to
edit the record and save it in order to be able to see the content.
This is because the pad is normally initialized by the JS layer, at the
first edition, thanks to a call to `pad_generate_url`. Therefore, a
programmatic pad creation won't initialize it.
opw-685826
Before this commit, we check everytime the subtype.
In some case (eg: portal user on the forum) don't have access to subtype of
type internal.
This commit fixes opw-688403
This commit closes#13510
The dictionary `_group_by_full` is replaced by a field parameter `group_expand`
that is assigned to the method name. The API of the method has been simplified
as well:
@api.multi
def _read_group_stage_ids(self, domain, read_group_order=None, access_rights_uid=None):
# the stages are given by self.ids (wrong model);
# read_group_order is the order given to read_group() on self;
# return stages.name_get(), {stage.id: stage.fold)
_group_by_full = {'stage_id': _read_group_stage_ids}
is now written:
stage_id = fields.Many2one(..., group_expand='_read_group_stage_ids')
@api.model
def _read_group_stage_ids(self, stages, domain, order):
# stages is a recordset;
# order is the order to use on stages' model;
# return a recordset which is a superset of stages
When a modal was opened, the system seemed slower because a web_tour
callback was called every 500 ms.
This was because of jQuery. Using the "find" method on a jQuery element
will temporary set an ID on this element for some jQuery reason. So,
when a modal opened, a DOM mutation was caught by the web_tour observer
which then called the "update" method in which a $modal.find
is done... and so an ID was set and a new DOM mutation was caught again.
The solution here is to provide an unique ID on each modal in odoo so
that the find function has not to set an ID, and so does not trigger
any DOM mutation.
When increasing the amount on a confirmed purchase order line,
an extra move is created in the incoming picking.
When the purchase creates the moves in the picking on confirmation, it takes into account
the procurements that triggered the purchase order and creates a move for every procurement.
This is necessary in order to make the next steps ready.
With this commit, when you increase the quantity, it will take into account the amounts of moves
already created for a procurement and not link the new move with a procurement if not necessary.
This case can be tested by confirming the PO with less than foreseen by the procurements and increasing
the amount afterwards. (which is more of a corner case, but it is good to do things right)
The dashboard must be visible for non-'group system' users, hence
the sudo call + only display the link to modify the client id
if the user has sufficient access rights.
Small visual correction for live users counter in the dashboard.
The dashboard instantiates an action manager for each view it has to display.
It then replaces the do_action() function of those action managers by its own
one, forgetting to pass the second argument 'options'. Thus, when do_action was
called by a view of the dashboard (e.g. a button in a list view), it was called
without the options.
This is linked to the previous commit.
This commit adapts the widget extension and backend controller of
the website admin dashboard to prevent a crash if the user does not
have sales rights.
This is linked to the previous commit.
This commit adapts the widget extension and backend controller of
the website admin dashboard to prevent a crash if the user does not
have sales rights.
The Website Admin dashboard displays graphs for sales, analytics,etc.
using a (somewhat easily) extensible js framework.
Unfortunately, this framework is ACL unaware, meaning that it will
completely and silently crash if you are missing any of the required
access rights.
To solve this, extensions must now specify not just a graph name
but a necessary group for it and set the value for this group in
the extension of the backend controller.
This commit also
- make the icon visible for the group 'Website Designer and Editor'
(not juste the Settings group, which is extremely restrictive)
- make the button to set the Google API key only visible to people
with sufficient access rights
Makes it easier to later reconcile payments with
bank statements. For eCommerce orders the payment
transaction happens before the creation of the invoice,
so the invoice number is not sufficient to quickly
find a match for reconciliation.
This will improve the onbarding of project and the usability in general.
Project: When creating a project a small modal opens with one or more fields, and you have to click on it just to type the project name.
Usability: one many2one (and others), when clicking on "Create and Edit", the focus is set on the first field.
This allows to import acccount.move.line via csv and provide the field 'tax_ids' (which is needed for the tax statement).
This option is now a context's key, replace the key 'dont_apply_taxes' which was now useless
qsm-odoo