@reqquest/ui 1.8.1 → 1.9.1

package/dist/components/PromptDisplayGrid.svelte

@@ -0,0 +1,47 @@
+<!--
+  @component
+  Lays out a prompt's display data as challenge/response rows that align with the
+  surrounding prompt list, for prompts that collect several question/answer pairs in a
+  single form but should read as individual rows on the review screens. Rows take on
+  the same padding and border treatment as the prompt rows around them, so each
+  challenge/response is indistinguishable from a standalone prompt.
+
+  Place this as the root element of a `displayComponent` and register the prompt with
+  `displayMode: 'large'`. The full-width answer area becomes a subgrid of the prompt
+  list, so rows share the exact column tracks of the real prompt rows around them and
+  wrap at the same breakpoints. Fill it with `PromptDisplayRow` children; pass `full`
+  on a row to span the entire width.
+
+  It may also be the root element of a `formComponent` registered with
+  `formMode: 'large'`: the reviewer screen's inline edit form is bridged into the same
+  subgrid, so rows of field inputs align with the prompt rows too. Rendered anywhere
+  without a prompt list around it (the edit modal, applicant pages), the grid falls back
+  to laying out its own two columns.
+-->
+<dl class="prompt-display-grid">
+  <slot />
+</dl>
+
+<style>
+  dl.prompt-display-grid {
+    display: grid;
+    grid-column: 1 / -1;
+    /* The review screens set --prompt-display-subgrid: subgrid when this grid is positioned
+       to share their prompt-list tracks. Anywhere else (edit modals, applicant pages) it
+       lays out its own two columns so full rows and placement still work. */
+    grid-template-columns: var(--prompt-display-subgrid, var(--prompt-display-columns, fit-content(50%) minmax(0, 1fr)));
+    align-items: stretch;
+    row-gap: var(--prompt-display-row-gap, 0);
+    margin: 0;
+  }
+  dl.prompt-display-grid > :global(.prompt-display-challenge),
+  dl.prompt-display-grid > :global(.prompt-display-response),
+  dl.prompt-display-grid > :global(.prompt-display-full) {
+    border-bottom: 1px solid var(--cds-border-subtle);
+    padding: var(--prompt-display-row-padding, 1rem 15px);
+  }
+  dl.prompt-display-grid > :global(.prompt-display-challenge),
+  dl.prompt-display-grid > :global(.prompt-display-full) {
+    padding-left: calc(var(--prompt-display-challenge-padding-left, 32px) + var(--prompt-display-indent, 0) * var(--prompt-display-indent-size, 1rem));
+  }
+</style>

package/dist/components/PromptDisplayGrid.svelte.d.ts

@@ -0,0 +1,45 @@
+export default PromptDisplayGrid;
+type PromptDisplayGrid = SvelteComponent<any, {
+    [evt: string]: CustomEvent<any>;
+}, {
+    default: {};
+}> & {
+    $$bindings?: string | undefined;
+};
+/**
+ * Lays out a prompt's display data as challenge/response rows that align with the
+ * surrounding prompt list, for prompts that collect several question/answer pairs in a
+ * single form but should read as individual rows on the review screens. Rows take on
+ * the same padding and border treatment as the prompt rows around them, so each
+ * challenge/response is indistinguishable from a standalone prompt.
+ *
+ * Place this as the root element of a `displayComponent` and register the prompt with
+ * `displayMode: 'large'`. The full-width answer area becomes a subgrid of the prompt
+ * list, so rows share the exact column tracks of the real prompt rows around them and
+ * wrap at the same breakpoints. Fill it with `PromptDisplayRow` children; pass `full`
+ * on a row to span the entire width.
+ *
+ * It may also be the root element of a `formComponent` registered with
+ * `formMode: 'large'`: the reviewer screen's inline edit form is bridged into the same
+ * subgrid, so rows of field inputs align with the prompt rows too. Rendered anywhere
+ * without a prompt list around it (the edit modal, applicant pages), the grid falls back
+ * to laying out its own two columns.
+ */
+declare const PromptDisplayGrid: $$__sveltets_2_IsomorphicComponent<any, {
+    [evt: string]: CustomEvent<any>;
+}, {
+    default: {};
+}, {}, string>;
+interface $$__sveltets_2_IsomorphicComponent<Props extends Record<string, any> = any, Events extends Record<string, any> = any, Slots extends Record<string, any> = any, Exports = {}, Bindings = string> {
+    new (options: import("svelte").ComponentConstructorOptions<Props>): import("svelte").SvelteComponent<Props, Events, Slots> & {
+        $$bindings?: Bindings;
+    } & Exports;
+    (internal: unknown, props: {
+        $$events?: Events;
+        $$slots?: Slots;
+    }): Exports & {
+        $set?: any;
+        $on?: any;
+    };
+    z_$$bindings?: Bindings;
+}

