This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to add the possibility to define a <control>
in the arch of a kanban view. This works exactly like in the list view
arch. So we can add <create> and <button> that will be present when the
arch is used by an x2m in kanban view.
As a reminder, <control> allows you to add buttons to an x2m in list or
kanban view without js customization:
<create> allows to add a button allowing the creation of a record with
a different context
<button> allows to add a button action.
closesodoo/odoo#111307
Taskid: 3143419
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
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>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
Before this commit it is possible to archive a product if the current user have no access to all reward (multi company rules).
closesodoo/odoo#106574
X-original-commit: 5bafee8d0479367fd25b2fa2daefd4374ab38211
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- Go to reward and loyalty add a reward to a program
- Select the free product reward in type
- Select a product
Current behavior:
There is a JS traceback
Explanation:
The reward_product_uom_id was missing from the form
closesodoo/odoo#103272
X-original-commit: 7552a828ce72e51ecd171519f6de6b14478791ac
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Prior to this commit, the mail preview for gift card wasn't readable in
dark mode.
This commit fixes this issue.
task-2710677
closesodoo/odoo#103163
X-original-commit: 360e8da33fa8b1a607a96eb58fc0dcc5e1b07539
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
- Gift cards can now be sent alongside the receipt via mail in the Receipt Screen.
- The gift card report no longer show n² gift cards
- Properly download all PDF files for the gift cards when there are multiple gift card programs
closesodoo/odoo#102910
X-original-commit: 5b269ebb3e725ff84c437e204874c14251ed1d78
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
It was possible to sell gift cards without mail template or report link to the gift card program.
Thus, it was impossible to get the info related to the card unless you have backend access rights.
We now make sure the gift card program have a template and a report when starting the session.
closesodoo/odoo#102885
X-original-commit: e81db2e6e1a3179f9cb6c8410111201d311a97ab
Signed-off-by: Masereel Pierre <pim@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>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the present when in a multi-company environment it is possible to create loyalty programs without a company associated to it. This cause a problem when computing conversion rates as conversion rates are associated to a company.
After this commit if no company is setted on the loyalty program then when computing the amout to deduce on the loyalty program we fallback to the env company (this is the same way the company is initially deduced on the loyalty program).
Task - 3001177
closesodoo/odoo#101922
Forward-port-of: odoo/odoo#101631
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
* Allow multiple loyalty programs.
* Improve gift card workflow: https://app.excalidraw.com/l/65VNwvy7c4X/1Xt93llULvo
* Integration with the ewallet programs: https://app.excalidraw.com/l/65VNwvy7c4X/4B9AEOSbaku
Note that we prevent refunding eWallet and gift card top up and
reward products. If for instance the user wants to refund gift cards
they'll have to transfer the gift card to ewallet by topping up the
customer's ewallet and paying with the gift card to be refunded.
closesodoo/odoo#100891
Task-ids: 2959620, 2959661
X-original-commit: fa06e3225650ed9d1a96709b0398e7f33313acf5
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The generate coupon button would appear after the export button prior
to this commit.
closesodoo/odoo#100463
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
Prior to this commit it was not possible to choose the customer when the
wizard was started form an ewallet's program ewallet list view.
TaskId-2982239
Part-of: odoo/odoo#100170
This PR adds some trigger to make sure that all python request
is correctly finished. This is needed because an unfinished python request
makes a traceback appears on runbot.
opw-28835921
closesodoo/odoo#99475
X-original-commit: 7a98b59b36e9e2cf1816b73ebc3be5de58e054c2
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
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>
Due to the new form and list views some of the customisation of loyalty
were not working properly anymore.
This commit adapts the js customisation inside of loyalty to wowl 2.
TaskId-2929488
closesodoo/odoo#96731
Signed-off-by: William Braeckman (wbr) <wbr@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>
With some scanners, the barcode was not readable due to its size.
A 2 time width increase make the barcode width similar to the code width in text form.
OPW-2793423
closesodoo/odoo#92999
X-original-commit: d19517cf84baf979ee10e6796a6f9e093ab48485
Signed-off-by: Masereel Pierre <pim@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>
Aaron Bohy