odoo-addon-shopfloor-mobile 16.0.1.4.0__py3-none-any.whl → 18.0.1.0.1__py3-none-any.whl

odoo/addons/shopfloor_mobile/README.rst

@@ -1,3 +1,7 @@
+.. image:: https://odoo-community.org/readme-banner-image
+   :target: https://odoo-community.org/get-involved?utm_source=readme
+   :alt: Odoo Community Association
+
 ================
 Shopfloor mobile
 ================
@@ -7,58 +11,58 @@ Shopfloor mobile
    !! This file is generated by oca-gen-addon-readme !!
    !! changes will be overwritten.                   !!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-   !! source digest: sha256:e2e8c5dda324092d44eb40ecd4e2bfd44696c59cdc3af9ded861ef7401f7d971
+   !! source digest: sha256:5343b7be8eb4f58f7548ae53194c5554d3a7d9ac639fb64e27cae31cf8cd2766
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
 .. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
     :target: https://odoo-community.org/page/development-status
     :alt: Beta
-.. |badge2| image:: https://img.shields.io/badge/licence-AGPL--3-blue.png
+.. |badge2| image:: https://img.shields.io/badge/license-AGPL--3-blue.png
     :target: http://www.gnu.org/licenses/agpl-3.0-standalone.html
     :alt: License: AGPL-3
-.. |badge3| image:: https://img.shields.io/badge/github-OCA%2Fwms-lightgray.png?logo=github
-    :target: https://github.com/OCA/wms/tree/16.0/shopfloor_mobile
-    :alt: OCA/wms
+.. |badge3| image:: https://img.shields.io/badge/github-OCA%2Fstock--logistics--shopfloor-lightgray.png?logo=github
+    :target: https://github.com/OCA/stock-logistics-shopfloor/tree/18.0/shopfloor_mobile
+    :alt: OCA/stock-logistics-shopfloor
 .. |badge4| image:: https://img.shields.io/badge/weblate-Translate%20me-F47D42.png
-    :target: https://translation.odoo-community.org/projects/wms-16-0/wms-16-0-shopfloor_mobile
+    :target: https://translation.odoo-community.org/projects/stock-logistics-shopfloor-18-0/stock-logistics-shopfloor-18-0-shopfloor_mobile
     :alt: Translate me on Weblate
 .. |badge5| image:: https://img.shields.io/badge/runboat-Try%20me-875A7B.png
-    :target: https://runboat.odoo-community.org/builds?repo=OCA/wms&target_branch=16.0
+    :target: https://runboat.odoo-community.org/builds?repo=OCA/stock-logistics-shopfloor&target_branch=18.0
     :alt: Try me on Runboat
 
 |badge1| |badge2| |badge3| |badge4| |badge5|
 
 Frontend for Shopfloor app.
 
-The work is organized in scenario.
-A scenario represents a process in the warehouse (eg: receive, deliver).
-The app allows to start each process through the main menu.
-
-Each scenario is linked to a specific menu item which can be configured in the backend.
-Each scenario drives you through the work to do.
+The work is organized in scenario. A scenario represents a process in
+the warehouse (eg: receive, deliver). The app allows to start each
+process through the main menu.
 
+Each scenario is linked to a specific menu item which can be configured
+in the backend. Each scenario drives you through the work to do.
 
 Tech details
-~~~~~~~~~~~~
+------------
 
-* This frontend is built on top of `VueJS <vuejs.org>`_  and `VuetifyJS <vuetifyjs.com/>`_
-  and relies on `shopfloor` module that exposes REST API in Odoo
-  (based in turn on `base_rest <https://github.com/OCA/rest-framework/tree/13.0/base_rest>`_).
+- This frontend is built on top of `VueJS <vuejs.org>`__ and
+  `VuetifyJS <vuetifyjs.com/>`__ and relies on shopfloor module that
+  exposes REST API in Odoo (based in turn on
+  `base_rest <https://github.com/OCA/rest-framework/tree/13.0/base_rest>`__).
 
-* The whole business logic comes from `shopfloor` module,
-  this module takes care of providing a nice and reactive UI to work with.
+- The whole business logic comes from shopfloor module, this module
+  takes care of providing a nice and reactive UI to work with.
 
-* No Odoo JS is used, no assets machinery used.
+- No Odoo JS is used, no assets machinery used.
 
   Static assets are loaded straight, served by a specific controller.
   This app is a Single Page App, hence resources are loaded only once.
 
-  The version of the module appended to the URL of each resources
-  makes sure it's not cached when the version changes.
+  The version of the module appended to the URL of each resources makes
+  sure it's not cached when the version changes.
 
