Purpose
The assignation method should always give the new conversation to the operator who
has the less active conversation.
If two operators have the same amount of active conversation, it should chose one of
them randomly.
We also want the visitor to get the same operator (if available) from its last visit.
Specifications
The method 'get_mail_channel' on the 'im_livechat.channel' model used a simple random.choice in
the available users to select the operator.
It was improved to select the operator that has the lowest number of open livechat sessions. If multiple
operators share the same number (lowest) of open livechat sessions, it selects randomly between those.
For the visitor to get the same operator as during its last visit, we save that information in a cookie (1 week lifetime), and give this optional parameter to the server when asking for the livechat session.
To make the code clearer, some methods were reorganize and convert from `api.model` to `api.multi` (ensure_one) to be more API-compliant.
Task-1919871
closesodoo/odoo#29888
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Like every changes in web client, and in the assets composition, "some
people" forget to update the specific assets of livechat.
Specific livechat assets allow to load a small part of odoo js
framework in order to be embedded on external website.
Task-1919871
Task #1919871
Purpose
=======
If a visitor comes on the website and launches a livechat, it will be randomly assigned operator A.
If he comes the next day and opens a livechat again, we want him to have the same operator if he's available.
To handle that use case, we added a cookie that stores the "previous operator id" information for 7 days.
Task #1919871
Purpose
=======
The method 'get_mail_channel' in the 'im_livechat.channel' model used a simple random.choice in
the available users to select the operator.
It was improved to select the operator that has the lowest number of active livechats. If multiple
operators share the same number (lowest) of active livechats, it selects randomly between those.
A livechat is considered 'active' if it has at least one message within the last hour.
Spec
=======
The assignation method should always give the new conversation to the operator who
has the less active conversation.
If two operators have the same amout of active conversation, it should chose one of
them randomly.
Purpose
=======
Several methods of the 'im_livechat.channel' model were passed a 'channel_id' to work on.
This has been changed so that the caller can use those methods on an instance of this model instead.
Some methods have also been switched to private because they had no apparent reasons to be public.
This is a preliminary cleaning for task #1919871
Specicial note for the "loader" template:
To load the livechat assets in a website page, the 'loader' template of livechat
is directly called (instead of being returned through a controller) in order
to avoid a new call to server.
As this commit moves 'sudo' to make method callable on the record directly, it
still needs to be sudo. First solution was to add the 'sudo' in the template, which
is a bad practise.
This commit creates a proxy method on website model returning the livechat info
with 'sudo'. This avoid having the 'sudo' done in template. Like always, explicit
is better than implicit.
Task-1919871
*: project, crm, maintenance, helpdesk,
It is useless to track fields during create since they
have no initial value and future tracking message will
show changes on tracked field.
We can log a default creation message instead
(as it is now if there is no mail_create_nolog context key)
This change will implies
- less queries when creating record
- cleaner creation messages
- less occurence of mail_create_nolog ctx key
Removing tracking at create could break the creation subtypes
mechanism (example: following task creation subtype on project)
Instead of using _track_subtype to give a subtype at create,
a new _creation_subtype method can be override. If a creation
subtype is set on a specific modlel, creation messages will be
create by message_post instead of _message_log.
We also need to adapt the message_track_post_template in order to
keep this feature whithout tracking.
Task: #1916916closesodoo/odoo#31945
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a pricelist could be easily misconfigured when
multi-company and multi-website were both activated.
Eg: website 2 is for company 1, create a pricelist and set website 2 and
company 2, it would make no sense and code would not behave as expected.
Now, we prevent this type of misconfiguration by ensuring a pricelist can't
have a website which is from another company than the company set to the
pricelist.
We also filter website in m2o widget to only show company's websites.
Closes#25109
---------------
With this new constraint, l10n module would need to force company:
l10n modules install will change the company currency, creating a pricelist for
that currency. Do not use user's company in that case as module install are
done with OdooBot (company 1).
Step to reproduce:
- Active multi-company and create a new company
- Switch to that company and try to install any l10n module not in EUR or USD
- It will create a new pricelist for that company for that new currency
- It will crash as module install are done as OdooBot which is in company 1.
It will search websites in OdooBot company (self.env.user).
It will then create the pricelist with company 1's website which is
uncompatible with the new company, thus raising the constraint.
closesodoo/odoo#31929
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* website
Review the blog layouts to
- Use cards where necessary to match the forum / event redesign
- Use correct bootstrap / HTML
+ Some minor improvements
task-1948882
closesodoo/odoo#31749
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- No cards for menus
- Use the grid system for better blog post card footers
- Correct grid system for blog list grid view
- Remove some useless custom css
- Restore 'groups' in xml data
- ...
Part of https://github.com/odoo/odoo/pull/31749
task-1948882
* website
Use real social colors which makes the blogs look more modern.
Introduce the colors for github, instagram and youtube.
Part of https://github.com/odoo/odoo/pull/31749
task-1948882
Review our blog layouts to follow the design we added for forum and
event (usings cards for records but not for menu + colored cards for
the right column). Also fixes some DOM/Bootstrap structures.
Part of https://github.com/odoo/odoo/pull/31749
task-1948882
* website
When the e-commerce is installed, you can now add a new snippet that can
be dropped anywhere: a search bar to search for products with an
autocomplete feature.
That snippet is also used as default "/shop" search bar. Finally,
you have the possibility to customize the snippet via snippet options.
task-1866973
closesodoo/odoo#30366
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
The mail.message.subtype model contains a field internal,
which decides if the messages are visible to external users or not.
Such a value should not be overriden at module update,
so all subtypes should be in noupdate.
opw 1946043
closesodoo/odoo#32214
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, when 'Inventory Valuation' was on 'Automated' and
'Costing Method' was on FIFO, the product cost field wasn't editable
anymore.
Now, it still editable in this configuration (other configuration aren't
affected).
Task #1937164closesodoo/odoo#31145
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Task #1891970
Original p. configurator commit d3530eb
Main purpose
------------------
The main purpose of this merge is to improve the product configurator usability by removing the "Configure a product" link to make it dynamic based on the selected product.
It also cleans the (website_)sale modules by moving the configurator specific code into its own modules: (website)_sale_product_configurator.
Detailed changes
-----------------------
Here is a more detailed list of the things done in this merge:
- 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)
- Since we now have the product_configurator in its own module, we can add a bridge module for the
website_sale to override the necessary controller routes in a cleaner way.
This commit adds the bridge module and move files and code around.
- The sale order lines will now always be editable directly from the tree view.
Installing some modules would force a popup form, which leads to a significant drop
in productivity when filling in multiple sale order lines.
- This commit will add an event configurator widget that will open a wizard when the selected product is
'event_ok'.
The widget will allow configuring the 'event_id' and the 'event_ticket_id' fields so that they can be safely
removed from the sale order line tree view.
The user can also edit the event configuration by using a button next to the product_id dropdown field
if the product is configured as 'event_ok'.
- The p. configurator now comes with a widget that is "o2m" like in the SO lines view.
The widget is only used on the added "product_template_id" field on the SO line.
This widget controls the opening of the configuration window and removes the need of a "Configure a
product" button.
The "SectionAndNoteListRenderer" is now cleaned from p. configurator specific code.
The widget is also responsible for handling the configuration provided by the p. configurator form
and applying it on the SO line with a 'field_changed' event that updates all the necessary fields.
- Added support for 'MULTI' and 'DELETE_ALL' operations on X2Many fields in basic_model.js
- 'MULTI' allows to batch multiple operations at once
- 'DELETE_ALL' behaves like 'DELETE' with all the current data of the field
- A message will be displayed when hovering a disabled attribute value's input to explain why it's
disabled.
e.g: Not available with Color: Black
This works for both exclusions within the product and exclusions from a reference product.
- The exclusions will work in both sides, if "black" excludes "metal", "metal" will also exclude "black".
- The "Customizable Desk" and "Conference chair" products now have some stock in the initial inventory
to avoid the stock warning when adding these products in a SO through the product configurator.
- The _name_search of product.template fallbacks by default on product.product
In case there are no product.products yet (dynamic product variants configuration), we need to
include the base product.template _name_search in the results
- The "ProductConfiguratorMixin" was named like that for historical reasons.
It had no direct link to the product configurator anymore since the latter was moved in its own module.
The ProductConfiguratorMixin was renamed to VariantMixin to avoid confusion.
This commit just move files around, there should not be any functional change.
Spec
=======
- remove "configure a product" from sale order lines
When the product configurator is active, replace the product_product_id by a product_template_id
in the sale order line. When we select a template without variants, it sets the variant automatically,
but when we select a product template having variants, it opens the configurator dialog.
- add a widget to modify the product configuration in the sale order line (next to product template field)
- UX improvements:
- Invert image and configuration in the main screen
- If the product doesn't have an image, hide it instead of showing the placeholder (only for first
screen?)
- new independent option in sales settings to activate product configurator.
(same in e-commerce)
- demo data: Change demo data to set Customizable Desk & Conference Chair as make to order
- If only one attribute value that is Custom, don't display radio, selection or even color box
- show exclusions in both sides in the configurator
-> SOLUTION: auto populate other way around (Black not for XL -> XL not for Black)
- don't allow to select an excluded value in the configurator (frustrating).
Replace with an uncomaptibility message on hover (e.g. Not available for Color: Black, Size: XL)
- apply the same mechanism for optional & suggested products: e.g. Not available for Customizable
Table (Color: Black)
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28310
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task #1891970
Purpose
=======
The name of the optional products displayed in the modal now change dynamically based on the selected
variants configuration.
You do not have to wait until the product is in the cart to see the full name anymore.
Ex: Conference Chair -> Conference Chair (Steel)
Task #1891970
Purpose
=======
The "ProductConfiguratorMixin" was named like that for historical reasons.
It had no direct link to the product configurator anymore since the latter was moved in its own module.
The ProductConfiguratorMixin was renamed to VariantMixin to avoid confusion.
This commit just move files around, there should not be any functional change.
Task #1891970
Original p. configurator commit d3530eb
Purpose
=======
- The p. configurator now comes with a widget that is "o2m" like in the SO lines view.
The widget is only used on the added "product_template_id" field on the SO line.
This widget controls the opening of the configuration window and removes the need of a "Configure a product" button.
The "SectionAndNoteListRenderer" is now cleaned from p. configurator specific code.
The widget is also responsible for handling the configuration provided by the p. configurator form
and applying it on the SO line with a 'field_changed' event that updates all the necessary fields.
- Added support for 'MULTI' and 'DELETE_ALL' operations on X2Many fields in basic_model.js
- 'MULTI' allows to batch multiple operations at once
- 'DELETE_ALL' behaves like 'DELETE' with all the current data of the field
Spec
=======
- remove "configure a product" from sale order lines
When the product configurator is active, replace the product_product_id by a product_template_id
in the sale order line. When we select a template without variants, it sets the variant automatically,
but when we select a product template having variants, it opens the configurator dialog.
- add a widget to modify the product configuration in the sale order line (next to product template field)
- UX improvements:
- Invert image and configuration in the main screen
- If the product doesn't have an image, hide it instead of showing the placeholder (only for first screen?)
- new independent option in sales settings to activate product configurator.
(same in e-commerce)
- demo data: Change demo data to set Customizable Desk & Conference Chair as make to order
- If only one attribute value that is Custom, don't display radio, selection or even color box
Before this commit, you could specify putaway rules for service type
products, but as putaway is useless for services, we don't want that.
Task #1961021closesodoo/odoo#32199
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Task 1942984
Add a warning to alert for partner duplicates based on VAT number
When we create a new partner with an existing vat number, on change from vat number --> trigger a warning,
closesodoo/odoo#31597
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
*: crm, project, maintenance, hr_recruitment
When a record is created from an email, cc can be lost. This commit
proposes a new mixin to keep cc on the record and allows to create
partner for each of them when sending a message from the chatter.
The mixin is added on the mail recors that can be created from mail.alias:
document
helpdesk.ticket
mrp.eco
quality.alert
hr.applicant
crm.lead
project.task
mail.channel
maintenance.equipment
A new show more/ show less mechanism is also added to the partner suggestions in chatter.
Task: 1925001
Linked PR: odoo/enterprise#3689closesodoo/odoo#31275
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: crm, project, maintenance, hr_recruitment
When a record is created from an email, cc can be lost. This commit
proposes a new mixin to keep cc on the record and allows to create
partner for each of them when sending a message from the chatter.
The mixin is added on the mail recors that can be created from mail.alias:
document
helpdesk.ticket
mrp.eco
quality.alert
hr.applicant
crm.lead
project.task
mail.channel
maintenance.equipment
Task: 1925001
When sending a message from chatter, a list of suggested partners appears
on the top of the text area. With the previous commit,
cc will be added to this list. This commit adds a show more/show less
button in case there is more than 3 suggested recipients to display.
Task: 1925001
Purpose: The quantities to consume on Bill of Material lines should be
either strictly used or be taken as a reference more or less adjustable.
This commit adds a setting on BoM to specify if the consumption is 'strict'
or 'flexible'. This new option has the following impacts:
On produce wizard: if consumption is set to 'strict', the done quantities
are prefilled and checked when saving the wizard. If set to 'flexible',
the production flow remains the same as present one.
On workorders: if consumption is set to 'strict', the Validate button
will save the consumed data, and propose to fill the remaining ones until
the total is registered. If set to 'flexible', two button are displayed.
'Validate' to register the current component and pass to next step either
the quantity to consume is complete or not, and 'Continue Consumption'
to registered the current component quantity but leaving the user the
possibility to add more quantity (and possibly another lot number) for
the current component
This commit also revert partially d3617fd852
as the warning become some sort of an error
Task: 1889393
The attribute is true by default, but when it is set to `false`
in a test, it was not correctly passed in the view.
Note that it has no impact currently in the tests.
closesodoo/odoo#32175
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Since we now have the product_configurator in its own module, we can add a bridge module for the website_sale
to override the necessary controller routes in a cleaner way.
This commit just adds the bridge module and move files and code around, there should not be any functional change.
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
=======
Commit 92b9e3684607fbb0c9a7d3f2331292eac51ebdea removed the SO line popup form and added all the event
information fields directly in the sale order line tree view.
The event information should be hidden by default because they are only relevant for 'event_ok' products.
This commit will add an event configurator widget that will open a wizard when the selected product is 'event_ok'.
The widget will allow configuring the 'event_id' and the 'event_ticket_id' fields so that they can be safely removed
from the sale order line tree view.
The user can also edit the event configuration by using a button next to the product_id dropdown field
if the product is configured as 'event_ok'.
Purpose
=======
The sale order lines will now always be editable directly from the tree view.
Why?
- Installing some modules would force a popup form, which leads to a significant drop
in productivity when filling in multiple sale order lines ;
- The next version of the product configurator will only be compatible with inline tree view editing.
Targets commit d3530eb07e
References task id 1891970
Purpose
=======
- A message will be displayed when hovering a disabled attribute value's input to explain why it's disabled.
e.g: Not available with Color: Black
This works for both exclusions within the product and exclusions from a reference product.
- The exclusions will work in both sides, if "black" excludes "metal", "metal" will also exclude "black".
Before this commit, when opening a website livechat window,
it crashed with the following error message in the dev tools:
```
Cannot read property 'html' of `undefined`
```
The problem was caused by the rendering of the chat window header
before the chat window widget is even mounted in the DOM. This error
has been introduced by the migration from jQuery 1.12 to 3, in which
most occurrences of `$.Deferred` have been turned into `Promise` [1].
`Widget.appendTo()` returns a `Promise` (was `$.Deferred` before).
A `Promise` is always asynchronous, whereas a `$.Deferred` with
jQuery 1.12 may be either synchronous or asynchronous. In the case
of the website livechat window, the implementation with `$.Deferred`
was always synchronous, which is no longer the case now.
[1] https://github.com/odoo/odoo/commit/126fb33f6a74916c808c8e988f55faf82f0b5759closesodoo/odoo#32168
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Usecase to reproduce:
- Go on a Mo
- Edit and Unlock
- Produce the MO
- Update a raw move and add a move line
User error you quant write on product_qty fields.
product_qty represent the reserved quantity on move line as quant's UoM.
The system requires to write a product_uom_qty that represent the same
quantity but in the move line UoM.
Fix it by removing the fields from the view, so it's no more save.
Also set the quantity done as readonly if the lines are present in
the view.
closesodoo/odoo#32135
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Targets commit d3530eb07e
Purpose
=======
- The "Customizable Desk" and "Conference chair" products now have some stock in the initial inventory
to avoid the stock warning when adding these products in a SO through the product configurator.
This feature was already working in the actual version of Odoo but it is now tested. The following
features are supported:
- When the value of one widget is modified, the other ones change accordingly
- The modifiers 'invisible' and 'readonly' are applied correctly if they differ between widgets.
However, the modifiers 'required' must be equal for the several fields, otherwise the behavior
is not guaranteed.
closesodoo/odoo#32158
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit ensures the qty_to_consume is always adapted to be the same
as qty_done in the onchange on qty_processing. This patch is needed to
keep the same behaviour before and after the workorder line refactoring
5ef46664a2
Now that we don't take into account the legal leaves, it should be hiddden when the number of leaves is equal to 0 instead of 20.0
closesodoo/odoo#32125
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
moment().locale('en').format('YYYY-MM-DD')
"2019-03-25"
moment().locale('ar').format('YYYY-MM-DD')
"٢٠١٩-٠٣-٢٥"
moment().locale('my').format('YYYY-MM-DD')
"၂၀၁၉-၀၃-၂၅"
Was rejected as a valid bug at moment/moment#4448
Apply the same logic than 109b319d64Fixesodoo/odoo#32081closesodoo/odoo#32102
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Robot Odoo