* account, maintenance, mrp, payment, point_of_sale, sales_team
Previous system was:
- `flex: 1 1 300px;` on kanban records
- If a specific record needs a different size, add custom style to
either change the `flex` rule or set a `min-width` for >=SM screens
Now:
- `flex: 1 1 auto;` and `width: 300px;` on kanban records
- If a specific record needs a different size, add custom style to
change the `width` rule.
This allows some standardization of the way to customize the suited
width and also allow lesser LESS code (as the previous version required
either the use of the flex mixin or the use of a media query).
Note:
- Also remove useless app record rule
- Also fix MRP Work Centers record width
Note2:
This system should be improved for version 12.0.
Purpose of this commit is to ease the use of the payment widget and
avoid having to perform too much custom code in the various routes used
when doing payments :
* when instantiating the widget give him its parent element data so
that parameters given when calling the payment form template are
automatically present in the widget options;
* support more parameters when calling the route for form-based acquirers
including access_token, URLs and callback method;
* when doing a form-based payment a call to a JSON route returning the
rendered form is done. Payment widget now uses all data from that
form including the URL of the acquirer website. This way form-based
acquirers are really dynamic and values update is easier;
* remove hidden display of form-based acquirers as all data come now
from the called JSON route that returns the form;
* add a warning about partner-id not being set as it is an issue some
people may encounter;
This commit performs just some linting in order to ease code reading and
prepare future updates.
* extract duplicate variable computation;
* link spaces and indentation;
* light renaming to ease code understanding;
* add a method computing available acquirers and payment tokens for a
given partner and company. Those data will be used notably in customer
portal when displaying the payment form;
* raise if no partner_id set in s2s process. Indeed this field is
required but values come from a dict. Current code raises an error
about None being converted to Int instead of giving the real error;
- 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)
- Added the support of form payment.
- Fixed payment form's errors not being displayed.
- Fixed a crash when paying on e-commerce with a saved token.
(dev commit, need to clean the code)
- Added the most used payment option (credit cards) in the world and assigned which payment acquirers can use them.
- Added the form templates for each payment acquirer.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* 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.
- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.
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.
As this field is defined directly in payment and is displayed on
acquirer form view let us display it in tree view also directly
in payment instead of website payment.
Since the new views, `record.id.value` contains the formatted value of
the ID, meaning it can contain separators. For example, by default,
`1234 => 1,234`. Since this value is used in the image URL, using
`value` won't work anymore.
When registering a payment token, validating it using a payment of a small amount followed by a refund
allows ensuring that the method is valid (i.e. checksumming the card number simple ensure the number
is valid but not that the card exists). This commit introduces a generic approach that must be implemented
for each acquirer that has tokenization support. This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
payment_ogone: add support for tokens validation
-added tour for invoicing
-allow to set easily the number of the first invoice/bill/refund of a journal, from the invoice screen
-small usability fixes and refactoring
Since subscriptions only accept tokenizable (credit-cards and such)
payment options, we must use the token_implemented field to filter out
non-tokenizable payment options (such as wire transfer) and because
token_implemented is a computed field, a search function had to be
created
Odoo Translation Bot