-* When developing you can use a demo mode which allows to define interactive scenario
-  with pure JS demo data, without interacting with Odoo.
-  Nothing to deal with Odoo demo data.
+- When developing you can use a demo mode which allows to define
+  interactive scenario with pure JS demo data, without interacting with
+  Odoo. Nothing to deal with Odoo demo data.
 
 **Table of contents**
 
@@ -69,88 +73,102 @@ Usage
 =====
 
 Pre-requisites
-~~~~~~~~~~~~~~
+--------------
 
-* Your Odoo instance is accessible via mobile device
-* You have an API Key configured
+- Your Odoo instance is accessible via mobile device
+- You have an API Key configured
 
 Start the app
-~~~~~~~~~~~~~
+-------------
 
-* Go to "Inventory -> Configuration -> Shopfloor -> Shopfloor App"
-* In the login screen fill in your API key
-* Hit "Login"
+- Go to "Inventory -> Configuration -> Shopfloor -> Shopfloor App"
+- In the login screen fill in your API key
+- Hit "Login"
 
 Select a profile
-~~~~~~~~~~~~~~~~
+----------------
 
-Several profiles can be configured in the backend,
-you must choose one before starting.
+Several profiles can be configured in the backend, you must choose one
+before starting.
 
-* Tap on "Configure profile"
-* Select a profile
+- Tap on "Configure profile"
+- Select a profile
 
 This will load all available menu items for the selected profile.
 
 Change language
-~~~~~~~~~~~~~~~
+---------------
 
-* Go to "Settings -> Language"
-* Select a language
+- Go to "Settings -> Language"
+- Select a language
 
 Customization
-~~~~~~~~~~~~~
+-------------
 
-Please refer to `shopfloor_mobile_custom_example`.
+Please refer to shopfloor_mobile_custom_example.
 
 Known issues / Roadmap
 ======================
 
-* Split module by scenario
-* Improve documentation and demo data
-* Document each component
-* Document demo mode
-* Find / create a nice icon
-* Finish base translations (move all UI strings to translatable terms)
-* Use SCSS
-* Refactor states definition
-
-  States are now part of the scenario data. They should be specific objects with their own class.
-  They should also provide all the actions that should be displayed w/ their handlers when needed.
-  Actions can be popup actions or buttons at the bottom of the screen.
-  The tricky part here could be how to register this states for the given component.
-  Today states have access to the full object of the scenario component as they are part of it.
-  `_get_state_spec` could probably lookup for registered states
-  (eg: when you register a component in the registry you should provide states as well).
-  When we'll have states in this fashion we should also consider if they should provide their own template.
-  This way the component template will hold only the generic bits of the scenario.
-
-* Back buttons should be smarter
-
-  In some cases getting back using history is fine but very often this could lead to outdated data display.
-  To mitigate this in particular scenario's steps, custom handlers for the back action have been implemented.
-  For instance, in cluster_picking when you hit back on manual selection it forces the state to go to start and reload.
-  For starting we should provide `on_back` property to all states where we want to display it
-  (no more specific check on the state to display this button).
-  This part is also related to "Refactor states definition".
-
-* Go through `_.forEach` and similar calls to replace them w/ vanilla JS (eg: `.map()`)
+- Split module by scenario
+
+- Improve documentation and demo data
+
+- Document each component
+
+- Document demo mode
+
+- Find / create a nice icon
+
+- Finish base translations (move all UI strings to translatable terms)
+
+- Use SCSS
+
+- Refactor states definition
+
+  States are now part of the scenario data. They should be specific
+  objects with their own class. They should also provide all the actions
+  that should be displayed w/ their handlers when needed. Actions can be
+  popup actions or buttons at the bottom of the screen. The tricky part
+  here could be how to register this states for the given component.
+  Today states have access to the full object of the scenario component
+  as they are part of it. \_get_state_spec could probably lookup for
+  registered states (eg: when you register a component in the registry
+  you should provide states as well). When we'll have states in this
+  fashion we should also consider if they should provide their own
+  template. This way the component template will hold only the generic
+  bits of the scenario.
+
+- Back buttons should be smarter
+
+  In some cases getting back using history is fine but very often this
+  could lead to outdated data display. To mitigate this in particular
+  scenario's steps, custom handlers for the back action have been
+  implemented. For instance, in cluster_picking when you hit back on
+  manual selection it forces the state to go to start and reload. For
+  starting we should provide on_back property to all states where we
+  want to display it (no more specific check on the state to display
+  this button). This part is also related to "Refactor states
+  definition".
+
+- Go through \_.forEach and similar calls to replace them w/ vanilla JS
+  (eg: .map())
 
 Changelog
 =========
 
 13.0.1.0.0
