This fixes an issue that occurs when marking fields to compute in the
following situation:
- it occurs before the actual modification,
- a relational field is marked to compute,
- the same field is traversed to inverse some dependency.
When the marking occurs after the modification, the traversal of the
field should actually recompute the field. However, if the marking
occurs before the modification, the inversion of dependencies must be
based on the current value of the field. This is the case with method
unlink(): we call method modified() to mark the fields that currently
depend on the records to be deleted, and the fields must be computed
only after the deletion!
X-original-commit: cd19c2d93db8911fe42802640ea32e5d87aadeec
Create a promotion program with the "Minimum Purchase Of" right field
left as blank
It won't be taken into account in SO when clicking on 'Promotions'
When the field is left as blank `rule_minimum_amount_tax_inclusion`
value is `False` and thus break the check.
opw-2392546
closesodoo/odoo#63330
X-original-commit: 814cd954944b76fb8a8cb8e4b8da8d17c0eec88c
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps:
- Have a demo user with "User: Own Documents Only" rights on Sales.
- Connect as admin
- Go to Sales > Products > Coupon Program
- Click one of the programs
- Generate a Coupon
- Reconnect as demo user
- Create a Sales Order
- Apply the generated coupon
Bug:
Access rights restriction on the coupon.
Sorry, you are not allowed to modify documents of type 'Sales Coupon' (sale.coupon). This operation is allowed for the groups:
- Sales/Administrator - (Operation: write, User: 6)
Explanation:
When applying a coupon to the sales order, it tries to update the coupon's state and link it to the order. This needs to update the coupon record.
This commit also fixes confirming quotations and cancelling sales orders with coupons for salespeople.
opw:2409858
closesodoo/odoo#63239
X-original-commit: 873340ca98b9732132e056c1ca79c614c6255c1c
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a coupon code
use it in a quote A
cancel the quote A
use it in a quote B
confirm B
go back to quote A
set to quotation
confirm
Result: you used the coupon code twice
opw-2410684
closesodoo/odoo#63067
X-original-commit: 58d82943c58ed50e2cae27b8eb085fc4e54eebaf
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
mail_template_sale_coupon is specific to sale_coupon so we are moving
it back to sale_coupon module. Additionally, we add a way of selecting
a mail template when generating coupons for customers.
Recenlty, this method was changed to use set instead of recordsets
to improve the performance of the code.
But set have a non deterministic order, which means the order of the
returned programs returned is not the same, modifying the resulting behavior
as some programs cannot be applied together.
To fix this problem, this commit replaces the set by lists
to ensure the returned recordset keeps the same ordering.
Also rename a potentially conflicting variable caused by the same commit.
Finetuning of commit cc1bb9224b3d50897e8f16404ed10bcc04225c60.
closesodoo/odoo#60472
X-original-commit: 6d4da47fff9a809f65912d4132a5fd3ccaa37b90
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Avoid filtering/checking the same condition multiple times on the same
records...
This allows to avoid n more fetch of all applicable coupon programs from
the database (because _check_promo_code is called on each program in a loop).
Also apply the date filter directly in SQL:
* The computation of inherited fields (_inherits) by the orm is intrinsically slow.
The fields rule_date_from and rule_date_to checked in the _filter_on_validity_dates
python filter are inherited from sale.coupon.program.rule model.
* Filtering recordsets in SQL is faster.
closesodoo/odoo#60292
X-original-commit: 679ebc3381179f6b18364c6f2b4d4f7f34274698
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Use set instead of recordset to incrementally join records
* avoid filtered and mapped calls when possible
* use generators correctly
sum([gen]) --> sum(gen)
X-original-commit: d3daa3793b8fbc9308ec0fb8935d6991b834f3a5
Co-authored-by: Loan Sens <lse@odoo.com>
_get_applicable_no_code_promo_programs always returns a subset of
_get_applicable_programs ...
We can thus avoid summing the results from the two methods, which
triggered unnecessary operations and resulted in a recordset with
useless duplicates...
Furthermore, as _get_applicable_programs returned recordset is only
used to compare to other recordsets (substraction or comparison),
it doesn't need to be sorted by the model order. We can thus
safely order the result by id instead, to reduce the query complexity.
X-original-commit: 5d45322cb6abb689dd15566e938fe75318dfdc4d
When coupon is installed, all cart (SO) updates on the e-commerce go through
the _remove_invalid_lines method. It has been proved to be a performance
bottleneck on big instances with a lot of coupon programs.
To reduce the performance impact of this method, this commit reorganize it
to avoid unnecessary operations as much as possible.
X-original-commit: 447057cfbe28db760834fba2dfd2c79303825cbc
Co-authored-by: Loan Sens <lse@odoo.com>
Instead of summing the programs filtered by "current_order" and
"next_order" usage, use all the programs directly.
We can safely assume that the promo_applicability is always set, and if
not, the code later should still behave correctly considering it wasn't
verified in the other methods.
This allows us to avoid two "useless" walkthrough on the coupons applied
on the current sale order.
X-original-commit: cc74ad0108e47654f4a795556f03841319909c67
If only one of the two dates rules fields is specified, it won't be considered
when filtering coupon programs, and the program will always be considered valid...
This commit reorder the conditon to correctly consider both fields: rule_date_from
and rule_date_to, even if only one of the two field is set.
X-original-commit: 871a118d2c72f58185cbf822375282b613e67337
A check on the company_id field was forgotten in _get_applicable_programs.
To follow the logic of the following method _get_applicable_no_code_promo_program,
this condition is added to the domain, ensuring coupon programs from other
companies cannot be applied to a sales order.
X-original-commit: 559f1e96e17fadad82261eb32a5d02aa5fe91ca9
Issue
- Create promotion program with product_x
- Create new quotation
- Add product_x on the first line
- Add another product_x on the second line
- Press "Promotions" button
Cause
The attribut reward_product_qty except singleton but order_line contain more than one element
Solution
Take the order line with the higher quantity
opw-2350574
closesodoo/odoo#59637
X-original-commit: 30d66b17ea1829e30de176774c7511aab19851a0
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Achraf <macadelic80@users.noreply.github.com>
`_send_reward_coupon_mail` is defined as `ensure_one` but is called on
`self` in `action_confirm` which supports multiple records in self, thus
raising a ValueError when confirming multiple sales orders together.
This commit adapts the method to handle multiple records.
FW-Port of odoo/enterprise#12161closesodoo/odoo#56861
X-original-commit: 99c230c1c167d7369f8003c0219386799f92097d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Alex Comba <alex.comba@agilebg.com>
On instances with a lot of coupons programs, performance issue arise while using eccommerce (adding item in basket ant opening it in particular).
In the client case, he have ~2000 of them.
Opening the basket with 1 product take:
Before this commit: ~10s
After this commit: ~2s
( pyflame is available in the ticket attachment )
`_get_valid_products` use the v13 `filtered_domain` method
Average execution time:
Before change: 0.001 s
After change: 0.0001 s
=> 10x times gained
The average execution time of `_is_valid_product` is 0.002 s (20 times slower than `_get_valid_products` for the same result).
=> All use of `_is_valid_product` were replaced by `_get_valid_products`
In this commit targeting master, we also completely remove
`_is_valid_product` as it effectively is no longer used and there are no
stable compatibility requirements.
OPW-2323599
closesodoo/odoo#56460
X-original-commit: c3a9738e25dbd773e3ee7c2175e62219346ef764
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Steps to reproduce the bug:
- Create a promotional program P with company A
- Change to company B and create a SO
- Click on Promotion
Bug:
The promotion created in company A was applied to SO created in company B
opw:2303169
closesodoo/odoo#55010
X-original-commit: 3e88c5157ca344208ad4853c529baab732c1c2dd
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Create four promotion programs:
if the order > 1500 than 10% discount
if the order > 1750 than 15% discount
if the order > 2000 than 20% discount
if the order > 2500 than 25% discount
Take a product with a price of $300 and add 5 to cart > the 10% discount
is correctly applied.
Add 1 more product (6) > it should now qualify for 15% discount, but it
stays at 10%
Add 1 more product (7) > it (correctly) gets the 20% discount
The 25% discount does not get applied until 11 of the product is in the
cart, even though it should qualify at 9
If you then decrease the quantity, the right discount will
sometimes display.
This occur because when the order amount change and the new total is
used to match the right promo the previously applied discount is not
removed from the amount.
This occur as side effect of
1d59785 in which the amount has to be
kept in order to avoid discount line removal on cart update.
opw-2285656
closesodoo/odoo#54400
X-original-commit: 28c099e6d5b02518b6b5a0be66b2b74a57f0c936
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a promotion program with conditions:
- Minimum product quantity (ex 2)
- Minimum purchase in currency (ex 500$ tax excluded)
- Auto apply
- On current order
- with reward:
-- Free product (Free Prod A)
-- 1 Quantity
Create a sale order. Insert 3x ProdA @ 1000$. Click on "promotions".
Nothing will occur because the minimum order amount for applying the reward is
calculated removing from the order the product associated with the
reward. This removed all of the products from the order, so the result is 0.
Fixing by subtracting just the amount specified in the reward program.
opw-2274316
closesodoo/odoo#53407
X-original-commit: 804461fb1353c931986eeae94bd3ad8465b604e7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Create a promotion program with conditions:
- Minimum purchase in currency (ex 100$ tax excluded)
- Auto apply
- On current order
- Unlimited use
And reward:
- Free product
- 1 Quantity
Go to website shop. Fill an order with amount above the minimum
required by the program. The promo will apply and add the free
product.
Increasing the order amount will eventually make the free product
quantity increase, eventually overcoming the reward product
quantity.
Fixing by calculating the reward quantity using both minimum quantity
and minimum amount and using as cap the to reward product quantity
currently in cart
opw-2246138
closesodoo/odoo#51680
X-original-commit: 02331a34cf66117b27cfa1e96078b4721cbd1e70
Related: odoo/enterprise#10722
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This refactoring extracts parts of `sale_coupon` module to create a more
generic module called `coupon`. This new module can be extended in
different sales modules to implement functionalities specific to modules
that extend it.
An initial step to prepare the creation of coupon module. The main goal
is to just move the logic from sale_coupon to coupon. To come up with
less diff as possible, this rename/move step is beneficial for this
purpose.
Create a coupon program with:
- Minimum purchase in currency (ex 100$ tax excluded)
- Fixed discount applied on order (ex 100$)
Generate some coupon.
Go to shop. Fill an order with amount slightly above the minimum
required by the coupon (ex. 125$). Apply the coupon.
Nothing occur to the cart: the coupon is applied correctly,
but when the cart is refreshed it will check for any non-applicable
promotion against the current order state (125$ - 100$ = 25$, since
the coupon check is for orders above 100$ the promotion will be removed).
Fixing the condition in '_get_no_effect_on_threshold_lines' to detect
also coupon lines in order to make the fair computation.
opw-2224169
closesodoo/odoo#50694
X-original-commit: 2f733ba85320dd67c6892f6a56e3680a3b2fbb50
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Currently, when there is promotion with usage Automatically Applied
and creating quotation without reward line but on copy of that order
the reward line will be added even the original quote did not have the
reward line(discount).
So in this commit, on copy of the sale order, unlink and apply reward
line only if origin sale order has the reward line.
TaskID: 2228249
OPW-2227968
closesodoo/odoo#49798
X-original-commit: 88aae85cafaeec763a05f49003aff5d593a8922d
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>
Co-authored-by: Rushi Sathawara <rus@odoo.com>
Before this commit, There was expected singleton tracback on Archiving multiple Coupons at once.
With this commit, We are passing single Record to process.
This is manual Forward port of https://github.com/odoo/enterprise/pull/9637
(Coupons modules went from OE to OC in saas-12.3)
closesodoo/odoo#48996
X-original-commit: d8c2c7269560920511598414741ad42e1f7a0213
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
- Create a Promotion Program with
'Applicability' set to 'Apply On Next Order'
'Promo Code Usage' set to 'Use a code', set a code (not required,
only for easiness)
- Create a SO, use the code and validate
- In the Promotion Programs, open the coupon list
The Expiration Date is set to tomorrow.
The Expiration Date is not useful in this case, and it is computed only
because the default value of `validity_duration` is 1. However, the user
is not able to change it since `maximum_use_number` is used for
programs instead.
We set a default value to zero to avoid any confusing computation.
opw-2210794
closesodoo/odoo#47779
X-original-commit: 44e71f9192d8711cbaeac0088db55c3ff26813a1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When installing website_sale_coupon, you are forced to install sale_management,
it shouldn't be the case.
Task Id : 2192587
closesodoo/odoo#46416
Related: odoo/upgrade#861
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose
=======
Helpdesk users don't have the right to write on a coupon.
When sending a coupon by email, the coupon is marked as 'sent'.
Allow users to send coupons by executing the state change in sudo.
closesodoo/odoo#45091
Taskid: 2179609
Related: odoo/enterprise#8143
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
as per the task requirements pdf coupon design changed
same as email design.
Task-ID: 2027296
Closes#34620
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Fix the layout of logo to the printed coupon.
The traceability of the coupons is not clear. for Ex. coupon is send or not?
should I resend? so updated the stages of the coupon
Now the stages will be like
-pending(previously reserved) -- hidden by default
-Valid
-Sent : updated when mail is sent to customer
-used
-expired
-cancelled : hidden by default(added button to cancel the new coupon)
Cron added to expire coupon automatically.
PS: model sale.coupon do not inherit the thread so instead of message_post
change the state 'sent' from mail_compose_message.
Task-ID: 2027296
Closes#34620
some layout fixed and confusing string of promo_applicability option is
changed to 'Send a Coupon' form 'Apply On Next Order'.
Task-ID: 2027296
Closes#34620
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit fix most `t-set` errors that either led to:
1. unwanted text to be considered as translatable.
eg: `<t t-set="classes">text-left bg-100 p4</t>` would create an
`ir.translation`.
2. text that should be translatable were not.
eg: `<t t-set="text" t-value="'Both'"/>` would not create an
`ir.translation` while it should.
If a text should be translatable, it should never be inside a `t-value`:
- `<t t-set="text">Both</t>`
If a text should not be translatable, it sould either be inside `t-value`,
`t-valuef` or the `<t>` tag should have `t-translation="off"`:
- `<t t-set="classes" t-translation="off">text-left bg-100 p4</t>`
- `<t t-set="classes" t-valuef="text-left bg-100 p4"/>`
- `<t t-set="classes" t-value="'text-left bg-100 p4'"/>`
https://github.com/odoo/odoo/pull/43660https://github.com/odoo/enterprise/pull/7839https://github.com/odoo/design-themes/pull/203closesodoo/odoo#43660
Related: odoo/enterprise#7839
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Raphael Collet