The Card Lifecycle

Card States

Cards move through a number of states as they're created and put into use.

Draft

All Cards are created in a draft state. Draft Cards are light blue in the admin UI.

A draft Card can't be added to any Workflow Templates or to any Workflows. Saving a draft Card will overwrite its contents. Users are expected to enter some historical commentary when they publish a Card.

Published

Once a Card is published it can be added to Workflow Templates and Workflows. Published cards are dark blue in the admin UI.

Published With Changes

If a user saves changes to a published card, it goes into the "published with changes" state.

A published card will only have 1 draft of its next version at any given time. Users can discard that draft or publish the new version. **Publishing a new version will not affect papers that have the current version. **The new version will only be applied to newly submitted papers. This is discussed further in the Card Versioning section.

Archived

Archived Cards can't be added to any new papers, but they will continue to exist on papers that are in flight.

Card Versioning

A given Card can have many versions that exist side by side in Aperta. When a Paper is created, the latest version of each Card specified in the Workflow Template will be added to the Paper. The same is true when a Card is manually added to a Workflow after a Paper has been created. The lastest version is the one that will be added.

When an administrator publishes a new version of a Card, existing Papers will keep their (older) version of the Card.

The "immutable" versioning scheme we chose has some benefits and drawbacks. Users enter specific answers based on the content of a Card's version. If we tried to "migrate" those answers from version 1 to version 2, for instance, there's a chance that the original answers a user posed for version 1 would not make sense for version 2. Staff would have to decide what constituted a "breaking" change in that case. End users might or might not have to re enter their answers, or check to see that their answers were migrated correctly during a version change. The immutable versioning scheme keeps the user experience simple. It also makes the implementation simple.

A drawback to the immutable versioning scheme is that a content change on par with fixing a typo also warrants a new Card version. If administrators really wish to change the content of a version that's being used by papers in the system, they'll still need to ask the Aperta development team to write a data migration to do so.