Skip to main content

Mobile frontend for WMS Shopfloor app

Project description

Alpha License: AGPL-3 OCA/wms Translate me on Weblate Try me on Runbot

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 and VuetifyJS and relies on shopfloor module that exposes REST API in Odoo (based in turn on 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.

Table of contents

Usage

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.

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())

Changelog

13.0.1.0.0

First official version.

Bug Tracker

Bugs are tracked on GitHub Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us smashing it by providing a detailed and welcomed feedback.

Do not contact contributors directly about support or help with technical issues.

Credits

Authors

  • Camptocamp

  • BCIM

  • Akretion

Contributors

Design

Other credits

Financial support

  • Cosanum

  • Camptocamp R&D

  • Akretion R&D

Maintainers

This module is maintained by the OCA.

Odoo Community Association

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.

Current maintainer:

simahawk

This module is part of the OCA/wms project on GitHub.

You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distributions

No source distribution files available for this release.See tutorial on generating distribution archives.

Built Distribution

File details

Details for the file odoo13_addon_shopfloor_mobile-13.0.2.5.1-py3-none-any.whl.

File metadata

File hashes

Hashes for odoo13_addon_shopfloor_mobile-13.0.2.5.1-py3-none-any.whl
Algorithm Hash digest
SHA256 aa16b720e8b88b0928c2abad0aa6cbb668fc08c7b90e9b1d0bbe4ef30bdc48ac
MD5 50a57113ef410b356061ddbac81d0258
BLAKE2b-256 b84134a5e4202119b3f589040f644f9ee7cab28f6fadc45524c506b949183cae

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page