-~~~~~~~~~~
+----------
 
 First official version.
 
 Bug Tracker
 ===========
 
-Bugs are tracked on `GitHub Issues <https://github.com/OCA/wms/issues>`_.
+Bugs are tracked on `GitHub Issues <https://github.com/OCA/stock-logistics-shopfloor/issues>`_.
 In case of trouble, please check there if your issue has already been reported.
 If you spotted it first, help us to smash it by providing a detailed and welcomed
-`feedback <https://github.com/OCA/wms/issues/new?body=module:%20shopfloor_mobile%0Aversion:%2016.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.
+`feedback <https://github.com/OCA/stock-logistics-shopfloor/issues/new?body=module:%20shopfloor_mobile%0Aversion:%2018.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.
 
 Do not contact contributors directly about support or help with technical issues.
 
@@ -158,39 +176,38 @@ Credits
 =======
 
 Authors
-~~~~~~~
+-------
 
 * Camptocamp
 * BCIM
 * Akretion
 
 Contributors
-~~~~~~~~~~~~
+------------
 
-* Simone Orsi <simahawk@gmail.com>
-* Thierry Ducrest <thierry.ducrest@camptocamp.com>
-* Guewen Baconnier <guewen.baconnier@camptocamp.com>
-* Raphaël Reverdy <raphael.reverdy@akretion.com>
-* Sébastien Beau <sebastien.beau@akretion.com>
-* Jacques-Etienne Baudoux <je@bcim.be>
+- Simone Orsi <simahawk@gmail.com>
+- Thierry Ducrest <thierry.ducrest@camptocamp.com>
+- Guewen Baconnier <guewen.baconnier@camptocamp.com>
+- Raphaël Reverdy <raphael.reverdy@akretion.com>
+- Sébastien Beau <sebastien.beau@akretion.com>
+- Jacques-Etienne Baudoux <je@bcim.be>
 
-Design
-~~~~~~
+**Design**
 
-* Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com>
-* Jacques-Etienne Baudoux <je@bcim.be>
+- Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com>
+- Jacques-Etienne Baudoux <je@bcim.be>
 
 Other credits
-~~~~~~~~~~~~~
+-------------
 
 **Financial support**
 
-* Cosanum
-* Camptocamp R&D
-* Akretion R&D
+- Cosanum
+- Camptocamp R&D
+- Akretion R&D
 
 Maintainers
-~~~~~~~~~~~
+-----------
 
 This module is maintained by the OCA.
 
@@ -210,6 +227,6 @@ Current `maintainer <https://odoo-community.org/page/maintainer-role>`__:
 
 |maintainer-simahawk| 
 
-This module is part of the `OCA/wms <https://github.com/OCA/wms/tree/16.0/shopfloor_mobile>`_ project on GitHub.
+This module is part of the `OCA/stock-logistics-shopfloor <https://github.com/OCA/stock-logistics-shopfloor/tree/18.0/shopfloor_mobile>`_ project on GitHub.
 
 You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.

odoo/addons/shopfloor_mobile/__manifest__.py

