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 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
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>
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>
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>
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>
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
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>
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>
* 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>
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>
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>
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>
higo-odoo