Purpose
=======
The menu "Sales -> Invoicing -> Orders to invoice , shows the orders which are confirmed and where the invoice needs to be created for those.
User should not be able to create SO from this menu.
===========
Specification
===========
Remove create Button in (Order to invoice and Order to upsell) menu and in website -> order to invoice
Purpose
=======
As you can easily edit your stages via your kanban view, this menu item is not necessary
Specification
=============
Following configuration/stages menu Move to debug mode
List of menu:
Quality/Configuration/Quality Alert Stages
PLM/Configuration/ECO Stages
Events/Configuration/Track Stages
Project/Configuration/Stages
Maintenance/Configuration/Maintenance Stages
Recruitment/Configuration/Stages
Email Marketing/Configuration/Campaign Stages
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
Purpose
=======
Improve label in full mail composer.
Specification
=============
In full mail composer if it's log than send button string should be "Log".
Localizations depend on the module "base_vat". It is therefore
impossible to remove base_vat without the localization. This causes
issues for users who simply want to deactivate the VAT check.
opw-743260
Purpose
=======
Don't display sales app icon in Odoo homepage when installing ecommerce (only website should be visible)
it's confusing to have sales icon -> where do I manage my sales? In sales or in website? -> in website
Specfication
============
We need one new modules to add Sales menus to the homepage. Currently they come with "sale". So when installing "website_sale", we get them (because sale and account are dependencies of website_sale). We don't want that anymore. Along with that you need to replace modules in Apps menu:
sales menu items must be in the new sale_management module, no longer in sale
- create new app "sale_management"
- Currently 3 app icons when installing ecommerce (Sales, Invoicing, Website) -> too many icons, where to start? -> GOAL: Only 2 icons > Website, Invoicing
- new module to display Sales Icon (like account_accountant): "sale_management"
- move menu items to sale_management
- sale, sale_management: move app description, rewrite the manifest file
- sale, sale_management: move tour from sale > sale_management
- Changes in some dependency module "sale" > "sale_management" modules: event_sale, mrp_repair, pos_sale, report_intrastat, sale_crm, sale_expense, sale_stock, sale_timesheet, website_quote
Menu items to move 'sale' --> 'sale_management'
===============================================
Sales
Quotations
Sales Orders
Invoicing
Orders to invoice
Orders to Upsell
Catalog
Products
Product Variants
Pricelists
Reporting
sales
Configuration
Settings
Products -Attributes, Attribute Values, Internal Categories
This reverts commit 9ab421d99a.
We should use the active field on the ir.ui.menu with the root menuitem instead of moving all the menuitems into a new module
Let `create` and `write` round monetary field values before sending them to the
database. Pass the values to be written to `field.convert_to_column`, so that
the currency can be retrieved from the values, and the value be rounded.
Before this commit, expanding a chat window would open the discuss application, which means that the current navigation state (breadcrumbs) is lost. With this commit, it simply opens a new action in the breadcrumb, and does not lose the current action. (PR 16725, closes task 31767)
Note that this implies that it is possible to have two discuss client actions open at once.
Purpose is to ease user flow and understanding when configuring and
managing payment methods. UX of acquirers (form, kanban) and their
integration in ecommerce is improved. Please refer to individual
commits for more details.
This merges 'dev/master-clean-payment-views-jpr-tde'.
Purpose
=======
In Expenses > Reporting > All Expenses, the X-axis of this pivot by default is the creation date of expense report. It should be the expense date instead.
make the same changes in graph view.
Specification
=============
In "All Expenses" report by default "Expense Date" instead of "Create Date" in pivot
Also rename "Date" to "Expnese Date"
Changes should be made in to graph view.
* add a constraints about authorized state for tx and authorize feature
available on acquirer;
* order acquirers first by publish, then sequence then name;
* add a sequence on some provider data and use a default to have some
popular acquirers first;
* use update instead of write in an onchange;
* add provider, related on acquirer_id.provider, in order to display
certain piece of information on tx depending on their provider;
* better tx form view and partner address display;
* remove unnecessary notebook on tx form view as it is not used;
* rename Payment Acquirers menu into Payment Methods, easier to
understand;
* acquirer kanban view improved to install / activate / configure them
depending on their state;
* be able to publish / unpublish acquirers without having to wait for
website_payment to add a button;
We add the o_touch_device css class to the body (it was done in enterprise only), and various other small changes to make sure that the action buttons (in discuss, next to the message title) are always visible (not only on hover) when we are on a touch device. (pr (#15459, closes task 31208)
This commit proposes to simplify payment acquirers configuration in
backend and frontend. Includes mainly
* configuration boxes for website admins at checkout process;
* better and fixed display of transaction status at checkout;
* hide unnecessary fields for transfer provider;
This commit merges 'dev/master-payment-tde'.
Indeed as transfer transactions are always pending and independant of
any callback, it is not necessary to see credentials, auto confirmation
settings and error / cancel / done messages.
Currently displaying tx status after checkout is done using two templates
and two separate pieces of code, aka "order_state_message" and
"payment_confirmation_status". This leads to checkout information
being displayed twice in the page. It is displayed once before the
order details and once after payment information.
This commit simplifies the code to display only once the transaction
status after payment information. This one is the "polled" one aka
refreshed automatically several times to try to catch responses from
payment providers.
From the confirmation message it is also now possible to directly jump
in the backend for website administrators in order to edit the displayed
messages.
Currently /shop/payment controller perform some data processing. It calls
model methods _get_errors and _get_website_data that are defined on sale
order model only to be inherited in website_sale_delivery.
This commit proposes instead to have a data processing method in sale
controllers that is inherited in website_sale_delivery. There is no need
to have model methods only to format data.
Before this commit, when a test in the qunit test suite failed, the
error displayed by the runbot was not really interesting. It just said
that test_01_js failed. With this commit, each assertion error is now
logged as an error, which means that they are displayed in the short
error log by the runbot.
With this commit, we introduce a benchmarking infrastructure: a new
controller, accessible at the route /web/benchmarks which will render a
new template (web.benchmark_suite).
This template uses benchmark.js and qunit.js to display a list of
benchmarking informations. For example, the number of op/s for
instantiating and destroying a list view.
I hope that this is the start of the beginning of taking the habit to
check our JS code performance sometimes, and making sure we do not have
large regression without a good reason.
The form renderer defines inline style on the groups it renders to
set the width of their children according to the col and colspan
attributes specified in the view.
However, before this rev., this impacted inner list views (for
x2many fields), as their columns get an harcoded width as well,
whereas they shouldn't.
This was for example the case in the stock.location.route form
view, for the push rules and procurement rules o2m fields.
Prakash Prajapati