In saas-15, the LESS editor was introduced alongside the use of the
select2 library to style the <select/> element which allows to choose
the view / less file to edit. The problem is that the default behavior
of the select2 library is to open a dropdown with a max-height of 200px
and a width equals to the <select/> element (with no regards to the
dropdown content). In most cases, the dropdown was then displaying
only a few results, broken over multiple lines.
Now, the dropdown is restyled so that it has no maximum height, no set
width and more readable content.
This commit adds a 'Create and Edit' button in the footer of the
dialog opened when creating a record from the Kanban of several
models. Clicking on this button creates the record and directly
opens it in a more detailled form view in edit mode.
This commit adds an 'Edit' button to the record quick create in
grouped Kanban views. When this button is clicked, a name_create
RPC is performed and the created record is directly opened in a
form view in edit mode.
When displaying only invoices, a "Credit notes" filter is useless (and
vice-versa). Filters will be called "Not draft"
When displaying both, keep filters for Invoices and Credit Notes.
Before this the POS would load product.product records with
pricelist_id defined on the pos.config in context. These unit prices
were then used everywhere in the POS as-is. The POS contained no
pricelist logic at all.
This implements the full pricelist logic in the POS and provides a way
for users to choose what pricelist to apply per order. This
implementation closely follows the behavior defined in the product and
sale modules.
This includes unit tests for the get_price function and acceptance
tests. The unit tests are done in PhantomJS and ensure that get_price
returns the same as the backend returns when reading the 'price' field
on product.product.
Prices of products are displayed according to the selected
pricelist. To accomodate this the product_cache DomCache of the
ProductListWidget is now done per pricelist.
Additionally, this feature should speed up the loading of
product.product records. Now only stored product.product fields are
loaded. Before the non-stored computed 'price' field had to be loaded
for every product.product record.
Before this the user was unable to see what value was currently
selected in the selection widget (used for selecting users and fiscal
positions). This implements support for an optional 'is_selected'
function which gets an item from 'list' as a parameter and should
return true when the item is currently selected.
This also removes the fiscal position name from the fiscal position
button because there wasn't much room on the button to fit the name
and with this feature that information is redundant.
The twitter settings view contained a link which opened an inline modal
with a tutorial. As inline modals are not supposed to be supported by
the backend (the Dialog JS class should always be used), this is removed
and replaced by a link to the online Odoo twitter documentation.
When an image is added thanks to the media dialog, the URL that is used
was '/web/image/<id-of-the-attachment>'. Now the name of the image will
be added for SEO purposes ('/web/image/<id-of-the-attachment>/<name>').
Also protect URLs with quotes to allow spaces.
Use case to reproduce the bug:
- Set multi location in settings
- Set warehouse's deliery method as pick/pack/ship
- Deliver a product to customer
- Process a return from customer to output.
- Create a return from output to pack ->
Unable to reserver product.
It happens because return moves where not linked together but have
the picking that created the return as origin.
Thus action_assign does not detect the return moves and can't
guess the real quantity available.
This commit add a behavior that will create links between
return move. It can be guess from parent move(the picking's move from which
the return is created) and its move dest/orig that have already
created other return. It also correct action assign because
the group by could retourn same line with return moves.
It add a test that check returns and links between them.
When deacreasing a quantity on a PO it will decrease the quantity
of an associated move. When the move's quantity reach 0, previously the
move was unlinked and aslo the picking if all moves inside were unlinked.
However the destination move(s) still exist with the quantity that has been
removed in the original move. It can confuse the end user which have a move without
origin.
This commit cancel the move/picking instead of unlink them. Thanks to this
the end user still have the link with the original moves and can guess from where
their destinations moves come from. It also remove the filter on PO in order
to display the canceled picking.
commit 0a960c08757a8ba5e1dc1dd36c17a35de8913975 introduced change about
reserved quantity that set it to 0 once the move is done.
This commit add views improvement. If the move lines are done
reserved quantity does not really matter and thus it is better
to not display it.
Modify the decorator on stock picking that change the font to red
if the quantity processed is greater than the reserved quantity.
This decorator does not trigger if the picking is in state done since
reserved quantity is always 0.
When validating a stock picking there were 2 different cases:
(1) If all qty are equal to 0 it will display a wizard asking
if the user want to set the quantity done to the reserved quantity
for all moves. If the user accept it will automatically perform the
moves after setting the quantity done.
(2) If the user set a quantity on a move, it will check if there is
a need for a back order. If yes it will display a wizard asking if
a back order is needed or not.
However the check if a back order was needed or not was never perform
in case 1. If the quantity reserved was lower than the initial demand
a back order was automatically created.
This commit add the step 2 in the procedure of step 1 (after setting the
quantity done).
The quantity reserved for move was never modified once the move
is done. It is a nonsense to have a reserved quantity for a done
move.
This commit add a constraint that ensure the quantity of
move line to be 0 if it is in state done. Also it add a write
on move_line's 'action_done' function that set the reserved quantity
to 0 for all move line processed.
It does not introduce any change on the stock move itself since the
reserved quantity is the sum of all its move lines's reserved quantity.
This merge mainly does 2 things:
- move frontend chatter feature from website_mail
into portal, since chatter is required for some
business model in the customer portal. This chatter
is still also responsible of displaying comments
for website object (slides, blog, ...)
- bring project customer portal into project,
and make project module depends on portal, like
it was already done for sale and account.
hr_timesheet now contains the dislaying of timesheet
on task in portal.
website_project is removed, and we do not use
website.published.mixin on project, since this
is only used to display its rating. projects are
not public object.
'project.project' should not use 'website.published.mixin',
since we don't want to publish a project on the website.
All we want is to display the rating of a project, nothing
more. So, a flag on project is enought to allow the publication.
* 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.
- ask questions about "Dates", not "Datetimes" anymore
- display dates according to website language
Thanks to Kinjal Mehta and Ravi Gadhia who contributed to this commit.
- 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.
This include mainly the 3 following changes:
1/ [IMP] account: Isolate `group_account_user` in account
---------------------------------------------------------
Purpose
=======
We want to clear the accounting access groups when only the Invoicing application is installed as follows:
If only Invoicing is installed, we should only have 2 groups: `Billing` and `Billing Manager`
If Accouting and Finance is installed, we should have the current groups: `Billing`, `Accountant` and `Advisor`
Specification
=============
1/ If we have only Invoicing the should have the following hierarchy:
group_account_manager (Billing Manager) ---Implies---> group_account_invoice (Billing)
group_account_user (Accountant) is a technical group out the Accouting groups hierarchy
2/ If we have Accouting and Finance installed, we should then have:
group_account_manager (Advisor) ---Implies---> group_account_user (Accountant) ---Implies---> group_account_invoice (Billing)
The reason we want to keep the group_account_user is that we will hide the accouting fields (account_id,...) with this group, allowing the consultants to show the accouting related information on support.
2/ [IMP] account: Split clearly the accounting & invoicing applications
-----------------------------------------------------------------------
PURPOSE
=======
1) Have a clear split between the invoicing and the accounting apps
2) Have a clear split between the community and the enterprise version (no accounting in community)
SPECIFICATION
=============
(1) When only invoicing installed, we shouldn't see accounts (for community and enterprise)
(a) Perpetual Inventory Valuation:
- Hide the field inventory valuation from the product category
(b) Taxes
- No accounts
- No cash basis option
- No tax adjustment
(2) Remove from Community, modules:
- Accounting
- Budgets
- Assets
(3) No account_report in community, keep PDF reports for
- sale/purchase journal
- Aged partner balance
- Partner Ledger
(4) Clean split between invoicing and accounting in enterprise
(a) When installing invoicing, I shouldn't have access to accounting just by changing my access right to adviser
(b) Menus (when only invoicing installed)
- Sales
- Customer Invoices
- Customer Credit Notes
- Payments
- Customer Statements
- Customers
- Sellable Products
- Purchases
- Vendor Bills
- Vendor Credit Notes
- Payments
- Vendors
- Purchasable Products
- Reporting
- Partner Reports
- Partner Ledger
- Aged Receivable
- Aged Payable
- Audit Reports
- Tax report
- Management
- Invoices
- Product Margins
- Configuration
- Settings
- Products
- Products
- Accounting
- Taxes
- Fiscal Positions
- Bank Accounts
- Journals
- Management
- Payment Terms
- Follow-up levels
- Payments
- Payment Acquirers
(c) Settings (when only invoicing installed)
- Fiscal Localization
- Taxes
- Default Taxes
- Rounding Method
- TaxCloud connection
- TaxCloud Categories
- EU Digital Goods VAT
- VIES VAT CHECK
- Currencies
- Main currency
- Multi-currencies
- Invoicing
- Warnings
- Docsaway
- Customer Payments
- Follow-up levels
- Payment Followup
- Bills Payment
- Bank & Cash
- Analytics
- Margin
- Automated Entries
Remarks
- Test with the different access rights
3/ [MOV] account_accountant: Move module to enterprise
------------------------------------------------------
Purpose
=======
When validation his first invoice/credit note, a billing user can choose which number will be the first on the invoice sequencing but it will raise a access right issue
Specification
=============
We want to allow a billing user to do it, but we can't give him the right to write on the ir_sequence.
For that reason, we won't modify the ir.sequence field on the journal and skip this part. The field won't be displayed too on the form.
Additional Point:
~~~~~~~~~~~~~~~~~
A cleaning of the code has been made to avoid raise conditions even when the first invoice has been created (2 users creating 2 invoices before having one validated).
qsm-odoo