*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Some basic fields were missing in the front-end product creation modal (i.e. the sales price).
task-3093208
closesodoo/odoo#107420
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
- Make content helper more generic for programs
- Add search fields for loyalty.card
- Fix creation emails for gift cards in pos not being sent properly
- Fix validity date check on loyalty rules being inverted.
TaskId-3002190
closesodoo/odoo#102160
X-original-commit: f893fda1a40127b7510e861c96f4d4cf9d10f79d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The widget `many2one_tags` tags was used in the loyalty program form
view, however it does not exist.
TaskId-2982239
closesodoo/odoo#100170
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Prior to this commit the default values of a reward/rule would be static
and not depend on the program type.
It will now use the default value if the program_type is given in the
context.
TaskId-2982239
Part-of: odoo/odoo#100170
This commit improves some messages and usability for loyalty and its
submodules:
- Coupons should not be restricted to the partner assigned to them
anymore
- Merged "I have a promo code" and "Use a gift card" into a single
toggle
- Boolean fields have been added to each app to disable them where we
don't want them.
- Reduced the size of coupon codes
This means that we increase the risk of collision which should be
handled by the model as well now.
Creating a coupon with an existing code will retry the creation (up
to 10 times) until the coupon is indeed created.
- Make it clearer in the coupon generation wizard that an email will be
sent to the customer.
- Reintroduce coupon/gift card details on sale order lines in eCommerce
which was wrongfully removed.
- Remove the "on product with taxes: " message on order lines when
the amount is not split between taxes or if the tax message would be
empty.
- Make it possible for some error messages to be displayed as warning
instead of errors
- Split program types in two menuitems, one for promotions discount
loyalty etc and one for gift cards and ewallet, the latter has
simplified views.
- Views overall have been reviewed to make it easier to understand how
to programs work. New program types have also been added.
TaskId-2951413
Part-of: odoo/odoo#99023
Co-authored-by: William Braeckman <wbr@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This module is an unification of `coupon`, `gift_card` and an extraction
of the program models of `pos_loyalty`.
The goal of this module is to unify the creation of coupon, promotion,
gift_card, loyalty programs etc.. into a single base module and share
the same models.
Managers will be able to create programs based on rules and rewards.
Programs may apply on the current order (rules and rewards)
or on future orders, where the rules must match the first order to get a
reward on the second order
or even be nominative and accumulate points over multiple orders.
Every program is based on a point system. And each use of the program
will result in the creation of a coupon (except for nominative programs
which should be limited to one card per customer).
A rule may filter on quantity, money spent and products and give points
on the order, the amount of units paid or the amount of money spent.
A reward could be a free product, a discount or (with an additional
module) free shipping.
Discounts can be percentage based, fixed, or based on the amount of
points the card has.
They can also be filtered on products or tags, to discount specific
products.
A new feature is also being able to select communication plan for these
programs.
The manager can define a template to be sent upon the creation of a new
coupon/card or when reaching a certain amount of points.
TaskId-2675382
For empty list design:
Co-authored-by: Carlos Valverde <cvs@odoo.com>
Elisabeth Dickinson