To effectively use XRAS, you must understand the six core concepts described in this section. The workflow assumptions built into XRAS are based on the concepts of Projectsprojects, Allocationsallocations, Requestsrequests, Rolesroles, Transactionstransactions, and Opportunitiesopportunities. We define and describe them here since they affect the rest of this document.
Projects
The concept of a Project “project” is central to the value XRAS provides to your allocations process. A Projectproject, assigned a unique identifier (in a format of your choosing), encompasses all the Requestsrequests, Allocationsallocations, Reviewsreviews, and Transactions transactions spanning the history of a line of work supported by your institution’s resources. Projects may be short and consist of a single Request request (e.g., a Project project to support a single training course or workshop) or long and encompassing many Requests requests (e.g., a Project project spanning many years of research by the same lead investigator). The linkages provided by Projects projects let you easily see the history of a project and allow reviewers to look at prior Requests requests and reviews to see if progress has been made or if previous reviewers’ concerns have been addressed in the latest submission.
...
It would be difficult to have any discussion about XRAS without defining “allocationsan “allocation.” In casual conversation, the term allocation can refer to different concepts, so we must define it clearly for the purposes of this document.
In XRAS, an Allocation allocation is defined as an amount of consumable units on (or approved access to) a specific resource for a defined time period bounded by start and end dates. XRAS allows you to track the amounts requested by users, recommended by reviewers, and awarded by your site for every allocation.
Significantly, XRAS does not allow Allocations allocations for the same resource on the same Project project to overlap in time. Such Allocations allocations may be contiguous or have gaps, but they cannot overlap. The various transactions defined later in this section can be used to manage most scenarios without the need for overlapping allocations.
...
The allocations process model embodied within XRAS revolves around the notion of Requests“requests.” A Request request is a fully detailed submission to be reviewed and processed to initiate or re-initiate an allocation or set of allocations. In most cases, you can think of a Request request in its non-technical sense: a person is asking for an Allocation allocation or Allocations allocations for their Projectproject.
XRAS recognizes two types of allocation Requestsrequests: New new and Renewalrenewal. A New new request will cause a new Project project to be created and indicates that there is no prior history to the proposed line of work. A Renewal renewal can only be submitted for an existing Projectproject. A Renewal renewal typically requires the same or similar detail as a New new request and is intended to create a fresh set of allocations (i.e., covering a new time period) that begin after the current or prior set of allocations associated with the Projectproject. You can customize XRAS rules to define when New new and Renewal renewal requests are permissible.
...
Project Management Actions
While the allocations awarded to a project as the result of processing a New new or Renewal Request renewal request are active, XRAS supports a range of transactions “actions” that can be used to manage or modify the active allocations for a project.
As an administrator, you can specify which Actions actions are permitted during your organization’s resource allocations, when they happen, and which rules apply to each of them. If your process needs an Action action that doesn’t already exist in XRAS, you can request a new Action action type by contacting the XRAS team via help@xsede allocations@access-ci.org. XRAS currently supports seven defined transactionsactions:
Extension. An Extension extension will move the end date for all of a Project’s project’s current Allocations allocations on active resources. No additional allocation amounts can be added as part of an Extensionextension.
Supplement. With a Supplementsupplement, a user can ask for additional allocation amounts to be added to all or some of their current allocations. A Supplement supplement does not change the end dates for any allocation.
Appeal. An Appeal appeal is a special case of a Supplement supplement that allows a user to contest the results of an Allocation allocation decision, often by correcting a reviewers’ misinterpretation or by providing missing details requested by the reviewer. XRAS allows you to define a window during which Appeals appeals may be submitted (e.g., within 30 days of an award being made).
Transfer. Within a given Projectproject, a user can ask for allocated resource units to be moved from one resource allocation to another. Typically, some amount is subtracted from one allocation and added to another allocation.
Advance. Another special case of a Supplementsupplement, in which additional allocation amounts are sought immediately, in anticipation of a future allocation award. Typically, the approved Advance advance is added to a current allocation. Later, when the future allocation is made, it is reduced by all or some of the advanced amount.
Adjustment. An Adjustment adjustment may be entered by XRAS admins to make changes to a Project’s Allocationsproject’s allocations, for any reason, usually to accommodate unusual situations that may arise. Users cannot request Adjustments adjustments via the XRAS Submit UI.
Progress Report. This transaction action allows a user to submit a statement of progress on a Projectproject. A Progress Report progress report requires no processing and does not affect a Project’s allocationsproject’s allocations. Note that a progress report document can be required as part of other actions.
Final Report. This transaction action allows a user to formally close out a project by attaching a final report without asking for any additional allocations. This allows you to capture outcomes from users who have completed a project but who are not planning to submit a Renewal renewal request for that line of work.
XRAS allows you to configure rules to control if and when users are allowed to submit the different transactionsactions. For example, you may not want to allow a transfer to be requested within one week of a Project’s project’s current allocations ending. You can control if and when Actions actions are permitted based on the dates and the status of their original allocation Requestsrequests.
Users and Roles
The persons involved with an allocation request play a key part in the process. XRAS has a number of roles for persons who can view and edit a request, as well as additional individuals whose names may be part of the request’s data fields.
For the most part, XRAS is concerned with individuals insofar as they are assigned one of three specific roles associated with allocation requests. Once a person is added to a request in any of these roles, the request will be visible to (and modifiable by, per your rules) that person when they authenticate to XRAS Submit. Below, the role name used by XSEDE ACCESS is presented first; alternate names are shown in parentheses. You can customize the visible role names using the XRAS Client Settings.
...
Opportunities
The notion of Opportunity “opportunity” helps organize the XRAS workflow and can generally be thought of as “a chance to submit Requests requests of a certain type.” The types are defined by your allocations policies and entered into XRAS as part of your initial configuration. Each Opportunity opportunity requires an associated Panel “panel” to review the requests, although the Panel panel may be composed only of you and your allocations staff. XRAS also supports multi-phase review processes involving more than one panel.
Opportunities come in two flavors: Terminating terminating and Continuouscontinuous. Terminating opportunities have fixed submission deadlines and are typically associated with larger-scale requests that are sent to a review panel and meeting. XRAS also supports multi-phase review processes involving more than one panel. Continuous opportunities allow users to submit requests at any time, and incoming requests are typically reviewed and processed as they arrive, often with minimal review by your allocations staff.