Scope

This page captures generalized user stories related to how OpenLMIS will behave in low-bandwidth and completely offline situations. This page shouldn't capture non-functional requirements such as caching strategies.

Background

OpenLMIS is developed to support "the last mile," which means that internet connectivity can be extremely inconsistent. The following features seek to improve the performance of client applications that are operating offline.

User Stories

Feature	Tickets
Add build date to UI By adding a build date to the UI, we are helping people understand how recent the version of the OpenLMIS-UI they are using is. This will also help service desk staff debug of escalate bugs.	OLMIS-3166 - Getting issue details... STATUS
Service workers for file caching Service workers are a relatively new API that is built into Chrome, Firefox, and Edge. A service worker can do many things, but it makes caching and updating the cached files in a browser extremely easy. Updating the website is done in a background process of the browser. NOTE: Caching and updating files can be accomplished with an appcache.manifest file, which the OpenLMIS-UI currently uses. The primary reason to change the OpenLMIS-UI's approach to saving documents is that many browsers are warning that support for appcache.manifest will be dropped (eventually).
Download of facility and program data Generally the OpenLMIS-UI downloads and stores data only when it needs it, which could leave users in situations where they need to connect to the internet to take an action that needs information associated with a facility or program. Allowing users to decide if they want to store the products and stock levels associated with a program and or facility will create a faster user experience when doing data entry. If the user has requested to store this data, the OpenLMIS-UI can periodically update the stored information while the user is using the application.
Background HTTP Requests A common approach to offline applications is to communicate information to the server using background HTTP requests. This is ideal for environments where internet latency is high, and users don't want to wait for requests to complete before moving on to a secondary task. To meaningfully enable background HTTP requests, the OpenLMIS-UI will need a page (or section of the UI) to show the state of background HTTP requests and a workflow that will allow the user to retry the request they were working on. It's reasonable that this page in the OpenLMIS-UI could also show users "in-app" notifications. Technically, allowing the UI to complete a HTTP request in the background is not much different than how other HTTP requests are implemented. The challenging part of implementing these features will be choosing when a HTTP request should be completed in the background, rather than locking the user experience.
Document Sync Conflict Resolution Documents, like requisitions or physical inventories, can have different states

Browser not supported