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
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.
Sometimes, a default_get returns a create command for a one2many,
with a dict of values containing value 'false' for a many2one. This
is strictly equivalent to the case where the many2one field isn't
in the dict of values, but we have to handle both cases, and before
this rev., we only handled the latter one.
This happens for example in Sales > Leads (must be activated in the
Settings) > in the list view, check several leads > in 'Action',
click on 'Forward to Partner' > crash.
The value for one2many fields returned by default_get may be a
list of commands, or directly a list of ids. These cases were
correctly handled. However, it seems that the value can also be
false, and when this happened, it crashed. For instance, go to
Sales > Leads (must be activated in the Settings) > in the list
view, check several leads > in 'Action', click on 'Convert to
Opportunities' > crash.
Let's assume the following situation: we have a one2many field
displayed as a list in a form view. The list isn't editable, so
when a subrecord is clicked, it is opened in a form view in a
dialog. In this form view, there is a relational field X that is
not in the list. In the main form view, there is a field with an
onchange. When its value changes, the onchange returns a new
value for the one2many: a command 5 (delete all), and a command 0
(create) with a dict of values containing a value for X. However,
as X is unknown as long as no subrecord has been open in the dialog,
the value for X can't be processed (we don't know the type of X,
so we don't know how to process the value).
Before this rev., when this happened, we discarded the value of X.
This caused an issue for example in the Quotation form view (with
website_quote installed):
- create a new Quotation
- set PartnerShip Contract as quotation template -> the onchange
returns two 'create' commands for the order_line one2many
- click on one of the two subrecords in the one2many -> error.
This rev. ensures to keep changes on unknown fields. We keep them
unprocessed, and once the form view is opened, we process and
apply them.
Since the revenue computation is an automatic system
action, it should be done in sudo(). This avoid access
error.
Indeed, if a company creates and confirms a SO, a task
can be created in another company project. Logging
timesheet from the project company is thus impossible
since the user can not access SO line of the origin
company.
Adding sudo() seems better than givin read access
to 'all' so line for timesheet user.
It happens because the function still use the old fields
utilized before refactoring introduced by commit b3180c8411
This commit adapt the function by using quantity instead of qty.
partner_id was either a recordset (in create mode), either an id (in edit more)
in the `_checkout_form_save` method.
An id is expected as the result is used in the ORM method (4, partner_id)
Closes#18533
Fine tuning of this commit: b795d69ce8
Steps to reproduce the bug:
Leaves > List view > Go into any validated leave > Get Odoo Server Error on access rights
opw:693536
Custom fields are duplicated because the cache of method `_existing_field_data`
is invalid at the time the model is reflected: it does not contain the field
that has just been created. Simply clear the method caches before reflecting
models and fields.
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).
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`.
Complementarily, when traversing related fields the prefetch
environment would be lost and every record would get an empty prefetch
environment, so the values would ultimately be read one by one.
Example: select (search) 1000 product.product records, access a
related field (e.g. categ_id) in a loop, on the first iteration the
system would first read 1000 templates, then it would read each
categ_id individually, resulting in >1000 SQL queries rather than the
~2 we would expect.
Fixes#18511
A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).
Commit 7cd2f6370 (in 10.0) recently added attribute special='cancel'
on the 'Cancel' buttons of the Settings views in Odoo. The attribute
wasn't really supported in this case by the old web framework, so
this commit also slightly adapted it, and made it reload the whole
webclient when such a button is clicked.
This commit now needs to be forwardported in saas-16, so we have to
handle the case in the new views as well. Before this rev., it
crashed, because the BasicModel tried to reload a new record (the
one of the Settings form view), so basically it performed a 'read'
RPC on a virtual ID like 'virtual_123', and the server didn't really
appreciate.
This rev. handles the case where a new record is reloaded, and
simply performs a 'default_get' instead of a read. Bonus point:
with the new views, we don't have to reload the whole webclient.
IE11 seems to be always using cache when doin an XHR request with the
same GET request.
It can be changed in several ways:
- returning a header: "Cache-Control: no-cache"
- altering the GET request with a nonce
- using the POST method instead of GET
to solve it, in this change the HTTP header is added on the response.
opw-752270
closes#18787
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
Edi Santoso