As a researcher working in SEAD's Project Spaces, I want to test the publishing functionality to see how the process works (with test data) and to get an idea of how my publication will look.

Background: SEAD has 3 major types of components that have independent build/release cycles: project spaces, c3pr services, and repository implementations/connectors. We've been running two instances of c3pr -seadva-test that has the latest code and only mints test DOIs, and seadva that has the latest stable code (may or may not be the same code or config as seadva-test) and always mints real DOIs. 1.5 spaces can be configured by a space admin to point at either c3pr instance. sead2-dev and sead2-beta both point at seadva-test today but can be configured by a sysadmin to point to seadva. Repositories can register a profile with either c3pr service and can make their own decisions about whether to run one or more instances (for example, IU Cloud/SDA runs one instance for each c3pr). We also support a "Testing-Only' preference set by project space users which, currently, allows deletion of pub requests through the api after repository processing has begun (so test requests can easily be cleaned up). Nominally, development-focused testing should be supported in parallel with user-driven testing capabilities.

Acceptance Criteria:
1. A SEAD user can create a test publication from a dataset in their project space. (note: when their project space is in trial mode, this is the only kind of publication they can generate)

2. The test publication has a limited lifetime (are deleted/deletable/replaced on the timescale of days to weeks (e.g. the 2 week period that test DOIs remain functional).

3. SEAD offers at least one repository capable of processing test publications and should have a well-defined mechanism for any partner repository to provide test publication services

4. Test publications are clearly marked as such throughout the process, particularly after publication (e.g. so that users know not to cite test DOIs)

5. SEAD test publication do not appear along with "real" publication listings, search, stats.

6. Developers and internal SEAD testers are able to try any combination of space/c3pr/repository versions required for dev/debug/test purposes

Some additional comments from Jim:

• It would be valuable for the test capability to use the same code and configuration choices to avoid cases where test publications may succeed/fail independently of the real publication process (which has already occurred).
• It would be useful if at least SEAD admins (superadmin) could send the same Dataset to current/new versions of c3pr and/or repositories (e.g. that the ability to make this selection is part of the 2.0 GUI and not a sysadmin option)
  It would be desirable for users to not need to know information such as the URLs of c3pr instances to make their choice (e.g. the GUI should hide this detail if the design uses multiple instances, or the choice should use a Preference flag such as the "Testing-Only" one if one c3pr instance will handle both cases, etc.)