specs/models/M_APP_VER
App Versions
An App Version is a saved state of an app that will use the same logic and visuals every time it is run in the Tulip Player.
There are three types of versions:
- Development Version: This cannot be run in the Tulip Player. It is a test version of the app that is meant for testing logic and visuals that have been created in the App Editor.
- Published Version: This is an immutable, saved state of the app that can be used by a device running the Tulip Player. These can be “restored” to the development version at any time, which will replace all content in the development version.
- Snapshot: This cannot be run in the Tulip Player. It is meant for app builders that want to store a version of the app outside of the versioning system that they may want to return to later.
An App Version must be approved using a series of App Approvals before it can be published and released to the Tulip Player.
An App Version can have five states:
- Development: Described above. Cannot be used in the Tulip Player.
- Published pending approval: Published by the app builder, but has not received a review from an approver within every App Approval yet
- Published: Approved by at least one approver in every App Approval and can be run in the Tulip Player
- Rejected: At least one approver has rejected the version and it cannot be used in the Player
- Approval request cancelled: sAn app builder realized a mistake and canceled the request for approval.
It contains the following Models:
The following Models can be changed and will automatically update within published versions. This means that they can impact published versions from outside of the app publishing system.
The following Models are versioned alongside the app version, and therefore that means that they cannot impact published versions if they are changed:
Fields
| Name | Description |
| Version Number | A number that automatically increments by 1 every time a new version is published. Cannot be edited by user. |
| Publisher | The name of the user that initiated the publishing workflow |
| Description | An optional description fields for details about the version |
| Publish Time | The timestamp that the publishing workflow was completed and the version was released |
| Completion List | This can be seen on the App Completions Page. A list of all completions related to the version |
| App Triggers | Triggers that can be fired upon the following events:
|
Tests
| ID | Name |
|---|---|
| QA-T327 | Apps Page : 05 - App Versions |
| QA-T720 | Apps Page : 05 / Failing to edit older App Versions |
Requirements
| ID | Requirement |
|---|---|
| 15 | Provide ability to apply status to managed content. E.g. Development, In Review, Released, Published, etc. |
| 16 | Manage the release to use of content based on approval status. |
| 49 | Provide a managed way to configure and maintain content including creating, copying, editing, making obsolete, and deleting. |
| 50 | Disallow deletion of content that have been used in execution of a work order or material processing. |
| 53 | All content must have configurable version control. |
| 98 | Ability to view current process step in the context of the executing production model. |
| 121 | Ability to define procedural sequences with relevant process information that can guide an operator through task execution. |
| 461 | Only approved content can be used for production execution activities |
| 806 | All records shall be Enduring, ie. store, managed and unalterable for the full retention period. |
| 827 | Ability to capture data during App execution and identify the data with the version of the App that was used and its status in the workflow. ie. be able to identify if data was generated during App testing, review or approved states. |
| 850 | Ability to test Apps in production execution during the development and review process. |