Card Config

Overview

Card Config is intended to replace the hardcoded cards created by developers with content that can be created by system administrators. In the old system, a seemingly simple task like changing a piece of text on a card requires a JIRA ticket and a full release cycle to accomplish. With Card Config that same change can be reflected to production much sooner. Cards are represented as an XML document that can be edited directly from Aperta. See How to create Card Config card content for a detailed overview of how to do this.

Card Config has a few technical terms that are laid out in Shared Vocabulary to avoid confusion.

Using Card Config

The goal for Card Config is to allow 100% of a Card's content to be authored by non-developers, likely system administrators.

How to create Card Config card content documents how to work with Card Config from a system admin's perspective, but is also essential reading for developers.

A given Card can have many versions active in the system. A Card will start its life as a draft, and then will need to be 'published' before it can be added to a workflow. Any new Paper will always use the latest version of a Card. When administrators make any change to the content of a card, the system will create a new version of that Card, and the change will not affect existing papers. The Card Lifecycle goes into greater detail.

Privileges for users to interact with a custom Card are set on a per Card basis in the Card editor. The permissions screen is described in Custom Card Permissions .

For Developers

A representation of the current database schema relevant to Card Config is located at Card Config Schema.
Ember renders the CardContent for a given card dynamically on the client. Card Config Rendering Overview briefly mentions the pieces involved.
If you're going to migrate an existing card into Card Config, Card Config Migrations is the canonical document to read. The PR for APERTA-10397 - Migrate Manuscript card Closed will also be a good place to go for the results of the migration.
The Card Content Type Maintenance Guide describes the files you'll need to change if you're adding a new type of card content into the system.

Ongoing Work

In addition to the work of moving cards into the Card Config system, we are also making adjustments to the Card Config system itself as we go.

Card Config Migrations - Proposal is an effort to make the html markup generated by the Card Config system more consistent.
The current Card Config system lacks some of the more arbitrary flexibility that Aperta's existing hardcoded cards possess. The Event Driven Architecture allows custom Cards to broadcast events that the system listens for. The Event Driven Architecture will eventually allow for behaviors like completing Cards or sending emails, and for these behaviors to be configured from custom Cards.
Card Loading and Data Seeding Update Proposal attempts to describe a better process by which we manage the data for new Card Config cards, especially for future journals that are not PLOS Biology
Card Migrations Tracking is just that {.emoticon .emoticon-smile}. Over some months we have been moving the existing Cards in Aperta (which were hard-coded by developers) into the Card Config. Further migrations are on hold at the moment but this page should be current.