Purpose
=======
display_name is equal to doing name_get()[0][1]
Replacing name_get()[0][1] by display_name could be good for 2 things:
- Uniformization of the code
- Probable optimization if name_get is used inside a for loop on a recordset (as the values will be prefetched and put in the cache).
TaskID: 1849250
closesodoo/enterprise#2515
Commit 092200073 broke the discount computation for discount of type
fixed_amount. Indeed the appropriate method was not called anymore and such
discount type would be computed as percentage discount with default value of
10% (field default for percentage).
opw-1888484
This commit adapts the business code to changes introduced by
the change to related field's default readonly value in order to
keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
67c3de295e9 wrongly adapt coupon to multi-websites as website references should
have been written in website_sale_coupon and not sale_coupon.
Closes#2673
Using a pricelist set as `without_discount` will show a strikethrough price on
reward line (discount and free product).
This is happening because the program reward line (discount_line_product_id) is
created with the default 1$ price as this price is not usefull when computing
coupons. Only the line price is checked.
Now, we create a reward line with a -1 000 000$ price to prevent this UI
behavior.
Step to reproduce:
- Activate pricelist (Sales>Config>Settings>Pricelist formulas)
- Activate discounts in Sales Configuration (Manual discount on order lines)
- Set pricelist to 'Show public price & discount to the customer'
- Add a discount in your cart
- There in a strikethrough price of $1 above the discount line price
task-1878245
A discount on products with different taxes will result in as many discount
lines as there is different taxes.
Before this commit, removing one of these lines would not do anything else.
Then, recomputing the coupon would regenerate/add back this line.
On e-commerce, it means you would never be able to remove the program by
deleting its reward lines if there are multiple taxes (and so multiple lines)
since it would `recompute_coupon_lines` right away, adding it back directly.
Now, this commit will ensure that removing one of these lines will also remove
the other ones coming from this program on other taxes.
It means removing a regular product will remove it's reward line that will also
now remove the other program's discount line on other taxes and ultimately will
remove the program from the SO since all the program reward lines got removed.
(It won't affect auto applied program since it will be regenerated afterward)
task-1866977
Related to #2224
Previous commit fixed some bugs on `sale_coupon` (#2224).
This commit add some tests to be sure these bugs are fixed and won't appear
again.
task-1866977
Related to #2224
This commit is the continuity of a42c27f9 that fixed some bugs.
One of the bug was that a discount was only applied on price without taxes.
E.G: A $100 product with 20% excluded tax would cost $120 but a 50% discount
would give the user only $50 discount and not $60 as expected.
User would lose $10 discount.
With these fixes, the discount line would correctly be set to $60 but since the
discount line would not have tax, the merchant would lose the discount amount
on the tax, in this case 50% of $20.
This commit will improve this case by adding a tax on a discount line.
Thus, since a global discount can be applied to multiple products having
different taxes or even multiple taxes on the same product, a discount line
should be split for every product taxes the discount applies on.
Obviously, this is a big behavior change, even if the discount is now finally
correct: the discount is applied on the total price and the merchant does not
lose any taxes.
To make it more clear, the discount lines description will mention on which
taxes it is applied.
There won't be any changes in the e-commerce since we will group the discount
lines so it will appear as before even if there are multiple lines. This is
only possible because we don't show taxes on line on the e-commerce.
This commit also fixes more complex flows/use cases.
Note: Fixes & flows will be illustrated with a SO but the behavior is the
same with a cart on front-end.
== Fixes ==
===========================================================================
The biggest flow that needed to be fixed is when a promotion program give a
reward on the next order.
Let's illustrate with a promotion program giving a free `product_B` on next
order (so it will generate a coupon) if the SO meets the requirements.
The requirements are: buy a `product_A` and buy for at least $600.
(This program needs a code: 'free_b_on_next')
1. If the SO has a `product_A` and over $600, applying the promotion code
`free_b_on_next` will error saying that `product_B` is not in the cart.
This error should not appear, since the `product_B` is the reward for
the next sale order that will use the generated coupon.
Anyway, if you add `product_B` and apply the promotion code `free_b_on_next`
to generate the coupon to check the rest of the flow. It will generate the
coupon and send email to the customer.
2. Every time you will apply the promotion code `free_b_on_next`, it will
regenerate a new coupon and resend a new email to the client.
Then, create a second SO, add 2 `product_B` and try to apply the generated
coupon from the first SO.
3. It will error saying that the $600 requirement is not met.
It should not since the requirement was only required to generate the
coupon on the first SO. User has now a coupon to enjoy a free `product_B`
and should not buy $600.
Anyway, let's add some products to meet the 600$ requirement to check the rest
of the flow.
4. It will now error saying that `product_A` is not in the cart.
As bug 3., it should not since this requirement was also required to
generate the coupon on the first SO.
Anyway, let's add `product_A` to meet the requirement to check the rest of the
flow.
5. Updating the promotions will remove the reward and you won't be able to
reapply the coupon since it was `used`.
This bug was even more critical in front-end since any action on the cart
will recompute the coupons and automatically delete the reward after adding
it. The customer never saw the reward on his cart.
This bug is related to 3. and 4. Indeed, when recomputing coupons, it will
remove programs that are not applicable anymore. The code wrongly think it is
the case with this coupon since we don't have $600 or a `product_A`.
`_remove_invalid_reward_lines` should treat coupon coming from a promotion
program set on `next_order` differently and not filter on requirements.
===========================================================================
6. (extension of 2.) Every time an user would meet the requirements of a
promotion program generating a coupon for a next order, it would generate a
coupon and send an email.
E.g: If buy 2 iPads get 1 for free on next order. If user add and remove iPad
for some reason, every time he has 2 iPads in his cart it will receive
an email with a new coupon.
6'. When applying a promotion code that will reward next order, it will not be
set in the SO `code_promo_program_id` (I did not change that behavior since
it could make sense to be able to apply another coupon that will give -20%
on current order).
This will allow applying multiple promotion rewarding a next order and/or a
promotion rewarding current order. (Which would not be possible if was
stored on `code_promo_program_id` since you can only apply one code on an
order)
But this cause a bug: since the promotion program is not stored on the order,
every time you will apply the coupon it will generate a new coupon and send
an email.
So if you work on a draft sale order and do some tests, it will send many
emails to customer..
7. Having multiple global discounts (on the whole SO) was forbidden: you can't
apply a coupon promotion or a program promotion if there is already a global
coupon discount or a global promotion discount with code. But still you could
apply a global discount if there were a global promotion discount automatically
applied (without a code).
8. On the generate coupon wizard, if you select `Number of Selected Customers`,
by default it is set to 'Match all records (X records)'.
But when you click on generate, it won't generate anything even if visually
it selected every partner by default.
This is because the domain default value is an empty string. Thus, the domain
widget is selecting everything but once it is sent back to the server, since
it's an empty string it won't get through the `if` condition.
It was even weirder when you add something to the domain and remove it, you
then visually come back to where you were at the beginning but the domain got
changed from '' to '[]' so in this case it will generate the coupon for every
partner.
== More like improvements ==
1. `action_cancel` and `action_confirm` would handle correctly the states of the
applied and generated coupons (valid, consumed, expired..).
But `action_draft` would not handle the states at all.
2. The generated coupon on a SO are now sent by email only when the SO is validated.
This is part of the fix n°2 on coupon being generated multiple times and sent by
email multiple times.
The coupon sent by email was not usable anyway since it would error saying the
SO that generated the coupon was not validated.
3. Discount line limited to a max amount (set in the program) will mention on
the line description that the discount is limited.
This will avoid cases where you don't understand why 50% discount of $2000
SO shows $40.
4. If you archive a program and there is still some SO containing this program's
reward line, these line will be 'floating free' and will never be updated or
removed. Indeed, the `_remove_invalid_reward_lines` is basically checking
which programs could be applied on the order and which one are applied on the
order. If a program is applied on the order but is not supposed to, his
reward line will be removed.
Of course, since the program got archived, it won't get retrieve and the line
will never get removed. Even if the case of a free iPad: if you buy an iPad
and you removed the paid iPad from the SO. The free iPad will remain forever.
Note: We can't remove these discount line directly when archiving a program
because there might be quotations that we don't want to modify since it
is waiting for customer confirmation.
Improved behavior:
- Archiving a program archives its related reward product but unarchiving
the program does not unarchived the product.
task-1866977
opw-1832967
opw-1857843
Closes#2224
Comes with https://github.com/odoo/odoo/pull/24971
This commit adds the `website.multi.mixin` to coupon program to make it
multi-websites.
It also adds the website_id field in the views and adapt SQL constraint on code
which now became multi-websites friendly.
Applied 'o_row' class instead of 'row' to avoid indentation issue and
also applied 'button_box' name attribute to group to fix stat button
separation issue.
* get_report_values() is now private
* account_reports: make private most of the methods to avoid any leak
* account_reports: ensure the options dict cannot be forged to leak any multi-company info
* [FIX] account_reports: prevent inconsistencies between options and context
Was task: 1823127
Was PR #2399
Enterprise counterpart of this commit: https://github.com/odoo/odoo/commit/762adedece1c6c2b97b282348659c1b39b988d24
In enterprise the commit will also remove most of the features of website_quote_subscription because they became obsolete with the ability to create sections.
Indeed the feature was to automatically regroup recurring subscriptions in a "section" at the bottom of the documents. Now if the sale persons want that behavior they can just create an actual section.
Task #53996
PR #2276
* Update demo data sheet for barcode
* Modify product "Book: Office Renovation for Dummies:
- Name: "eBook: Office Renovation for Dummies"
- Image:
- Internal category: All/Services/Saleable
* Tips internal reference
* Product 10.0 % Discount =
- Name : "10.0% discount on total amount" (no space between 0 and %)
- Internal reference : 10PERCENTDISC
* Free product - large cabinet
- Should be a stockable
- in category All/Saleable/Office Furniture
- Name : Free Gift - Pencil Holder
- Picture
* Desk Customizable :
- Change its website sequence (should be displayed first in the shop)
* https://github.com/odoo/odoo/pull/25263
* Need to clean attributes and attribute values and attribute categories :
- Attributes, keep : Brand, Color, Dimensions, Legs, Weight
- Attribute Category : Rename Storage into "Material"
* Events
- Suppress Functional Webinar and Technical Training
* PoS Categories :
- Suppress
- Create PoS Category : Desks (put desks in it)
- Create PoS Category : Chairs (put chairs in it)
- Create PoS Category : Miscellaneous (and put all other products in it)
* Products available in PoS
- Remove : Air Flight, Car Travel Expense, Bpost domestic bpack 24h pro, Bpost World Express Pro, Customer Care, DHL USA Delivery, DHL USA -> International, Deposit, Expenses, Fdex International, Fedexs US, Hotel Accomodation, Restaurant Expenses,
* Product:
https://drive.google.com/a/odoo.com/file/d/1KjxcB88aDfe8qAzIpFlkBmMj5ekA9eIf/view?usp=drivesdk
Timesheet : description to update https://docs.google.com/spreadsheets/d/1nB8l8pFcRXRFnudgDJVyZZp3McaHNovlyvY0jE1ZZ54/edit?usp=sharing
* Project : less projects, more tasks
Remove "Internal - GAP Analysis", "Internal Projects"
Rename Support into After-Sales Services
Task to rename: Data import + Doc ==> Office planning
Move the task Internal Training from "Support" to "Office Design"
* AGR Project : add the following tasks and link it to the right SO line
Decoration : SO Line ==> Senior Architect
Planning : SO Line ==> Senior Architect
Furniture SO Line ==> Senior Architect
Furniture Delivery : not linked to an SO line
* Marketing Automation
Partnership offer ==> to rename into "Commercial prospection"
Steps to rename:
Offer free trial ==> Offer free catalog
After 7 days (if not yet partners) ==> After 7 days (if not yet customers)
Message for sale person ==> keep the same
* Mass mailings:
http://nimb.ws/zrKsZ9http://nimb.ws/CbNpwd
* Events:
Suppress Functional Webinar and Technical Training
Tracks to update : https://docs.google.com/spreadsheets/d/1sKkJrltXY3Gz7ue3mVysZxaWGybKpx5fIhgUBnhbNDs/edit?usp=sharing
* Helpdesk
Rename team into Customer Care
Create 2 tickets in default team
Urgent : Kitchen collapsing (assigned to admin) : link to the task SO053: [SERV_585189] Customer Care (Prepaid Hours)
No pririoty : Where can I download a catalog ? (not assigned). Ticket type = question
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [FIX] Update some title attributes for a11y.
* [IMP] Add aria-labels
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views
* [IMP] Add 'alt' attribute on 'img' tags
* [IMP] Add aria-label and title on icons.
* [IMP] Add dialog role on modals.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add role on alerts
* [IMP] Add role="button" on simili buttons
* [IMP] Use dialog role, header, main and footer tags for modals
* [FIX] Set all tabs aria-selected since we don't have proper script to set the attribute correctly.
* [IMP] Add widget, navigation or img role to aria-labelled items
Purpose of this commit is to enhance quality of templates proposed by Odoo
and make them use notification layout when send by emails. Those emails
are cleaner and more up to date compared to other emails.
Including
* revamping of coupon email to match current notification guidelines. It
was using a very strange and different design. We choose to standardize
it;
* use the light notification template to encapsulate coupon emails when
sending them by email;
This commit is related to task ID 51122 (and PR #2060).
Before this commit:
1. With a coupon set on 'specific_product', the discount amount was multiplied
by the product quantity twice.
(Introduced by a42c27f which apply discount on the full price by using
price_total (already multiplied by quantity) over price_unit.
2. With a coupon set on 'cheapest_product', the discount was not discounting taxes.
3. With a coupon set on 'cheapest_product' and `sale_coupon_delivery` installed, it
would simply crashes and throws an error since `sale.order.line` has no
`program_id` attribute.
Now:
1. We no longer multiply by the quantity twice;
2. We apply discount on the full price (with taxes);
3. We use correct attribute to avoid crash.
opw-1830986
Before this commit:
When you 'CONFIRM SALE', it would recompute the coupons just before
confirming the quote.
This would cause 2 issues:
1. You had no way to know what the generated SO will looks like (maybe unless
you know perfectly all the coupon promotions?).
You would end up with a 'surprise' SO that could be totally different from
the quote you just confirmed.
2. You had no way to cancel or prevent a coupon to be applied even if you
wanted to.
Eg: you don't wan't to offer this free forth iPad or this 10% discount to
that customer or this week.
Obviously, you could set all your coupons to be used with a code so the
recompute won't add any coupon to the quote but that would not make sense since
you would be limited to one coupon per SO.
At the end, there is a `UPDATE PROMOTIONS` on the quote which it's only purpose
is to recompute the coupons. The good practice would be to use that button
instead of using the confirm quote step to recompute the coupons.
Comes from #1967 (see review comment)
Fix the commit a42c27f99e0061b7c4f6597e4 which inverts the initial
filter. The change remove all sale order lines for the simple order
create in the backend.
opw-1819977
TWA