@@ -5,11 +5,11 @@
 {
     "name": "Shopfloor mobile",
     "summary": "Mobile frontend for WMS Shopfloor app",
-    "version": "16.0.1.4.0",
+    "version": "18.0.1.0.1",
     "depends": ["shopfloor", "shopfloor_mobile_base"],
     "author": "Camptocamp, BCIM, Akretion, Odoo Community Association (OCA)",
     "maintainers": ["simahawk"],
-    "website": "https://github.com/OCA/wms",
+    "website": "https://github.com/OCA/stock-logistics-shopfloor",
     "category": "Warehouse Management",
     "license": "AGPL-3",
     "installable": True,

odoo/addons/shopfloor_mobile/i18n/shopfloor_mobile.pot

@@ -3,7 +3,7 @@
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: Odoo Server 16.0\n"
+"Project-Id-Version: Odoo Server 18.0\n"
 "Report-Msgid-Bugs-To: \n"
 "Last-Translator: \n"
 "Language-Team: \n"

odoo/addons/shopfloor_mobile/readme/CONTRIBUTORS.md

@@ -0,0 +1,11 @@
+- Simone Orsi \<<simahawk@gmail.com>\>
+- Thierry Ducrest \<<thierry.ducrest@camptocamp.com>\>
+- Guewen Baconnier \<<guewen.baconnier@camptocamp.com>\>
+- Raphaël Reverdy \<<raphael.reverdy@akretion.com>\>
+- Sébastien Beau \<<sebastien.beau@akretion.com>\>
+- Jacques-Etienne Baudoux \<<je@bcim.be>\>
+
+**Design**
+
+- Joël Grand-Guillaume \<<joel.grandguillaume@camptocamp.com>\>
+- Jacques-Etienne Baudoux \<<je@bcim.be>\>

odoo/addons/shopfloor_mobile/readme/CREDITS.md

@@ -0,0 +1,5 @@
+**Financial support**
+
+- Cosanum
+- Camptocamp R&D
+- Akretion R&D

odoo/addons/shopfloor_mobile/readme/DESCRIPTION.md

@@ -0,0 +1,30 @@
+Frontend for Shopfloor app.
+
+The work is organized in scenario. A scenario represents a process in
+the warehouse (eg: receive, deliver). The app allows to start each
+process through the main menu.
+
+Each scenario is linked to a specific menu item which can be configured
+in the backend. Each scenario drives you through the work to do.
+
+## Tech details
+
+- This frontend is built on top of [VueJS](vuejs.org) and
+  [VuetifyJS](vuetifyjs.com/) and relies on shopfloor module that
+  exposes REST API in Odoo (based in turn on
+  [base_rest](https://github.com/OCA/rest-framework/tree/13.0/base_rest)).
+
+- The whole business logic comes from shopfloor module, this module
+  takes care of providing a nice and reactive UI to work with.
+
+- No Odoo JS is used, no assets machinery used.
+
+  Static assets are loaded straight, served by a specific controller.
+  This app is a Single Page App, hence resources are loaded only once.
+
+  The version of the module appended to the URL of each resources makes
+  sure it's not cached when the version changes.
+
+- When developing you can use a demo mode which allows to define
+  interactive scenario with pure JS demo data, without interacting with
+  Odoo. Nothing to deal with Odoo demo data.

odoo/addons/shopfloor_mobile/readme/{HISTORY.rst → HISTORY.md}

@@ -1,4 +1,3 @@
-13.0.1.0.0
-~~~~~~~~~~
+## 13.0.1.0.0
 
 First official version.

odoo/addons/shopfloor_mobile/readme/ROADMAP.md

@@ -0,0 +1,43 @@
+- Split module by scenario
+
+- Improve documentation and demo data
+
+- Document each component
+
+- Document demo mode
+
+- Find / create a nice icon
+
+- Finish base translations (move all UI strings to translatable terms)
+
+- Use SCSS
+
+- Refactor states definition
+
+  States are now part of the scenario data. They should be specific
+  objects with their own class. They should also provide all the actions
+  that should be displayed w/ their handlers when needed. Actions can be
+  popup actions or buttons at the bottom of the screen. The tricky part
+  here could be how to register this states for the given component.
+  Today states have access to the full object of the scenario component
+  as they are part of it. \_get_state_spec could probably lookup for
+  registered states (eg: when you register a component in the registry
+  you should provide states as well). When we'll have states in this
+  fashion we should also consider if they should provide their own
+  template. This way the component template will hold only the generic
+  bits of the scenario.
+
+- Back buttons should be smarter
+
+  In some cases getting back using history is fine but very often this
+  could lead to outdated data display. To mitigate this in particular
+  scenario's steps, custom handlers for the back action have been
+  implemented. For instance, in cluster_picking when you hit back on
+  manual selection it forces the state to go to start and reload. For
+  starting we should provide on_back property to all states where we
+  want to display it (no more specific check on the state to display
+  this button). This part is also related to "Refactor states
+  definition".
+
+- Go through \_.forEach and similar calls to replace them w/ vanilla JS
+  (eg: .map())

odoo/addons/shopfloor_mobile/readme/USAGE.md

@@ -0,0 +1,29 @@
+## Pre-requisites
+
+- Your Odoo instance is accessible via mobile device
+- You have an API Key configured
+
+## Start the app
+
+- Go to "Inventory -\> Configuration -\> Shopfloor -\> Shopfloor App"
+- In the login screen fill in your API key
+- Hit "Login"
+
+## Select a profile
+
+Several profiles can be configured in the backend, you must choose one
+before starting.
+
+- Tap on "Configure profile"
+- Select a profile
+
+This will load all available menu items for the selected profile.
+
+## Change language
+
+- Go to "Settings -\> Language"
+- Select a language
+
+## Customization
+
+Please refer to shopfloor_mobile_custom_example.