9a07a459 added "override=True" to silence a Sphinx warning in about
the address node already existing, however the override=True parameter
was added in Sphinx 1.4 (alongside the warning), so this breaks in
1.2.
Only pass in override=True if we're in 1.4 or later.
Closes#18232
There was a problem with the new `ajax.loadXML` implementation
introduced with 417a664f16
Indeed the following case was buggy:
```
ajax.loadXML('URL1', qweb);
ajax.loadXML().then(function () {
ajax.loadXML('URL2', qweb);
});
```
With this code, 'URL2' is scheduled to be loaded when 'URL1' is fully
loaded. The problem is that the deferred returned by the call to
`ajax.loadXML` without argument was resolved before the internal
`isLoading` variable was reset to `false`. So, the loading of 'URL2'
was indeed scheduled when 'URL1' was fully loaded but its loading
never started because the `ajax.loadXML` loading loop was still marked
as running (so it was not started again as it should have been).
fixed cases:
1) having more than one account.move.line with a residual amount. This can easily be achieved by
-make a first invoice
-partially pay it
-make a second invoice
-partially pay it
-make a payment of the remaining amount
-reconcile the lines together
2) having more than one foreign currency involved, with several ecxhange difference to book
Purpose
=======
Issue: Product_id field should be visible only when product has more than one variant
Here's how it can be reproduced,
Assign user with group group_product_variant
Create a product without any variant
In this case, the product_id field won't be shown in product.template's internal form view for product.supplierinfo, that's working fine. But, now, as this fix is reverted, the product_id field will be visible in product.template's internal tree view for product.supplierinfo.
Adapt sale.order model in order to use the recently introduced portal
mixin :
* website_url field is replaced by portal_url field defined in portal
mixin; _compute_website_url is replaced by _compute_portal_url that
does basically the same computation;
* get_mail_url method used in emails now uses the get_share_url of
portal mixin;
This mixin holds the replacement for website_published.mixin
website_url field. This field is called portal_url to avoid confusion
with the website and enforce the new portal use.
It also contains get_share_url method that will be used to generate
the URL to use in emails or various communication for customers.
Purpose
=======
Terms are confusing in the deferred revenue app.
Specification
=============
- Rename label "Depreciation" -> "Revenue" in Deferred Revenue Lines wizard
- "Time method" in asset.categories shouldn't show "Number of Depreciation" but "Number of entries" instead
- In Customer Invoice visible field "Deferred Revenue Type" without developer mode
- All the menu related revenue will have same menu name "Deferred Revenues"
- Module name change to => "Deferred Revenues"
- Change module name : "Deferred revenue management for contracts" to "Deferred Revenues Management for Contracts"
- Change the label in time method 'Number of Depreciation' -> 'Number of entries'
- Also change the tooltip on Time Method
- Show Product(product.supplierinfo) field when product has more than one variants.
- Improve tooltip on Product(product.supplierinfo) and 'Cost'(product.template) fields.
- Hide 'Cost'(product.template) field when product has more than one variant
Purpose
=======
1. There is some confusion between the vendor price and the cost price of a product. The goal of this task is to clarify it for users.
2. Some users would like to set up vendor prices specific to a variant, the goal of this task is to allow them to do that.
Specification
=============
- Add a clear tooltip on the Cost field (standard_price) : "The cost price is used to valuate your inventory."
- When creating variants, it is impossible to set the cost of the product variant, it always resets to 0. It should be hidden if the product has some variants
- Add product_id o2m in vendors form, tree view on product template, and same field should be displayed on variant form view (the field is not required)
- Product_id field visible only when product has more than one variant
- Add a tooltip on this field : "If not set, the vendor price will apply to all variants of this products."
- Vendor price calculation for automated generated RFQ (should be based on sequence: take the first vendor price that matches all the conditions)
Purpose
=======
Projects and soon sales teams have a manual "favorite" button that calls a toggle_favorite method
It should actually be a widget on a boolean field
Specifications
==============
Develop a favorite widget for kanban view that allows to toggle a boolean field
Probably update boolean field to allow inverse method on it
Functionally nothing changed.
- Move Leads under new section Pipeline.
- Move Phone Validation and Customer Autocomplete under new section Contacts.
- Move Asterisk (VOIP) under new section Integrations.
The previous line in a loop calculates the number of queries made until
the end of the loop. This causes the number of queries to be counted
twice.
Don't blacklist the entry point method.
Check the methods called from a blacklisted method.
* Add a warning on the employee form view when the home address has a
company linked
* Get email, phone number and mobile number from the application
form when creating an employee from there
* [IMP] account, account_accountant: Move 'tax_cash_basis_journal_id' field from 'account_accountant' to 'account' module.
* [IMP] account: Few improvements in accounting settings,
- Set 'Invoicing' section as a last section.
- Add checkbox 'Cash Basis' in settings and make it company dependent and add multi company's icon to it.
- Disable the 'Tax Cash Basis Journal' field if 'Cash Basis' not active. Also add tooltip on 'Cash Basis'.
- Visible/Invisible 'Use Cash Basis' field in 'Taxes' form view based on 'Cash Basis' settings from accounting settings.
- Don't allow untick 'Cash Basis' settings if there are taxes using the configuration.
- When any CoA is installed which is creating taxes with configuration 'Use Cash Basis' set then make the 'Cash Basis' option in accounting settings checked by default.
Was PR #16516
Purpose
=======
You install CRM but you don't see CRM icon (except in English, as long as sales is not installed) -> confusing
The dashboard with salesteam is not obvious & not useful for simple users: what are those channel boxes about? why don't I see all my activities?, etc.
Specifications
==============
Split CRM & Sales + land in business views straight away
Default Entry Views
~~~~~~~~~~~~~~~~~~~
- New default view for CRM: Pipeline kanban
- New default view for Sales: Quotation list
Dashboards
~~~~~~~~~~
- Move sales teams dashboard to Reporting: Sales Channels.
- Remove the upper part of the sales team dashboard
Menuitems Structure
~~~~~~~~~~~~~~~~~~~
- CRM menu
Pipeline:
- Leads (optional)
- Pipeline (default menu, default filter "My Pipeline")
- Next Activities -> to remove (now there is an icon in top bar for next activities)
- Quotations (If sale_management installed)
Customers
Phone Calls (if voip, if not yet removed because there is a BE task to use next activities instead)
Leads Management:
- Scoring Rules
- Leads Assignation
- Team Assignation
Reporting:
- Leads
- Scoring page views
- Opp. Assignement
- Patnerships
- Pipeline
- Activities
- Phonecalls
- Sales Channels
Configuration:
- Settings
- Sales Channels
- Activity Types
- Leads & Opportunities:
- Lead Tags
- Lost Reasons
- Resellers
- Partner Level
- Partner Activations
- Sales menu:
Orders:
- Quotations
- Orders
- Customers
Invoicing:
- Orders to Invoice
- Orders to Upsell
Catalog:
- Products
- Promotion Programs
- Coupon Programs
Reporting:
- Sales
- Sales Channels
- All channels sales orders
Configuration:
- Settings
- Sales Channels
- Sales Orders:
- Quotation templates
- Payment acquirers
- Delivery Methods
Settings
~~~~~~~~
- Split settings form
- Remove recommended apps section
- Remove Timesheets section
- Remove Inventory Management and move shipping connectors to Shipping section
- Remove Integrations section
- Move Docsaway option to "Quotations & Orders", right after proforma
- Autocomplete and asterix: move to CRM section
- Restructure and rename sections this way:
- Product Catalog
- Pricing
- Quotations & Orders
- Shipping
- Invoicing
- eBay (if installed)
- Remove all the "Save this page and come back here" when checking a box that installs a new module
- restructure a bit the CRM settings, with 3 sections:
Pipeline
- Leads
Contacts
- Phone Validation
- Customer Autocomplete
Integrations
- Google Calendar / Synchronize your calendar with Google Calendar (copy from general settings but don't show message "Save this page and come back here...".
- Asterisk (VOIP)
This merge make the customer portal available independently from website
module. This implies moving some routing features from website to a new
http_routing module. Customer portal is located in a new portal module.
Sale and account customer portal are moved directly into sale and account
module, and in sale_payment and account_payment for the online payment
part. Most of website_payment code is moved to payment as it holds
customer portal features related to payment.
This merge removes website_portal, website_portal_sale and website_account
module.
This closes#17100.
Customer portal controller and templates contained in website_payment
module are moved to payment. This module now uses the customer portal
defined in portal module and most of website_payment code is moved
to payment.
website_payment now contain code really related to website, such as
payment acquirers configuration for website.
This commit adds a new bridge module between account and payment. This
module is used notably to display payment related information on account
customer portal. It currently holds only a template but future commit
will add new features related to invoice payment on customer portal.
As already done for sale, customer portal for account is moved to account
module directly. Account now depends on portal module and website module
is not necessary anymore to display the account customer portal.
Customer portal is now a feature coming directly with sale module. As
it uses a simple website renderer customization and advanced website
features are not available and depends on having website module
installed.
website_portal_sale contains code on sale.order and crm.team models
related to payments. This code is moved into the sale_payment module
that is the bridge between sale and payment and therefore is the
location where it belongs. First step toward removing content of
website_portal_sale module.
This commit moves the whole customer portal to the portal module.
It now completely uses portal and http_routing features and is not
dependent on website anymore.
An override of web controller is added in portal in order to redirect
portal users to /my instead of /web. That way once having the customer
portal installed all share users are correctly redirected to their
account.
All modules defining customer portal templates and controllers are
updated accordingly.
website.layout is now based on portal.frontend_layout template. Using
inheritance it adds and replaces various nodes in the portal template
in order to have the same behavior in website as before.
Let us completely support auth_signup_token and auth_login in request
session and parameters in the auth_signup module instead of in various
separate places.
As customer portal will be moved to portal module support of pager
has to be moved previously to the various portal moves. This commit
moves the pager code and template to portal.
Compatibility using website-based pager is provided to avoid having
to update all website addons currently. Future commits will make
addons use the portal pager instead of website pager.
Code managing language in URLs and redirection is moved from website
to http_routing. Override of _dispatch in website now consists in adding
website to the request.
url_for and is_multilang_url tools methods are also moved from website
to http_routing.ir_http as those are required for the moved code.
Some renaming is performed on request attributes previously added in
website. Indeed as website keyword may be misleading now a renaming
has been performed to better understand them :
* request.website_enabled -> request.is_frontend
* request.website_multilang -> request.is_frontend_multilang
* request.httprequest.cookies.get('website_lang') -> ('frontend_lang')
* first_pass variable in _dispatch is replaced by a new attribute of
request, routing_iteration, that is the number of routing iterations
currently done
Since commit 417a664f16:
The `ajax.loadXML` function has been refactored and improved so that
multiple calls to the function with the same URL only loads it once
and so that the deferred which is returned really indicates the status
of loading this particular URL.
Unfortunately, there was a mistake: when loading the same URL twice,
the second call always returned an already resolved deferred if the
first call to `ajax.loadXML` was done with this URL.
ir_http override in website manage languages through methods or attributes
directly defined on website model. Those methods are get_languages method
and default_lang_code attribute. In order to be able to have a translation
layer independent of website we have to have access to this data without
depending on website record.
This commit solves this by adding class methods on ir_http override
located in http_routing. Basic implementation comes directly from website
default methods _active_languages and _default_language. Website overrides
those methods in order to be based on website values defined through
language_ids and default_lang_id for available languages and default
language.
Website behavior is therefore untouched whereas http_routing implements
a basic default behavior. This commit updates ir_http code in website
to use those methods and ease next commits which will move parts of that
code.
Slug and unslug API is now available in http_routing. Indeed there is no
link to any website or any reason to not support slufigied URLs when
website is not installed. A new unslug_url method is added as a tool
coming from an embedded method from website. Doing it allows to have all
slug related methods defined at the same point.
Support of slug and unslug in qweb rendering is also moved directly in
http_routing version of ir_ui_view instead of website inheritance. This
is done in order to keep things coherent.
Some code from website about ModelConverter is also moved. Indeed both
versions of ir_http uses some kind of placeholder to store the uid
when converting urls to python. This commit unifies it by using the
website one directly in base to simplify the override.
This commit also updates all module importing slug. Enterprise modules
will have to be updated, see related commit.
This module adds required base code for a fully integrated customer
portal. It contains the base controller class and base templates.
Business addons will add their specific templates and controllers
to extend the customer portal.
This module contains most code coming from odoo v10 website_portal.
Purpose of this module is to allow the display of a customer portal
without having a dependency towards website edition and customization
capabilities.
Some CSS files used in frontend assets are already moved to have a
working portal skeleton. A is_public method on users is also added
as it will be used in various portal code soon.
This module will contain http routing capabilities that are not
necessarily linked to a website. This covers for example code related
to language management in URLs or slugify support.
Advanced http routing are not moved in base in order to keep the core
simple. It is not moved in web because this module should contain only
interface and not http / routing code. http_routing module will therefore
be used to hold those features.
This commit only adds a void module, future commits will gradually add
the various features through dedicated MOV commits.
Moisés López