The JS widget is simplified, which a cleaner approach.
For the rendering part:
- the server reads the data
- the JS widget formats/organizes the data
- the template renders the data prepared by the widget
Quick summary of the modifications:
1. The associated field is a text field which contains JSON-encoded
data. The data are read server-side, and not client-side anymore.
2. The widget is an AbstractField, no need of ReinitializeWidgetMixin
anymore. No use of the FieldMonetary widget directly, but use a similar
format_value instead (inspired by ShowPaymentLineWidget).
3. Data formatting (call to format_value) is done in the widget, not in
the template anymore. This seems to be the standard way of doing, since
lunch was the only module where format_value was in the template and not
in the widget.
4. The addition of an order line is cleaner since all necessary data
are prepared server-side.
Steps to reproduce:
- Create one (or several) expense lines
- Submit them to the manager (create the expense sheet)
- Approve the sheet and post the entries
- Delete the created and posted sheet
Bug:
- The expense is deleted but the accounting entries are still in the database
- The expense lines are in "To submit" and you can submit to manager again and
generate a new report and therefore new accounting entries...
Fix:
It is not allowed to delete posted expense.
opw:692323
The favorites menu is always added in search views. Then the
menu "add to dashboard" is always added even if it is triggered from
a form view in a modal. In this case, the action_id is not available
in the object FavoriteMenu.
If the action_id is not available, the menu "add to dashboard" is
hidden.
opw:692023
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
The javascript tour (test) will verify the total amount based on sale
price of the product without taking taxes into account.
However, if any l10n_* module is installed and defined a default value
for product taxes, the test will fail this check.
Model account.invoice has "date" and "date_invoice" fields.
("Accounting Date" and "Invoice Date" respectively)
The dashboard was incorrectly using the "date" field from account.invoice to
look up the corresponding invoices.
NOTE: account.invoice.report renames the date_invoice to date and doesn't use
the date field from account.invoice, it can be very confusing.
For invoices analysis(account.invoice.report) add this month and last month
filters in search view and set appropriate default filter on dashboard actions.
For pipeline analysis(crm.opportunity.report) add this month and last month
filters in search view and set appropriate default filter on dashboard actions.
For activities analysis(crm.activity.report) add current month and last month
filters in search view and set appropriate default filter on dashboard actions.
Set sale order and production order link on Mo. override make_mo method in sale_mrp module to set sale order reference in mo.
.and to find final destination move, i created one common private method to get parent move.
MESSAGES TO DISPLAY:
-Set a Reordering Rule (stock.warehouse.orderpoint) that creates a manufacturing order:
"This manufacturing order has been created from: OP/00001"
-Create new Sales order of manufactured product , there will be a Source Document with procurement of that Sale Order
"This manufacturing order has been created from: SO001"
-create MO for BoM items of the product, there will be a Source Document with procurement of that Manufacturing Order
"This manufacturing order has been created from: MO/00001"
As of f814dd9908, debug
mode causes an extra X-Debug-Mode header to be sent
by the rpc() JS method.
This custom header was not whitelisted in the accepted
CORS headers, therefore any cross-origin call to a route with
`cors=True` would fail in debug mode, with a console error
along those lines:
"Request header field X-Debug-Mode is not allowed by
Access-Control-Allow-Headers in preflight response"
This would prevent loading the POS GUI in debug mode,
for example.
This commit is necessary in the 8.0 branch because
the POSBox is currently based on a 8.0 server and may
be accessed by a 9.0 POS or later, thus with the extra header.
Previously we had 'Inventory at Date' (debug mode) and 'Inventory Valuation'
Both have been merged into 'Inventory Valuation' that pops up a wizard asking
whether you want the current one or the one from a specific date.
Depending on which one you choose you will get either report from the previous
menus. (stock.quant or stock.history model)
* Do not assault the user with a full traceback on bug, but indicates
an error occured and allow him to toggle the traceback
* Automatically scroll the traceback to the end (better for python
errors)
* Propose the user to report the traceback by using a new "Copy"
button which correctly copies the full error + traceback
'issue_ids' has a domain, so all the issue a folded
stage are not taken into account for statisfaction
percentage.
So replacing the field with a search call solve the
problem.
When a user has access to a quote (because he is follower) but he is not
in the same company than the customer, an access error can occur on the
the rendering of the partner field.
We use the tokenized link instead, which will read the SO as a superuser
to avoid this situation.
opw-691740
Currently when using a language on the website, the following is done in
this order to choose which one will be used:
1) use a language code if present in the url (eg. /fr_BE/),
2) use a language similar to the one in the url,
3) use a previously choosed language (saved in cookie),
4) use the browser language if available on website,
5) use a language similar to the browser language,
6) use the default website language
When a bot is requesting a page, he could either not specify a browser
language (en_US is set as default) or sometimes specify english
erroneously.
In these instance, we will then never use the default website language
if an english language is installed.
This fix changes this behaviour so if a bot is visiting a page, the 4th
and 5th steps are skipped and the default website language is used
instead of using the browser language.
closes#14033
opw-690910
When pasting, the paste event is cancelled and done back with the
corrected data.
This works fine on firefox, but this can have unwanted results on other
browser like pasting two times or copying the end of the line at the
beginning.
This commit replace completely the summernote functionality with our
small implementation of pasting corrected text.
closes#14043
opw-690814
Steps to reproduce :
1. Create a new customer
2. Create an invoice with an amount of 50.- for this new customer and validate it
3. Create a refund with an amount of 70.- for the same customer and validate it
4. Create a Customer Payment for this customer and validate it. The Invoice will be paid with 50.- of the refund. 20.- are still on residual in the refund.
5. Create a new invoice with an amount of 50.- for the same customer.
6. Create a new Customer Payment for the same Customer and validate it.
The Full Reconcile Boolean stays checked inspite of "Open Balance" of Refund amount is less than the Invoice amount.
After the fix:
Full Reconciliation Boolean doesn't get checked and Allocation amount on invoice journal item line should be same
as Open balance of the Refund Journal Item. So Invoice stays open with Balance amount.
opw:691577
Before this fix, the tz was ignored in the search. So the group by counter
was not especially the number of blog post displayed.
The month display was wrong, date_begin was localized.
Start was eg (in Europe/brussels) : 10/31/2016 22:00:00.
So if we don't localize this time with babel, we got October as displayed
month instead of November
The Archive was not sorted by year desc, now it is.
Old behaviour was strange:
2015: December, Octobre
2016: December, Octobre
=> Year asc, Month desc
dut-odoo