package/dist/components/PromptDisplayRow.svelte

@@ -0,0 +1,42 @@
+<!--
+  @component
+  One challenge/response row inside a `PromptDisplayGrid`. The challenge lands in the
+  same column as the prompt titles around it and the response in the answer column.
+
+  - `challenge` prop or slot for the question, default slot for the answer.
+  - `full` spans the entire grid width instead, for content that needs the whole row
+    (documents, notes, notifications).
+  - `indentLevel` indents the challenge (or full-row content) to suggest hierarchy,
+    e.g. follow-up questions under a parent question.
+-->
+<script lang="ts">
+  /** The question being answered. Use the `challenge` slot instead if you need markup. */
+  export let challenge: string | undefined = undefined
+  /** Span the full width of the grid instead of splitting into challenge/response. */
+  export let full = false
+  /**
+   * Indent the challenge (or full-row content) by this multiple of a small indent unit
+   * (1rem per level, tunable with --prompt-display-indent-size). Default 0.
+   */
+  export let indentLevel = 0
+</script>
+
+{#if full}
+  <div class="prompt-display-full" style:--prompt-display-indent={indentLevel || undefined}><slot /></div>
+{:else}
+  <dt class="prompt-display-challenge" style:--prompt-display-indent={indentLevel || undefined}><slot name="challenge">{challenge}</slot></dt>
+  <dd class="prompt-display-response"><slot /></dd>
+{/if}
+
+<style>
+  dt.prompt-display-challenge {
+    grid-column: 1;
+  }
+  dd.prompt-display-response {
+    grid-column: 2;
+    margin: 0;
+  }
+  div.prompt-display-full {
+    grid-column: 1 / -1;
+  }
+</style>

package/dist/components/PromptDisplayRow.svelte.d.ts

@@ -0,0 +1,46 @@
+interface $$__sveltets_2_IsomorphicComponent<Props extends Record<string, any> = any, Events extends Record<string, any> = any, Slots extends Record<string, any> = any, Exports = {}, Bindings = string> {
+    new (options: import('svelte').ComponentConstructorOptions<Props>): import('svelte').SvelteComponent<Props, Events, Slots> & {
+        $$bindings?: Bindings;
+    } & Exports;
+    (internal: unknown, props: Props & {
+        $$events?: Events;
+        $$slots?: Slots;
+    }): Exports & {
+        $set?: any;
+        $on?: any;
+    };
+    z_$$bindings?: Bindings;
+}
+type $$__sveltets_2_PropsWithChildren<Props, Slots> = Props & (Slots extends {
+    default: any;
+} ? Props extends Record<string, never> ? any : {
+    children?: any;
+} : {});
+/**
+ * One challenge/response row inside a `PromptDisplayGrid`. The challenge lands in the
+ * same column as the prompt titles around it and the response in the answer column.
+ *
+ * - `challenge` prop or slot for the question, default slot for the answer.
+ * - `full` spans the entire grid width instead, for content that needs the whole row
+ *   (documents, notes, notifications).
+ * - `indentLevel` indents the challenge (or full-row content) to suggest hierarchy,
+ *   e.g. follow-up questions under a parent question.
+ */
+declare const PromptDisplayRow: $$__sveltets_2_IsomorphicComponent<$$__sveltets_2_PropsWithChildren<{
+    /** The question being answered. Use the `challenge` slot instead if you need markup. */ challenge?: string | undefined;
+    /** Span the full width of the grid instead of splitting into challenge/response. */ full?: boolean;
+    /**
+       * Indent the challenge (or full-row content) by this multiple of a small indent unit
+       * (1rem per level, tunable with --prompt-display-indent-size). Default 0.
+       */ indentLevel?: number;
+}, {
+    default: {};
+    challenge: {};
+}>, {
+    [evt: string]: CustomEvent<any>;
+}, {
+    default: {};
+    challenge: {};
+}, {}, string>;
+type PromptDisplayRow = InstanceType<typeof PromptDisplayRow>;
+export default PromptDisplayRow;

package/dist/components/index.d.ts

@@ -2,4 +2,6 @@ export { default as CommentCard } from './CommentCard.svelte';
 export { default as FieldCardCheckbox } from './FieldCardCheckbox.svelte';
 export { default as FieldCardRadio } from './FieldCardRadio.svelte';
 export { default as InfoCard } from './InfoCard.svelte';
+export { default as PromptDisplayGrid } from './PromptDisplayGrid.svelte';
+export { default as PromptDisplayRow } from './PromptDisplayRow.svelte';
 export { default as QuestionnairePrompt } from './QuestionnairePrompt.svelte';

package/dist/components/index.js

@@ -2,4 +2,6 @@ export { default as CommentCard } from './CommentCard.svelte';
 export { default as FieldCardCheckbox } from './FieldCardCheckbox.svelte';
 export { default as FieldCardRadio } from './FieldCardRadio.svelte';
 export { default as InfoCard } from './InfoCard.svelte';
+export { default as PromptDisplayGrid } from './PromptDisplayGrid.svelte';
+export { default as PromptDisplayRow } from './PromptDisplayRow.svelte';
 export { default as QuestionnairePrompt } from './QuestionnairePrompt.svelte';

package/dist/registry.d.ts

@@ -86,6 +86,10 @@ export interface PromptDefinition {
      *
      * There is no 'full' mode for displayComponent, since we always want to be able to print the
      * full information dump on a one-pager.
+     *
+     * If your prompt collects several question/answer pairs that should each read as their own
+     * row in the prompt list, set 'large' and build the displayComponent on `PromptDisplayGrid` /
+     * `PromptDisplayRow` — its rows will align with the surrounding prompt rows.
      */
     displayMode?: 'small' | 'large';
     /**

package/dist/typed-client/schema.d.ts

@@ -271,7 +271,7 @@ export type AppRequestPhase = 'ACCEPTANCE' | 'COMPLETE' | 'STARTED' | 'SUBMITTED
  *     the database and the status of each application.
  *
  */
-export type AppRequestStatus = 'ACCEPTANCE' | 'ACCEPTED' | 'APPROVAL' | 'APPROVED' | 'CANCELLED' | 'DISQUALIFIED' | 'NOT_ACCEPTED' | 'NOT_APPROVED' | 'PREAPPROVAL' | 'READY_TO_ACCEPT' | 'READY_TO_SUBMIT' | 'REVIEW_IN_PROGRESS' | 'REVIEW_COMPLETE' | 'STARTED' | 'WITHDRAWN';
+export type AppRequestStatus = 'ACCEPTANCE' | 'ACCEPTED' | 'APPROVAL' | 'APPROVED' | 'CANCELLED' | 'DISQUALIFIED' | 'NOT_ACCEPTED' | 'NOT_APPROVED' | 'PREAPPROVAL' | 'READY_TO_ACCEPT' | 'READY_TO_SUBMIT' | 'REVIEW_COMPLETE' | 'REVIEW_IN_PROGRESS' | 'STARTED' | 'WITHDRAWN';
 /** An application represents the applicant applying to a specific program. Each appRequest has multiple applications - one per program defined in the system. Some applications are mutually exclusive and/or will be eliminated early based on PREQUAL requirements, but they all technically exist in the data model - there is no concept of picking one application over another, just two applications where one dies and the other survives. */
 export interface Application {
     actions: ApplicationActions;
@@ -453,7 +453,7 @@ export interface Mutation {
     acceptOffer: ValidatedAppRequestResponse;
     /** Add a note to the app request. */
     addNote: ValidatedNoteResponse;
-    /** Moves the application to the next workflow stage. If phase is READY_FOR_WORKFLOW, moves to the first or next blocking workflow stage. If on the last blocking workflow, moves to REVIEW_COMPLETE. If on the last non-blocking workflow, moves the application to COMPLETE. If all applications are COMPLETE, automatically triggers the app request close mutation. */
+    /** Moves the application to the next blocking workflow stage. If phase is READY_FOR_WORKFLOW, moves to the first or next blocking workflow stage. If on the last blocking workflow, moves to REVIEW_COMPLETE. In the non-blocking (WORKFLOW_NONBLOCKING) phase the workflow is non-sequential with all non-blocking requirements editable at once and once they are all resolved this becomes a single "Send to Complete" action that moves the application to COMPLETE. */
     advanceWorkflow: ValidatedAppRequestResponse;
     /** Cancel or withdraw the app request, depending on its current phase. This is only available if the app request is in a cancellable state. */
     cancelAppRequest: ValidatedAppRequestResponse;
@@ -480,7 +480,7 @@ export interface Mutation {
     returnToOffer: ValidatedAppRequestResponse;
     /** Return the app request to the review phase from acceptance, non-blocking workflow, or completion. */
     returnToReview: ValidatedAppRequestResponse;
-    /** Moves the application back to the previous workflow stage. If on the first blocking workflow stage, moves back to APPROVAL. If on the first non-blocking workflow, throws an error. */
+    /** Moves the application back to the previous blocking workflow stage. Non-blocking workflow stages are excluded from the reverse order, so this only steps back through the blocking workflow during the review (SUBMITTED) phase.  If no blocking then moved to APPROVAL */
     reverseWorkflow: ValidatedAppRequestResponse;
     roleAddGrant: AccessRoleValidatedResponse;
     roleCreate: AccessRoleValidatedResponse;
@@ -1107,6 +1107,8 @@ export interface AppRequestActivityFilters {
     impersonatedBy?: (Scalars['ID'][] | null);
     /** Return activities that were performed while one of the given logins was being impersonated by someone else. */
     impersonatedUsers?: (Scalars['ID'][] | null);
+    /** Filter activities by matching description content. */
+    search?: (Scalars['String'] | null);
     /** Return activities that were performed by one of the given logins. Also returns activities that were performed while one of the given logins was impersonating someone else. */
     users?: (Scalars['ID'][] | null);
 }
@@ -1421,7 +1423,7 @@ export interface MutationGenqlSelection {
             validateOnly?: (Scalars['Boolean'] | null);
         };
     });
-    /** Moves the application to the next workflow stage. If phase is READY_FOR_WORKFLOW, moves to the first or next blocking workflow stage. If on the last blocking workflow, moves to REVIEW_COMPLETE. If on the last non-blocking workflow, moves the application to COMPLETE. If all applications are COMPLETE, automatically triggers the app request close mutation. */
+    /** Moves the application to the next blocking workflow stage. If phase is READY_FOR_WORKFLOW, moves to the first or next blocking workflow stage. If on the last blocking workflow, moves to REVIEW_COMPLETE. In the non-blocking (WORKFLOW_NONBLOCKING) phase the workflow is non-sequential with all non-blocking requirements editable at once and once they are all resolved this becomes a single "Send to Complete" action that moves the application to COMPLETE. */
     advanceWorkflow?: (ValidatedAppRequestResponseGenqlSelection & {
         __args: {
             applicationId: Scalars['ID'];
@@ -1515,7 +1517,7 @@ export interface MutationGenqlSelection {
             appRequestId: Scalars['ID'];
         };
     });
-    /** Moves the application back to the previous workflow stage. If on the first blocking workflow stage, moves back to APPROVAL. If on the first non-blocking workflow, throws an error. */
+    /** Moves the application back to the previous blocking workflow stage. Non-blocking workflow stages are excluded from the reverse order, so this only steps back through the blocking workflow during the review (SUBMITTED) phase.  If no blocking then moved to APPROVAL */
     reverseWorkflow?: (ValidatedAppRequestResponseGenqlSelection & {
         __args: {
             applicationId: Scalars['ID'];

package/dist/typed-client/schema.graphql

@@ -486,6 +486,9 @@ input AppRequestActivityFilters {
   """
   impersonatedUsers: [ID!]
 
+  """Filter activities by matching description content."""
+  search: String
+
   """
   Return activities that were performed by one of the given logins. Also returns activities that were performed while one of the given logins was impersonating someone else.
   """
@@ -726,6 +729,11 @@ enum AppRequestStatus {
   """
   REVIEW_COMPLETE
 
+  """
+  A reviewer has begun their part on at least one application, some APPROVAL requirement prompt data has been input, but application has not finished review yet.
+  """
+  REVIEW_IN_PROGRESS
+
   """Applicant has begun the process and has not yet submitted."""
   STARTED
 
@@ -847,7 +855,7 @@ enum ApplicationPhase {
   ACCEPTANCE
 
   """
-  The applicant has submitted the application and any PREAPPROVAL requirements are passing. The application is under review.
+  The applicant has submitted the application and any PREAPPROVAL requirements are passing. The application is pending review.
   """
   APPROVAL
 
@@ -892,10 +900,15 @@ enum ApplicationPhase {
   READY_TO_SUBMIT
 
   """
-  The application has been reviewed and any blocking workflow stages have been completed. The application is ready for results (whether eligible or not) to be released to the applicant. A reviewer must manually advanced the phase, and will do so for the whole appRequest, not one application at a time. So the application will sit in this state until all applications are REVIEW_COMPLETE. If there is no acceptance phase (because there are no acceptance requirements), or if the application is not eligible, the makeOffer prompt will move the phase to WORKFLOW_NONBLOCKING or COMPLETE.
+  The application has been reviewed and any blocking workflow stages have been completed. Its results (whether eligible or not) are released to the applicant as soon as it reaches this phase - the eligibility decision no longer waits for the appRequest Complete Review. A reviewer must still manually advance the appRequest phase, so the application will sit in this state until all applications are REVIEW_COMPLETE and the reviewer completes the review. If there is no acceptance phase, or if the application is not eligible, the makeOffer prompt will move the phase to WORKFLOW_NONBLOCKING or COMPLETE.
   """
   REVIEW_COMPLETE
 
+  """
+  The review for this application is currently in progress (some APPROVAL requirement prompt data has been input)
+  """
+  REVIEW_IN_PROGRESS
+
   """
   The application review has been completed and now there is a workflow process to audit the review BEFORE marking the application status as eligible or ineligible. It should remain pending until the blocking workflow stages have been completed. Workflow stages that evaluate to INELIGIBLE will also make the application status INELIGIBLE. Prompts from the applicant and review phases are locked.
   """
@@ -1223,7 +1236,7 @@ type Mutation {
   ): ValidatedNoteResponse!
 
   """
-  Moves the application to the next workflow stage. If phase is READY_FOR_WORKFLOW, moves to the first or next blocking workflow stage. If on the last blocking workflow, moves to REVIEW_COMPLETE. If on the last non-blocking workflow, moves the application to COMPLETE. If all applications are COMPLETE, automatically triggers the app request close mutation.
+  Moves the application to the next blocking workflow stage. If phase is READY_FOR_WORKFLOW, moves to the first or next blocking workflow stage. If on the last blocking workflow, moves to REVIEW_COMPLETE. In the non-blocking (WORKFLOW_NONBLOCKING) phase the workflow is non-sequential with all non-blocking requirements editable at once and once they are all resolved this becomes a single "Send to Complete" action that moves the application to COMPLETE.
   """
   advanceWorkflow(applicationId: ID!): ValidatedAppRequestResponse!
 
@@ -1287,7 +1300,7 @@ type Mutation {
   returnToReview(appRequestId: ID!): ValidatedAppRequestResponse!
 
   """
-  Moves the application back to the previous workflow stage. If on the first blocking workflow stage, moves back to APPROVAL. If on the first non-blocking workflow, throws an error.
+  Moves the application back to the previous blocking workflow stage. Non-blocking workflow stages are excluded from the reverse order, so this only steps back through the blocking workflow during the review (SUBMITTED) phase.  If no blocking then moved to APPROVAL
   """
   reverseWorkflow(applicationId: ID!): ValidatedAppRequestResponse!
   roleAddGrant(grant: AccessRoleGrantCreate!, roleId: ID!, validateOnly: Boolean): AccessRoleValidatedResponse!

package/dist/typed-client/types.d.ts

@@ -230,6 +230,7 @@ declare const _default: {
             impersonated: number[];
             impersonatedBy: number[];
             impersonatedUsers: number[];
+            search: number[];
             users: number[];
             __typename: number[];
         };

package/dist/typed-client/types.js

@@ -600,6 +600,9 @@ export default {
             "impersonatedUsers": [
                 49
             ],
+            "search": [
+                85
+            ],
             "users": [
                 49
             ],

package/package.json

@@ -1,6 +1,9 @@
 {
   "name": "@reqquest/ui",
-  "version": "1.8.1",
+  "version": "1.9.1",
+  "overrides": {
+    "esrap": "2.3.2"
+  },
   "exports": {
     ".": {
       "types": "./dist/index.d.ts",