'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.
In grouped Kanban views, the list of res_ids of the displayed
records may change for several reasons:
1) 'Load more' is clicked for a column
2) a record is moved from a column to another
3) a record is moved inside a column (resequence)
4) a column is moved
5) a column is (un)archived
6) a column is (un)folded
7) a record is created/destroyed directly from the Kanban.
When this happens, the environment must be notified of the new
list of res_ids (the order matters). Before this rev., this wasn't
the case. As a consequence, when a record was opened in a Form view
after one of the 5 operations above, the pager could display
unexpected values.
Note that before the new views, cases 2, 3 and 4 weren't handled,
and case 7 already worked before this commit.
The problem occured when opening a record from a grouped list or
kanban view. In the opened form view, the pager was sometimes
incorrect. This was because the list of ids wasn't correctly
updated when groups were opened/folded.
Before 9.0, it was possible to display aggregate values in grouped
Kanban view (like sum, average...). The aggregate was displayed in
the header of the column (see for example in 8.0 in Project >
Tasks).
This feature has been dropped in 9.0 because it didn't work
correctly, but the documentation hasn't been updated accordingly.
/mail/view controller is a generic controller that redirects to a view
on a document either on backend or frontend depending on the module,
user and some model specific conditions.
However currently url computation is not always correct as you may end
up on frontend view even when you are a regular user that should land
on backend views.
In this stable version we introduced a key in the returned action that
indicates the action is a pure front-end (public) action or not. This
way people are correctly redirected to the backend or the frontend
when going through the controller.
* 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.
Up to this revision, clicking on 'edit' in a record with an existing pad
and discarding the changes straight away caused the pad content not to
be displayed.
The root cause of this issue is twofold:
- a hack tricks the model into thinking the pad URL has changed by
replacing it with an object yielding the URL when JSONified;
- the pad never affects the 'dirtiness' of a record and BasicModel only
actually discards changes when the record is dirty.
When a user clicks on discard, the model does not actually discard the
changes, thereby leaving the web client into thinking the pad URL is the
object mentioned above.
We fix this issue by requiring that the model always discard changes
when clicking 'Discard', regardless of whether the record is dirty.
In fact, the lines we changed were no longer correct since the
introduction of 'doNotSetDirty' (see
https://github.com/odoo/odoo/commit/72ed3a1), as a record could be
changed without being dirty. This commit thus also ensures that such
records are also properly discarded.
Before this commit there were two issues:
- The date "from and to" set in the wizard weren't working, as in not used at all
- The lines in the report did not have a date range, making the understanding of the report difficult
after this commit, only the budget lines which dates overlap at least one day of the report's dates will be selected.
Also, the first line of the report, containing the budget name also contains the dates on which it applies
OPW 743441
Closes#18737
Backport of 0280354045
Original message:
The previous trigger would recompute all sessions of a config when modifying
the cash_control flag on the config.
It was not possible to enable cash_control if a previous session wasn't in
cash control mode.
Recompute only when changing the config
OPW 761025
Closes#18814
Before this commit, it was not possible to copy the contents of a
multiline text field in read-only mode in Firefox without losing all
line breaks in the process. This is due to a bug affecting div tags
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1390115) in Firefox.
This commit ensures that the text in a text field is surrounded by a
span (as opposed to div) tag.
Note that spans were used in saas-15, so we are in fact simply undoing
the change to divs introduced by the new views.
1. Set the Decimal Accuracy of "Product Unit of Measure" to 7.
2. Create a UoM: T-LBS which is the reference for weight and has a
precision of 0.01
3. Deactivate KG (which was the previous reference for weight)
4. Create a UoM: T-GT which is BIGGER, with a ratio of 2240.00 and a
precision of 0.0000001 (necessary to avoid rounding errors)
5. Set the Product Unit of Measure Decimal Accuracy to 6 digits.
6. Create a Product T-TEST with T-LBS as the UoM ans Tracking as LOTS
7. Create a PO for 60 T-GT
8. Observe a Receipt created for 134,400.0000000 T-LBS
9. Receive 42760 by using LOT SPLIT button, and creating a LOT to hold
this amount.
10. Click VALIDATE.
11. Click CREATE BACKORDER.
The backorder is created for 91640.01 instead of 91640.00.
When the backorder is created, we should make sure to use the same
rounding method that was used to compute `product_uom_qty`, in this case
'HALF-UP'.
opw-753116
To reproduce:
- Create department 'Art' parent Department 'Management'
- Create job position and set department 'Art' & publish
- Allow 'Filter by department' from the frontend page
- As a public user, open job => Access Forbidden
The record rule should be adapted to allow accessing departments which
have children.
Actually, the rule could probably be removed since the controller
already lists only the necessary departments.
opw-765736
Currently when importing files, the parent left and right are recomputed on each record creation/update, which could lead to a lot a request.
This commit will defer the parent field recomputation to the end on the `load` function by recomputing the values from the MPTT and inserting directly the new values on the records.
Tested on a customer instance, this will reduce the execution time when importing a thousand stock.location from 15 minutes to several seconds.
The %d %h options in db-filter are case sensitive but the URL are not.
If you happen to use databases with uppercase in the name, using (?i) may be
needed to match the correct database.
Fixes#17407
As mentioned in
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49,
a resize after the first render is necessary to prevent overflow issues
with fullCalendar. As changing the date would rerender the calendar, we
also need to trigger a resize then.
From this revision onwards, a resize event is triggered every time the
calendar has finished rendering its events.
Unfortunately, I was not able to write a meaningful and successful test
(I encountered PhantomJS-specific issues). I also removed the test for
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49
because it always passed regardless of whether the fix is applied.
1. Create an attribute with create_variant boolean un-ticked (ie. don't
create variants from these attributes). For example 'Test Attribute'
2. Create attribute values related to the above attribute. For example
'Test 1', 'Test 2', etc
3. Create a product (product.template) and assign an attribute (eg.
Color: black and white)
4. On one of the product variants, add one of the attribute values for
the attribute we've created in step 2 to the attribute_value_ids
field to allow for filtering by product attributes that do not create
variants.
5. Go back to product template and add another attribute value to an
attribute where create_variant is True (eg. Memory: 16 GB)
6. Our value from attribute_value_ids is gone, and the product has been
deactivated
When attributes are set with create_variant is False, they are
obviously not used to create variants. Therefore, when we are looking
for existing variants, we should filter out these attributes.
Partially closes#18682
opw-762743
when access status hw_proxy in debug mode it's will raise error,
it's happens because hw_proxy uses subprocess module to get a list of usb
but the subprocess module not imported.
Introduced at 56456359Closes#18820
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
- 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.
The traceback was caused by an occurence of this.dataset, which was left
out in the new views refactoring (this.dataset has been replaced by
this.record).
We avoid to actually jump in the back-end, to prevent
phantomjs to send requests to the server without waiting for them.
Indeed, clicking on the close & confirm button jumps ine the backend,
but the tour is actually finished (and succeeded) once these buttons
are clicked, and just clicked. The test does not actually check if these buttons
makes the user come back in the backend, and it does not wait
for the requests sent because of the jump in the backend to be completed.
Besides, the jump in the backend triggers the compilation
of the common and backend assets, which take some time.
These requests for which phantomjs does not wait triggers
the method `def _wait_remaining_requests(self)` in the
class `class HttpCase(TransactionCase)`, which
leads to the ugly tracebacks in the runbot, waiting
for the requests triggered by phantomjs to be finished.
When deciding to prefetch records (getting records from the cache with no value
for the field being fetched), if the field was computed `determine_value` would
just get all records, not limited by the normal prefetch limit; for large
recordsets this would generate gigantic prefetch lists for records we may not
need at all.
Fix by applying the `PREFETCH_MAX` limit to records from the cache as is done
in `_prefetch_field`.
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).
Purpose
=======
Currently, a billing user can't create a payment without raising a access rule issue.
Specification
=============
The related field `check_manual_sequencing` on the account journal should be readonly on the payment form view to avoid a write on the account journal of record creation, which is forbidden for a Billing user
Jérome Maes