Reset view feature code still had remains of initial release (Odoo 9.0).
At that point all the view tree was returned, not only the broken view.
Since it has been fixed in 12.0 and refactored in saas-12.3 with this PR, it
now only takes the broken view as argument, handling multiple views has no
sense anymore.
Thus, this commit remove the (unused) multiple view compatibility.
This commit also add a test to test the refactoring or this feature.
Coming from #32009 (task-1943001)
Before this commit, when a t-call was calling an unexisting template, a QWeb
exception would be raised with the callee and not the caller as template.
That would be an issue since there was clean way to retrieve the view that did
the wrong t-call, for instance to be able to repair that view.
Now, in such a case the caller view will be returned.
That will avoid crapy code to retrieve the caller, eg searching on every Qweb
view archs.
Coming from #32009 (task-1943001)
- Store previous arch to be able to reset it (soft reset)
- Add the possibility to reset from file if possible (hard reset)
- Adapt frontend reset page to these new fields
- `arch_fs` hack to check if view was modified got moved to new field
`arch_updated` as we now need to keep track of the `arch_fs` to reset a
broken view.
Closes#32009 (task-1943001)
As there is a lot of arch fields, and those are not documented, it is not
always obvious to get the purpose of each fields.
This commit simply adds string helper on those.
It will be even more pertinent with the new reset view feature which adds two
new arch fields.
Coming from #32009 (task-1943001)
The error page does not use Odoo's assets, just bootstrap.css (the cursor might
be broken on the error 500 page so we can't use Odoo assets).
This commit mainly adapts the font-size and headings to fit Odoo style.
Coming from #32009 (task-1943001)
next_activity broken by a previous refactoring of js.
date picker broken by bs4 and JS don't handle local format.
closesodoo/odoo#32263
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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.
Jeremy Kersten