Package: odoo14-addon-shopfloor-mobile
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 detailsThis frontend is built on top ofVueJSandVuetifyJSand relies onshopfloormodule that exposes REST API in Odoo
(based in turn onbase_rest).The whole business logic comes fromshopfloormodule,
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.ImportantThis is an alpha version, the data model and design can change at any time without warning.
Only for development or testing purpose, do not use in production.More details on development statusTable of contentsUsageUsagePre-requisitesYour Odoo instance is accessible via mobile deviceYou have an API Key configuredStart the appGo to “Inventory -> Configuration -> Shopfloor -> Shopfloor App”In the login screen fill in your API keyHit “Login”Select a profileSeveral profiles can be configured in the backend,
you must choose one before starting.Tap on “Configure profile”Select a profileThis will load all available menu items for the selected profile.Change languageGo to “Settings -> Language”Select a languageCustomizationPlease refer toshopfloor_mobile_custom_example.Known issues / RoadmapSplit module by scenarioImprove documentation and demo dataDocument each componentDocument demo modeFind / create a nice iconFinish base translations (move all UI strings to translatable terms)Use SCSSRefactor states definitionStates 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_speccould 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 smarterIn 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 provideon_backproperty 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_.forEachand similar calls to replace them w/ vanilla JS (eg:.map())Changelog13.0.1.0.0First official version.Bug TrackerBugs are tracked onGitHub 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 welcomedfeedback.Do not contact contributors directly about support or help with technical issues.CreditsAuthorsCamptocampBCIMAkretionContributorsSimone 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>DesignJoël Grand-Guillaume <joel.grandguillaume@camptocamp.com>Jacques-Etienne Baudoux <je@bcim.be>Other creditsFinancial supportCosanumCamptocamp R&DAkretion R&DMaintainersThis 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.Currentmaintainer:This module is part of theOCA/wmsproject on GitHub.You are welcome to contribute. To learn how please visithttps://odoo-community.org/page/Contribute.