Merge pull request #169 from acsone/8.0-port-account-move-batch-validate-ape

[8.0] Port account move batch validate to 8.0

.travis.yml

@@ -17,7 +17,7 @@ virtualenv:
 install:
   - git clone https://github.com/OCA/reporting-engine ${HOME}/reporting-engine -b ${VERSION}
   - git clone https://github.com/oca/maintainer-quality-tools.git ${HOME}/maintainer-quality-tools
-  #- git clone https://github.com/OCA/connector $HOME/connector -b ${VERSION}
+  - git clone https://github.com/OCA/connector $HOME/connector -b ${VERSION}
   - export PATH=${HOME}/maintainer-quality-tools/travis:${PATH}
   - travis_install_nightly ${VERSION}
 

account_move_batch_validate/README.rst

@@ -0,0 +1,61 @@
+.. image:: https://img.shields.io/badge/licence-AGPL--3-blue.svg
+    :alt: License
+
+Account Move Batch Validate
+===========================
+
+This module provides a wizard to post many Journal Entries in batch. it
+uses the queue system introduced by the OpenERP Connector to handle a
+big quantity of moves in batch.
+
+The module account_default_draft_move introduces a workflow where the
+Journal Entries are always entered in OpenERP in draft state, and the
+posting happens later, for example at the end of the period. The core
+account module provides a wizard to post all the moves in the period,
+but that is problematic when there are many moves.
+
+The posting of a move takes some time, and doing that synchronously,
+in one transaction is problematic.
+
+In this module, we leverage the power of the queue system of the
+OpenERP Connector, that can be very well used without other concepts
+like Backends and Bindings.
+
+This approach provides many advantages, similar to the ones we get
+using that connector for e-commerce:
+
+- Asynchronous: the operation is done in background, and users can
+  continue to work.
+- Dedicated workers: the queued jobs are performed by specific workers
+  (processes). This is good for a long task, since the main workers are
+  busy handling HTTP requests and can be killed if operations take
+  too long, for example.
+- Multiple transactions: this is an operation that doesn't need to be
+  atomic, and if a line out of 100,000 fails, it is possible to catch
+  it, see the error message, and fix the situation. Meanwhile, all
+  other jobs can proceed.
+
+Credits
+=======
+
+Contributors
+------------
+
+* Leonardo Pistone <leonardo.pistone@camptocamp.com>
+* Nicolas Bessi <nicolas.bessi@camptocamp.com>
+* Rudolf Schnapka <rs@techno-flex.de>
+* Stéphane Bidoul (ACSONE) <stephane.bidoul@acsone.eu>
+* Adrien Peiffer (ACSONE) <adrien.peiffer@acsone.eu>
+
+Maintainer
+----------
+
+.. image:: http://odoo-community.org/logo.png
+   :alt: Odoo Community Association
+   :target: http://odoo-community.org
+
+This module is maintained by the OCA.
+
+OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.
+
+To contribute to this module, please visit http://odoo-community.org.

account_move_batch_validate/__openerp__.py

@@ -22,7 +22,6 @@
     'name': "Account Move Batch Validate",
     'version': '0.2',
     'author': "Camptocamp,Odoo Community Association (OCA)",
-    'maintainer': 'Camptocamp',
     'category': 'Finance',
     'complexity': 'normal',
     'depends': [
@@ -30,41 +29,6 @@
         'account_default_draft_move',
         'connector',
     ],
-    'description': """
-        Account Move Batch Validate
-
-        This module provides a wizard to post many Journal Entries in batch. it
-        uses the queue system introduced by the OpenERP Connector to handle a
-        big quantity of moves in batch.
-
-        The module account_default_draft_move introdoces a workflow where the
-        Journal Entries are always entered in OpenERP in draft state, and the
-        posting happens later, for example at the end of the period. The core
-        account module provides a wizard to post all the moves in the period,
-        but that is problematic when there are many moves.
-
-        The posting of a move takes some time, and doing that synchronously,
-        in one transaction is problematic.
-
-        In this module, we leverage the power of the queue system of the
-        OpenERP Connector, that can be very well used without other concepts
-        like Backends and Bindings.
-
-        This approach provides many advantages, similar to the ones we get
-        using that connector for e-commerce:
-
-        - Asynchronous: the operation is done in background, and users can
-          continue to work.
-        - Dedicated workers: the queued jobs are performed by specific workers
-          (processes). This is good for a long task, since the main workers are
-          busy handling HTTP requests and can be killed if operations take
-          too long, for example.
-        - Multiple transactions: this is an operation that doesn't need to be
-          atomic, and if a line out of 100,000 fails, it is possible to catch
-          it, see the error message, and fix the situation. Meanwhile, all
-          other jobs can proceed.
-
-    """,
     'website': 'http://www.camptocamp.com',
     'data': [
         'account_view.xml',
@@ -75,7 +39,7 @@
         'test/batch_validate_then_unmark.yml',
         'test/batch_validate_then_delete_move.yml',
     ],
-    'installable': False,
+    'installable': True,
     'images': [],
     'license': 'AGPL-3',
 }