Location models and views are moved in their own file. Impacted:
- stock.location
- stock.location.route
- stock.location.path
This commit only moves files. No change is done.
Move model is migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Pack operation models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Pack operation models and views are moved in their own file. Impacted:
- stock.pack.operation
- stock.pack.operation.lot
- stock.move.operation.link
This commit only moves files. No change is done.
Warehouse models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Warehouse models and views are moved in their own file. Impacted:
- stock.warehouse
- stock.warehouse.orderpoint
This commit only moves files. No change is done.
Picking models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Inventory models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Inventory models and views are moved in their own file. Impacted:
- stock.inventory
- stock.inventory.line
This commit only moves files. No change is done.
Quant models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Those models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Move models not located in stock.py file and their views:
- barcode
- procurement
- product
- product.putaway, product.removal and stock.fixed.putaway.strat are
extracted from product.py to their own product_strategy file
to separate product and product.template code from stock specific
code related to products
- res_*
- settings
- web_planner
This commit only moves files. No change is done.
Moves performed
- data and demo files are now located inside the data directory
- data and demo files name updated
- report views moved inside report directory instead of views
- main stock menus declarations moved from stock.xml to stock_menu_views.xml
in order to have all main menus in a single file, extracted from model
specific views
- data section of __openerp__.py file reorganized accordingly
No change done in this commit.
General remarks concerning cleaning commits preparing the stock migration
=========================================================================
Small update / cleaning before moving and migrating. This commit contains
the cleaning of stock_picking_type and stock_picking models.
The first cleaning performed is to clean methods having a browse record or
a list of records replacing ids parameter. Those are converted into classic
old API methods using cr, uid, ids. This eases the migration as they are
then migrated into multi methods.
Another cleaning concerns naming things. Some methods are renamed to ease
the code readability. Some parameters are also renamed as well as some
variables. This kind of change is performed only when the readability
is improved. Otherwise the code is kept as it is to avoid rewriting too
much of the code.
Finally unnecessary stuff is also removed. This concerns dead code (methods
not used in community nor in enterprise) and unnecessary code splitting
(tools methods called once without real added value are directly put into
their called method).
- stock.move: no specific changes; note that a method called only in mrp
has been moved to mrp.
- product: no specific changes
- config settings: no specific changes
- wizards: no specific changes
stock.quant main changes
========================
- ``apply_removal_strategy`` method updated to return only the removal
strategy instead of having a mix of several things (overrides updated)
- ``quants_get_**`` methods renamed to ease code understanding
- quants_unreserve from stock.quant to stock.move model because its primary
record is a move, not quants
stock.inventory and stock.inventory.line main changes
=====================================================
- stock.inventory: ``move_ids_exist`` field remove. Unused.
stock.picking and stock.picking.type main changes
=================================================
- stock.picking: ``move_lines_related`` is removed. Indeed it is used only
to display a slightly different view of moves contained inside a picking.
However this field causes a lot of issues when migrated into the new API.
The view is updated to keep the same look and feel while avoiding an
unnecessary field.
- stock.picking.type: complete_name field is removed. Using display_name is
sufficient for the existing use cases.
stock.warehouse and stock.orderpoint main changes
=================================================
- stock.warehouse: removed ``resupply_from_wh``, unused field
stock.pack.operation main changes
=================================
- stock.pack.operation: ``processed_boolean`` fields renamed to ``is_done``
to match its use in the code.
stock.location main changes
===========================
Note that in this commit a strange override in create has been replaced by a
cleaner override in default_get in order to have something more understandable
procurement main changes
========================
- in this commit some code located in procurement has been moved to the
orderpoint model. Indeed those methods take an orderpoint as main
argument, making it more orderpoint methods than procurement methods
- ``_prepare_orderpoint_procurement`` method has been merged with its
strange override in stock_calendar to have something a bit more modular
Including
- unit tests for test/inventory.yml
- unit tests for test/move.yml
- unit tests for test/shipment.yml
- integration of test_reuspply.py
- integration of test_owner_available into test_product.py
New tests are temporarily deactivated. Indeed they rely on onchange methods
that will change during migration. Tests will be reactivated after migration
and updated.
Setting a binary field stored in attachment may trigger recomputations on the
main record before all fields are set on that record. This may cause access
errors if the record does not satisfy some access rule because of the fields
that are not set yet.
Rev. 56cec604e6 modifies
the auto-commit behavior of the mail queue scheduler,
to allow using it within tests.
The condition was wrong and always True as soon as
the registry was loaded, permanently disabling
auto-commit, both during tests and outside tests.
This broke the duplicate emails protection.
Improved usability & code cleaning:
- Support for blanket orders, in addition of purchase tenders
("Purchase Agreements")
- Create a RfQ in one click, no wizard anymore
- Control of quantities really purchased
- Better control of side-effects thanks to purchase requisition types
- JS code removed (not necessary)
- Workflow removed
Closes#11666
When traversing relational fields as superuser, you end up with a recordset for
which only a subset is accessible to the current user. An earlier fix to this
issue completely dropped the `related_sudo` feature; change its implementation
to keep the feature.
Before this rev., if the user clicked, in the autocomplete dropdown, on an
already opened DM, nothing happened. Now, it redirects to that DM.
Also clear the input once a partner is selected.
When opening a new DM from the Discuss sidebar or from a chat window, and
when inviting people to a channel, first search for a match in the prefetched
partners (basically, the employees), and only perform the im_search RPC
(extending the research to all users) if there is no match.
Also sort the results by name.
There used to be some acceptance tests but they have not actually been
run since 8.0.
These acceptance tests are very useful for the POS because the POS is a
somewhat unusual module and it happens occasionally that a change in
another module unintentionally breaks the POS.
Another reason these tests are nice to have is because the POS
duplicates a lot of calculations in JS because it's meant to be able to
work offline (eg. calculation of taxes, orderline totals etc.). Subtle
differences (eg. rounding) between the frontend JS calculations and the
backend calculations make up the most common category of bugs in the
POS. These frontend tests will make it easy to write tests for these
scenario's. When phantom_js finishes we look through all the received
pos.order records and see that all of them are paid. If there would be a
difference between frontend and backend calculations the order would not
have the paid status because the payment on the order would be different
from the total. An example test for a previous bug has been included.
This will also come in handy for testing the upcoming pricelist
functionality that will be implemented in the POS.
Since the crm refactoring in V9, the stages doesn't make sense anymore on a lead,
as this step is only to validate an opportunity. We should remove this view as it
is confusing in this case : If I create a stage on the opportunity form view,
it appears also on the lead kanban view. Other side effects can also be encountered.
When invoicing several SO with same partner and with different invoice address,
different invoices have to be created with each invoice address.
Used case:
-create a customer with two invoice addresses
-create a SO for this customer with the first address
-create a SO for this customer with the second address
-select the two SO in the SO tree view
-click on "Invoice Order"
-click on "Create and view invoices"
Results:
Before the fix: The two SO are merged in one invoice with the second
address.
After the fix: Two invoices are created, one for the first address and
one for the second address.
opw:675961
The picking type is not defined on the stock move when a picking is
created manually. This can cause errors, for example in manufacturing: a
product sold in kit will not be replaced by its components.
opw-673741
The Automated File Upload (AFU) Ogone API requires a transaction code to be set,
either:
- ATR for automated transactions
- MTR for maintenance operations
The default is ATR and is used for submitting transactions in batch.
However, the server-to-server mode of payment_ogone only uses the AFU
API to create new credit card aliases, and not to process transactions.
Using the ATR transaction code requires the ATR feature to be available
in the Ogone Merchant account - a paying option that is otherwise
unused. Using MTR as the transaction code is sufficient for adding
aliases, and the corresponding feature (MTR) is available at no cost
in most Ogone Merchant Accounts.
References:
- Ogone Advanced Batch:
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/batch
- Ogone Alias Management:
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/alias/bulk-alias-management-via-batch
This is possible to create bank statements
forcing the amount in the foreign currency,
along with the bank account currency, and therefore
to force the foreign currency rate.
In such a case, when reconciling the journal items,
the currency rate conversion must not be done
against the currency rates written in database,
in the rates records, at that date, but with
the rate that was forced in the bank statement.
opw-676048
The current behavior was allowing going on the previous row if the
user is at the start of an editable element and on the next row if the
user is at the end of an editable element. The problem was, we did not
want this behavior when the editable element is a select or m2o (as
the up and down input should open the select/m2o dropdown instead).
When a user is subscribed to a channel with many messages,
the discuss initial rpc /mail/client_action can become very
slow (in production, the rpc took > 20s when subscribed to
the Community mailing list). This is due to the query in
_get_message_unread, counting the number of unread messages.
This commit adds an index on the relation mail_channel_partner,
this allows postgres to perform only index lookups, and speeds
up the query by 2 order of magnitudes.
Thibault Delavallée