Steps to reproduce the bug:
Let's consider a product A with a price of 100
Let's consider a pricelist P with a visible discount of 50% on product A.
Let's consider a quotation template Q with one line with the product A with 50%
of discount.
Let's create a SO with pricelist P and set the quotation template Q on it.
Bug:
The unit price of A on SO is 50 instead of 100 and the visible discount is 50%
instead of 75%.
With the fix:
The unit price is 100 and the discount is 75%
opw:771996
After removing the `sha_in` params a while ago, we get rid of
the deprecated `token_field` option.
- Make `token_field` a model attribute, so that each model can easily
define the token field that should be used, and it does not need
to be passed around all the time anymore.
- Rename `_special_access_object()` to `_has_token_access()`, much more
readable since it returns a bool
- Do not forward the `attachment_ids` keyword arg to message_post,
as it sometimes contains unrelated IDs (the helper is not meant
to post attachments anyway)
- Update callers accordingly
Echoes commit c255342e8f
Before this commit, the image that was fetched for the quotes was the static one, preventing it to be changed
Now, the image is dynamically fetched
OPW 769701
closes#19417
sale_payment method to check or create a new transaction when paying
a sale order should be named _check_or_create_sale_tx and kept private
like account_payment one. Both versions exists. This commit fixes
the typo.
The 'View', 'Accept and Sign', 'Pay Online' buttons are now correctly
computed based on the sales settings or the online quote settings.
Indeed it is now possible to sign and/or pay quotations without having
website_quote module installed.
Online quote can now use the generic signature widget already used on
the standard sale customer portal. We therefore remove the custom
widget build in website_quote.
A route already exists to sign quotes; the old route is removed. The
existing route is overridden so that quotations with template requiring
payment cannot be signed. This is the expected behavior.
* website_quote should not override all sale links from the customer
portal to replace them by website_quote specific view. Indeed the
quote view should be used only if the order has an active template
defined on it;
* do not override existing columns of the order page view on portal
with same content;
* implement redirection at route level by overriding the
controller order route;
* separate signature and payment option from website_quote template
feature;
* add a settings to choose whether to display the confirmation or
pay buttons in customer portal;
* simplify settings about website_quote now talking only about
the module itself;
This commit only adds the settings and parameter. Future commits will
use those parameters to effectively trigger some features and hide or
display part of customer portal.
This generic widget allow to confirm and sign documents on the customer
portal. Purpose is to reuse it in sale customer portal and online quotes
notably. It is made generic to call a route using parameters given to the
widget. It also supports access token to ease its use in various customer
portal pages where the customer is not always connected but is granted
access through an access token.
- Fixed 500 errors when trying to display payment form because of variables partner_id/acquirer_id missing.
- Accepted credit cards are now display next to the acquirer name on the payment form
- e-commerce and website_quote create a transaction with its reference when the user click on Pay.
So we need to render the inputs when the user click on pay and submit the form with the values
- Online quotation and e-commerce now use the new payment form.
- Added the ability to chose on an acquirer if it uses only form/s2s or both.
(Still need some code cleaning)
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
Dominican team is focused on Transifex traductions using es.po,
as es_DO.po has a lot of issues in the website and reviewed strings
with wrong wording and mixing english and spanish. From now on
Dominican Republic will inherit es.po and just make specific changes
on github just in the needed words or setences that change base on
region.
Closes#18834
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)
Christophe Simonis