Before this PR, users encountered an issue when attempting to add rules
to Discount and Loyalty programs. An undesired validation message would surface,
preventing them from saving their changes.
In this PR, the extraneous validation has been eliminated, enabling users to
successfully save and update their existing rules and rewards.
Task-3487478
closesodoo/odoo#134261
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
-------------------
- being in a multi-company environment;
- have one product made that is first in alphabetical
order of "Internal Reference" throughout the database (e.g. [AAA]);
- make this product specific to one of the companies
(set the "Company" field on the product template)
- go into a different company within the database
(not the one set on this product);
- create a new discount & loyalty record, and set
the "Program Type" to "Discount Code".
Issue:
------
An access rights error occurs.
Cause:
------
When creating a `promo_code` program, we use the first product
that can be sold in the default reward values.
Solution:
---------
Take into account the company in the domain that retrieves
the default product.
opw-3538516
closesodoo/odoo#139008
X-original-commit: d80c28c78bf3237e2526a6370f9c6c0b0f8dc232
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Steps:
- Install `sale_management`
- Go to `Discount & Loyalty`
- Create a new one and set a name
- Change default program type from `discount` to `buy x get y`
- Remove the default rewards
- Add a new one (the default one)
- Click `Save & Close`
- Trigger save
Rewards is reset to default `discount` instead of `buy x get y`
closesodoo/odoo#138523
X-original-commit: 798c69f44bfde2f66826775a5a11fe5e51adb9a8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
We move the filterable widget from loyalty to web to make it more widely
accessible to other applications. It will soon be used in the new activities
plan feature.
Following the move of the filterable selection widget to the web module, we do
some light cleanup.
Task-3390865
Part-of: odoo/odoo#137969
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
*: analytic, base_automation, loyalty, mass_mailing, project, web, web_editor, website
This commit adds many new documentation of options and their usage for
fields. This makes them more usable and customizable in Studio, and adds
documentation for developers to know the type of expected option.
Some options that might lead to issues or that are too technical have
been removed, as they are not relevant and not required in most use cases.
task-3469741
closesodoo/odoo#134858
Related: odoo/enterprise#47148
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce:
- Install Loyalty module
- Go to Website and buy a gift card
- Checkout and pay the order
Issue:
Only 'Order Confirmation' email is sent directly to the customer,
gift card email is queued and sent later.
Cause:
`send_email` method is called with `force_send=False` by default,
which queues the email to be sent later.
Solution:
Add optional parameter `send_force` (default to `False`) to
`_send_creation_communication` method and call it with
`send_force=True` when confirming a sale order.
opw-3324386
closesodoo/odoo#134927
X-original-commit: cd9b47322948dda519230d25cf9ed31a3535f0c2
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
When installing point_of_sale and loyalty modules, then creating an eWallet program, the user gets an error that prevents him from creating the program.
Steps to reproduce:
- Install point_of_sale and loyalty
- Open the settings of the default POS Shop
- Click on the "Gift cards & eWallet" link (under "Promotions, Coupons, Gift Card & Loyalty Program" setting)
- Click on "New" to create a new program
- Change "Program Type" to "eWallet"
- Set a name for the program, then click on the Save button (cloud button)
The error "Split per unit is not allowed for Loyalty and eWallet programs." is raised.
This error is due to the reward_point_split hidden and not modifiable by user field of loyalty.rule that is not correctly set.
The fix consists in correctly setting reward_point_split for new eWallet programs.
closesodoo/odoo#132631
Task-id: 3474750
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
A customer has a gift card product linked to a specific income account.
When sold, the income account associated with the gift card product is
credited correctly. The issue arises when the gift card is consumed
within a sales order. An order line is added using a "dummy product" to
indicate the gift card's usage (one dummy product is created for each
loyalty program). Due to this, when an account move is created from the
sale order, the income account defined on the dummy product is used
instead of the one on the gift card product. This leads to the wrong
income account being debited, causing unbalanced accounting entries.
There's currently no way to link back to the original gift card product
from a `loyalty.card` record. Because of this, the system cannot
identify the correct income account to debit. Fixing this would require
adding a new field, which we can't do in stable.
A potential workaround is to find the dummy product and set the income
account to the same as the gift card product. However, with one dummy
product for each `loyalty.program`, all named "Gift Card", finding the
right dummy product is difficult.
This commit aims to simplify the workaround by adding a link to the
associated dummy product on the `loyalty.program` form view. This change
should ease the process of finding and modifying the correct dummy
product, thus mitigating the issue in the current stable version.
opw-3239720
opw-3373287
closesodoo/odoo#133461
X-original-commit: 767eccb122055cd9a474ce5110cb7296eb9ef4c2
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
There is no need to have two bridges linking delivery & loyalty.
The two modules held the two parts of the same logic, making no
sense to keep the two modules separate.
Task-3420579
Part-of: odoo/odoo#129572
Step to Reproduce at Runbot:
-> Install Coupons & Loyalty and Contacts Apps
-> Open Contacts form view
-> AccessError telling you that you cannot read loyalty program & cards
See this video url:
https://watch.screencastify.com/v/ygI1wjVyP5xo5tWTzeST
closes odoo/odoo#130092
Part-of: #107375
X-original-commit: 4c31ef775579b6c7163c91fa2069fcc64819f940
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit fixes `.o_view_nocontent`'s mobile layout. Prior this
commit, it's content was overflowing on top of the page.
task-3418657
part of task-3015891
closesodoo/odoo#129115
X-original-commit: a51310a53ac3abf7435223e2d2a3215a3e60df50
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Steps to reproduce:
- Go to Sales > Products > Discount & loyalty
- Create a new record
- Click on existing reward
- Click discard button
Error due to missing field in kanban view.
Fixes#124785
X-original-commit: db6ee7113cd6c3a830d2d401e92de98787323d43
Part-of: odoo/odoo#129115
This commit fixes a few remaining bugs in loyalty:
- misplaced use of ewallet and gift view for discount program types;
- wrong context when creating a gift card (got discount and coupon);
- wrong options to program type when creating a loyalty card;
- product tag was mandatory in reward eventhough a reward product is
assigned.
task-3015891
X-original-commit: 440a853b01dbcc67ad926487764682a5c68c2c8b
Part-of: odoo/odoo#129115
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
When specified, restrict the promotion to customers using said pricelists
task-3049956
closesodoo/odoo#107656
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Lucas Vermulen (luve) <luve@odoo.com>
Co-authored-by: Morgane Demesmaeker (edm) <edm@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Default mail template for coupon on next order was linked to the gift
card mail template, but it should be linked to loyalty coupon card.
OPW-3281621
closesodoo/odoo#124927
X-original-commit: ece055c105a3a1cbd3621f25765668594af9837e
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
currently it is only possible to define the end_date that
does not allow to prepare the program in advance.
Added the start_date property to the program model.
task-3305712
closesodoo/odoo#121193
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If applied, this commit will solve the issue of missing product issue while
installing the following modules: loyalty_delivery, pos_loyalty, sale_loyalty,
website_sale_loyalty
Steps to produce:
- Install loyalty module.
- Go to 'Products' or 'Product Variants'.
- Delete the product 'Gift Card'.
- Now install the 'sale_loyalty' module.
This commit will raise an userError while deleting the loyalty products.
sentry - 4112536971
closesodoo/odoo#121484
X-original-commit: 3488d292b514bbf4190f19bd8271b3e68b3eb055
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
When archive a loyalty program which have somes rules and rewards and the unarchinving it will not have the rules and
rewards that it had before.
Steps to reproduce the error :
1- install sales
2- activate Discounts, Loyalty & Gift Card in sales settings
3- go to sales/products/Discount&loaylty
4- select one of the default programs and try to archive it and unarchive it after
5- you will not get the rules that it had before
The problem was in the toggle_active function of the loyalty program we try to unarchive already unarchived items because
we do ```program.rule_ids``` so it will get only active items.
opw-3299295
closesodoo/odoo#121710
X-original-commit: 1d9fbda1c5ec69ba83968668ddecec6a7e1421bb
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This commit brings the ControlPanel into a single line with 3 main
sections:
- buttons & breadcrumb
- layout related actions (ie. the SearchBar in multirecord view or
ButtonBox in formView)
- navigation (pager, switch view...)
Add new search bar menu, this is a merge of the following components
into one big component display in column:
* comparison_menu
* favorite_menu
* filter_menu
* group_by_menu
Also adapt navigation hook.
Part-of: odoo/odoo#116641
- The calculator logo of the cash opening popup has been changed to a
bill logo to be more explicite for the end user.
- The cash input is autofocused at the opening of the cash opening
popup. Select number input on focus and align numbers right money
details popup.
- Rearrange Close pos popup layout.
- Set the Gift Card amount to the price of the refound if there is one.
- Change pos_payement_method_view form id order to sequence. Set the
order of payement methods in PayementScreen to sequence.
- Fix markut issue in the chatter.
Task-3215901
closesodoo/odoo#118288
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When sending email with gift card, it will have the user langauge and not the partner language
Steps to reproduce the error :
1- Add french and english language
2- Make the current language english
3- Install contact and sales and activate gift cards
4- create a contact having french language
5- create a gift card for the french partner and send it to him
6- the email will be in english lang
The origin of the problem was the missing lang field in the template
opw-3308919
closesodoo/odoo#121086
X-original-commit: f09ac453aa7cffe1e31f30b68fa0665ef504283a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Current behavior:
When you try to open the pos as a demo user, you get an error message.
Steps to reproduce:
- Install pos and loyalty modules
- Log in as demo user
- Try to open the pos
- You get an error message
opw-3297341
closesodoo/odoo#120334
X-original-commit: 5f6a1df7eda6909df302bc6cfa3ba02d8a2de3d7
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Previously, when a reward was applied on a product, the product was
checked against the reward_product_ids field, which is a computed m2m
field that contains all the IDS of the products on which this reward is
available. In many cases, rewards are available on all products, causing
the computation of the m2m to fill it with the ids of all products.
This caused performance issues on all DBs with lots of products (~200k)
in all flows involving rewards.
We can't remove reward_product_ids from the data loaded in the frontend
in stable because existing JS customisations might crash if they depend
on its presence. As such, to keep compatibility with existing databases,
an ir.config_parameter has been introduced to opt into the new
behaviour. This parameter is set when creating a database so that new
databases don't suffer from this performance penalty.
For existing databases, the parameter can be set by hand if the old
behaviour is not necessary and the performance penalty is an issue in
practice, but is unset by default.
When opting into the new behaviour, the reward_product_ids field now
always evaluates to an empty recordset, and the desired behaviour should
be achieved by evaluating records against the reward_product_domain
instead. In the point_of_sale, the products available on rewards are
calculated by evaluating each product against the reward when it is
loaded. In the loyalty modules, instead of using the in operator on the
reward_product_ids field, we instead evaluate the reward product domain
against the product, which is much faster. This is always done even when
not opting into the new behaviour as the change in implementation cannot
be observed outside of timing.
closesodoo/odoo#120074
X-original-commit: 6f72d053a31aca520cbfbba2d1257568b7f7c0cb
Related: odoo/enterprise#40503
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: 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>
Before this commit when choosing the program rule type "Buy X get Y"
an error occured: after adding rewards and trying to save the record
the rewards were reset to the default value for program rules
of type "discount".
This ocurred because the program type was not being sent to the
`default_get` method of the `loyalty.reward` record.
After this commit rewards are correctly preserved.
opw - 3240558
closesodoo/odoo#118679
X-original-commit: 44b9eab482a219e6c260ef29512b8d6a595300ac
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This error was caught by sentry.
Steps to produce:-
* Install eCommerce,loyalty module.
* Delete 'Top-up eWallet' product from eCommerce/product.
* Then create a new Gift card & eWallets from eCommerce/Gift card & eWallets.
* At this moment A trace back raise.
Because user deleted the product 'Top-up eWallet'.
Sentry:-3985154178
closesodoo/odoo#116738
X-original-commit: e5ae091a530de45741749e01d25f436af093a8a2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Add a stat button on customers views to easily retrieve all
the linked loyalty cards.
task-3050152
closesodoo/odoo#107375
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
We forget to remove few 'props.value' in 688986f888.
We should replace it by 'props.record.data[props.name]'.
closesodoo/odoo#114785
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
nikj-odoo