=======
This PR is in the continuity of odoo#62360.
- Display remaining hours in task sales_line_id (name_get + task form view)
- Remove internal reference from services demo data
- Display sol in project timesheets list if project is billable
- Remove use of non_allow_billable in timesheets as it has been removed from project and task in previous PR (see above)
- Only recompute planned_hours for service product
- Determine the correct SOL for timesheet
- Set the last SOL of customer on timesheet if none is set on task or project
- Allow edition of so_line in timesheet
- Restrict SOL on project to sale lines with a service product
- Use same widget on partner_id many2One than in sale.order (using ranking)
- Remove timesheets table in SO and invoice portal.They were added in previous PR (see above). This introduces the use of links to /my/timesheets/.
- Review portal timesheets (my/timesheets/ and link from orders and invoices)
- Activate group_uom "Units of Measure" on sale_timesheet install
- Hide partner phone number in task form view
- Only determine SOL of task and timesheet if allow_billable=True
- Filter SOL in task so that it matches the SOL of the project SO
- Display red label if remaining hours is negative
- Change SO compute behavior
- Only open SO for salesman on project overview
task-2409761
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closes odoo/odoo#63695
Forward-port-of: #62900
X-original-commit: b1985773f3a67e28049f9e2bb635bcab059ad9c0
Related: odoo/enterprise#15427
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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
Currently, when the payment is done by the wire transfer or by sepa
then the transaction is going to be in the 'pending' state and due
to that confirmation mail will display the button as
'Sign and Pay Quotation' but is should be the 'view quotation'.
So in this commit we check for the last transaction and if transaction
status is 'pending' then display the 'View Quatation' instead of
'Sign and Pay Quatation'.
We have not modified method has_to_be_paid because it's used to display
the button on portal so still it will display the 'Sign and Pay' on portal.
closes odoo/odoo#49389
Taskid: 2210990
Closes: #49389
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the task is, we have added the activities on various
listviews, the goal of this task is to update SO/PO/invoice demo data
with activities and also set tags on sales orders.
So in this commit, We added the activity on several SO/PO/Invoices and
also added the some tags one sales order and set the user as False
where the user is set as 'Odoobot'.
closes odoo/odoo#51799
Taskid: 2254708
Closes: #51799
Related: odoo/enterprise#10743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Install "Sales" and "eCommerce"
- Activate debug mode
- Go to Settings->Technical->Email->Templates
- Search and open "Sales Order: Confirmation Email" record
- Click on stat-button "Preview"
- Select a "Sale Order" sample with product(s)
The quantity column label is not in the right place/column.
Cause
Each row of the table is a table.
Solution
Add same fixed column size css on each table.
opw-2242914
closesodoo/odoo#51380
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Website sale order confirmation email is broken by design. Indeed it has
jinja markers between html elements that do not allow them, like between
table and tr, between tr, ...
In this commit we completely rewrite the structure to correctly include
jinja markers where they are not moved or stripped by standard browsers
and editors.
Translations are updated accordingly as changing a mail template content
imply updating the whole body translation.
Followup of 74c5c00
website_sale: add website on some demo orders
Purpose is to showcase orders using website field, used notably for some
template rendering.
Forward port of afd173652214000ed and f74c86d448246b796d
closesodoo/odoo#48228
X-original-commit: d3bdb0a42eb052281b4652bf78e82b1c6c1c1d24
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The default invoicing policy should be based on the delivered quantities
by default because:
- In countries with anglosaxon accounting, that's mandatory
- Even for other countries, it's probably as frequent as the "based on ordered"
quantities
Task 2159161
closesodoo/odoo#47526
Related: odoo/enterprise#9355
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In Sale, there is a view called oezirhgoi which adds the sign and pay
online buttons (xml id sale.mail_notification_paynow_online)
So rename it with the 'Quotation: Sign and Pay mail notification template'
closes odoo/odoo#46954
Taskid: 2196751
Closes: #46954
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In this commit,
-Change the price of the three-seat sofa 60.000 to 1.500
-Change invoicing policy based on ordered qty
closesodoo/odoo#41980
Task-id: 2153140
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
* = point_of_sale, sale_management, sale_product_configurator, stock,
website_sale, website_sale_comparison, website_sale_wishlist
- Remove Attribute Values menu to ease onboarding because everything can be done
more cleanly through Attributes menu.
- Remove unwanted new lines from help texts.
- Hide color fields when attribute type is not color.
- Move Attribute "Related Products" into a tab because it is less important than
the rest of fields.
The opportunity is also taken to rename the `type` field of `product.attribute`
to `display_type` to better convey its meaning.
task-2058142
closesodoo/odoo#36313
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* account, hr_expense, mrp, sale, sale_product_configurator, stock_account,
website_sale, website_sale_comparison
Before this commit, the `product.attribute.value` were stored on the variants.
This required filtering of attribute lines to find the appropriate matching
`product.template.attribute.value` that were used in most of the business code,
such as when computing the `price_extra`.
This also prevented to have multiple attribute lines for the same attribute,
which is needed to handle use cases such as grape varieties for wine products.
This will be done in the following commit.
After this commit, the combination of `product.template.attribute.value` will be
directly stored on the product variant.
Other changes
=============
Add `combination_indices` on product, which allows to quickly find a variant
matching a combination (1 simple indexed equality query as opposed to 1 query
with as many joins as there are attribute lines), and to add an easy
SQL constraint to ensure active combination uniqueness.
Add active field on `product.template.attribute.line` and
`product.template.attribute.value`, with the same behavior as variants:
They become archived if they can't be unlinked. This allows to keep the database
consistent, such as archived variants correctly keeping all their values, sales
order lines keeping their custom and no_variant. This is done with the help of
`ondelete=restrict` on the corresponding m2m fields, and the `unlink` methods
falling back to archiving when `unlink` is restricted.
Part of task-1912579
PR: #32946
* pos_sale, sale, sale_crm, sale_management, sale_stock, website_sale
Purpose of this commit is replace the confirmation date field with
order date from sale. As order_date and confirmation_date of sale order
are having same value so no need to keep two fields, remove confirmation
field and instead use order date.
cretae_date use as order Date and replace the order_date on confirmation
of the order as confirmation date.
task-2027274
closes: #34571
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
There is a confusion with SO when it comes to payment ref. 'SO001' is too
visually to close to 'S0001'.
And wrong payment ref don't help the user reconciling the payments.
So, changed the prefix in default sequence of sales orders from 'SO' to 'S'.
task-2033229
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
This commit improves the ux in CRM by changing a few things:
- Restore the use_leads and use_quotations fields
along with their features as they were in 12.0.
- Hide the email alias if use_upportunities and use_leads
are unchecked.
- Show a link to the general settings instead of the alias_domain
if no alias_domain has been configured.
- fixes the "unassigned lead(s)" link so that
it redirects the user to the actually unassigned leads
Task: #1962182
PR: #32372
For the model 'sale.order'
- Set the action menu 'Share' only for the form view of model.
- Rename the action menu 'Invoice Order' by 'Create invoices' and set
only for the list view.
- Rename the action menu 'Send a Cart Recovery Email' by
'Send cart recovery email' and set it only for the list view.
Also improved tour 'shop_cart_recovery' as now action menu only
available on the list view.
Linked to task 1984526
Related to PR #33720
Replace the email template content form if you have any question to if you have any questions.
task-1962924
Closes#33520
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Purpose of this commit is to send the order and payment details email to user
when they purchase any order from ecommerce or when do the payment from
portal. Currently it was sending quotation mail when the payment is processed.
Now it send an email for quotation, and one email for sale confirmation that
may contain more detailed content if coming from website (eCommerce).
In sale
* create new confirmation template and set the default template in sales
settings;
* when payment enabled in sales settings then display template option to send
default confirmation mail when payment is processed or order signed;
* add tool method to find the right template to use when sending the
quotation / SO by email;
* ensure email is sent everytime SO is confirmed;
In website_sale
* add option in website setting in order, to set the confirmation mail
template;
* ensure email is sent everytime SO is confirmed;
Related to task ID 1873634
Linked to PR #28781
- set field 'portal_confirmation_sign' to true by default and removed from demo data where it sets to true.
before this commit:
without demo data 'online signature' setting is false by default.
after this commit:
'online signature' setting is true by default with or without demo data.
Related to Issue: 1946116
closesodoo/odoo#32360
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This field is a non-sense. By using the same logic, it should be added
to any low level model.
Replace the check by a simple verification of presence of an XMLID.
A more generic opt-in solution should be integrated into ORM.
Partially revert commits 0db0e66e96 and
bbd64c22ab.
See #29257odoo/enterprise#3550closesodoo/odoo#31778
Signed-off-by: Christophe Simonis <chs@odoo.com>
Purpose
=======
- Moved the product_configurator into its own module now that we have a specific option for it.
The option only enables the p. configurator in the SO form.
The e-commerce should always allow customer to configure their products, even if the option is not checked.
This allows moving some of the code specific to the p. configurator into its own module.
However, a lot of the code has to remain in "sale" module since the e-commerce does not require the option
checked and needs the "configure product" feature in the shop by default.
(This is why the fields "product_custom_attribute_value_ids" and "product_no_variant_attribute_value_ids"
are still in the "sale" module)
Purpose of the task is some demo data values are not matching with the products
mentioned so update the demo data values with matching product.
Task: 1892754
closesodoo/odoo#28573
Since commit 34c47eecd3 wording of link when
sending a quotation by email is broken. Indeed has document in draft is
not correctly considered as having to be signed and/or paid the link is
not labelled correctly.
This commit fixes it. Parameter is also renamed to be more understandable.
This commit is linked to task ID 1910532 and PR #29849 .
closesodoo/odoo#30953
Purpose of this merge is to update main addons and set activity types used
for automated activities as master data. This means they cannot be removed.
Indeed those activity types are used in business flow to generate activities
and removing them may break some flows.
This commit is linked to task ID 1907970 and PR #29257.
- Create a SO, keep it as draft
- Click on 'Send by Email'
The name of the attached PDF file contains `_draft`.
This doesn't really make sense anymore, since the SO will be set to
'Sent' right after sending. Therefore, if sending a second time,
`_draft` won't be added to the filename.
opw-1930282
closesodoo/odoo#30367
Since commit 34c47eecd3 wording of link when
sending a quotation by email is broken. Indeed has document in draft is
not correctly considered as having to be signed and/or paid the link is
not labelled correctly.
This commit fixes it. Parameter is also renamed to be more understandable.
This commit is linked to task ID 1910532 and PR #29849 .
This commit has several parts:
- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)
================================================================================
*** Make consistent the filtering and ordering of product variants ***
Filter & Check possibility
==========================
The first variant shown on the website should always be possible.
When activating the customize "list view of variants", we don't want to show
impossible combination on the list.
We also don't want the user to be able to add to cart an impossible variant.
Show appropriate messages when no combination is possible.
Order
=====
We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.
This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value
The general order is now: (parent,) sequence, id.
Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.
On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.
Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.
================================================================================
*** Fix product template and variant price computation ***
Move and improve the get_combination_info method:
- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset
================================================================================
*** Fix currency conversions ***
The list_price and lst_price of a product are always encoded using the currency
of the product.
The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.
The prices on an order (line) are encoded with the currency of its pricelist.
================================================================================
*** Fix dynamic variants access rights ***
Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".
This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.
================================================================================
*** Miscellaneous bugs, tracebacks and necessary improvements ***
In general:
- correctly show warning when no variant is possible
- don't let user add to cart an impossible variant (from optional product
modal or from any RPC), both in interface and controller logic
- fix as much flickering as possible by correctly pre-computing in python/views
- move business logic from controllers to models
- correctly add no_variant and is_custom values on the SO line description
Sale order:
- fix traceback when emptying the product_id field from configurator
website_sale:
- correctly compute first image / carousel, and correctly swap images when
changing variants, without duplicate image or zoom problems
- don't use list view of variants when it doesn't make sense
- added missing product info when adding a no_variant attribute to cart
- fix cart accessory product computation
website_sale_wishlist:
- fix it with dynamic variants, no_variant and is_custom
website_sale_comparison:
- fix it with dynamic variants (comparison and alternative products)
website_sale_stock:
- fix it in general (some flickering still present)
================================================================================
Authored by @seb-odoo with contribution from @awa-odoo
task-1910821
closesodoo/odoo#28079
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
Improve various design elements in sales onboarding and config bar :
Onboarding :
- tooltip and done button
Company info:
- Move the incoterm field from company view to account settings.
Document layout:
- layout widget relabelling and reorganizing
- paper format as required
- added a Preview button
Payment methods and sample quotation :
- Style and relabelling
Notably
* remove cdata and fix html code when necessary;
* re-order fields declaration to have globally the same order in various
template definition;
* remove unnecessary reply-to, make user signature and auto delete fields
explicit when necessary;
* improve some name to ease template ordering and understanding in the
template list view;
Related to task 1972615
Linked to PR #32872
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose: use more email_formatted when possible, clean and simplify
email_from, email_to and partner_to computation.
Next step is to try to extract some common patterns in tools or methods in
order to simplify template creation and customization.
Related to task 1972615
Linked to PR #32872
Rename the attachment file name.
Restore the option : have the name of the customer who viewed the quotation on the email notification
TaskID: 1920476
closesodoo/odoo#30550
Before this commit, the template that was rendered when sending
an email to a customer to invite hime to pay online
was not translatable
This was because the override of the template did not have an xml_id
After this commit, it is translatable
OPW 1944258
closesodoo/odoo#31396
fw-bot