vueda

Appearance

View Markdown

Action & Workflow Views ​

This page shows the action confirmation views and the history view in the default theme: ViewAction, ViewActivate, ViewDeactivate, ViewExecuteTransition, and ViewHistoryList. CRUD Views shows ViewDestroy, which uses the same confirmation layout. Components describes the rules every component page shares.

Action Contract and Availability describes which actions a view offers and which actions honor a Dry Run. Design Transition UX and Redirects describes what an action form does on pre-flight, submit, and cancel, and where it goes afterward.

Action card ​

Every action view renders its confirmation in ModelActionForm, with the page prop set. The page follows the layout of ViewRead and ViewUpdate:

  • The page title holds the title and a "Go Back" button.
  • The sticky action bar from ActionForm holds the confirm button. The button names the action in sentence case, such as "Archive" or "Submit for approval". The page has no separate cancel button, because "Go Back" leaves the page.
  • The page body, in the page gutter, holds the banner, the selected-records panel, the prompt "Are you sure you want to ...", and any fields the action collects.

The banner is an icon tile, a title, and a one-line description. The title combines the action name and the model's verbose name. The description defaults to "Review the selected records before continuing." The banner is a required part of every action view. It states the action and the records it targets before the user reaches the confirm button, and its tone signals the action's risk.

ModelActionForm without page renders the same parts as a card for use outside a routed page, such as in a dialog. The card has a bordered edge and a tinted banner, and ActionForm's actions strip below the body holds the confirm button and a "Cancel, go back" button.

The tone prop sets that risk level. The form carries the value as data-tone, and the banner icon tile changes with it. On a card, the card edge and the banner fill change too.

toneMeaningDefault forBanner icon
info (default)A neutral confirmationViewAction, ViewExecuteTransitionInformation
successActivate or restoreViewActivateCheck mark
warningAn irreversible change that deletes nothingViewDeactivateWarning triangle
dangerA permanent deletionViewDestroyWarning triangle

At danger, the selected-records panel and its chips also take the destructive tint, and the default confirm button takes the destructive button tone. At every other tone, the confirm button keeps the primary tone.

The selected-records panel is headed "Selected" plus the model's verbose name, with an "N of N selected" count. Each record is a chip that shows the record's Formatted Name as a LinkModelView link. A view can pass the records it fetched as fetchState. Without it, ModelActionForm looks the records up by primary key for display only: the action still targets the primary keys it was given. A chip shows the primary key instead when the record has no formatted name, or when the lookup fails.

Each chip is a FormField named for its record's primary key. Server Feedback keyed by primary key therefore appears beside the matching chip. ActionForm.validation lists, above the card, any error that no rendered field shows.

The card's states:

  • Pre-flight. When the view opens, the card sends the action as a dry run. Its server feedback appears on the form without a toast.
  • Running. While a request runs, both buttons are disabled and show a spinner.
  • Server feedback only. The confirm button stays enabled while only server feedback remains, because the server checks the records again on confirm.
  • Success. A success toast appears, and the buttons stay disabled until the next page replaces the view.
  • Warnings. A Warning Confirmation opens FormConfirmDialog. For an action on several records, the dialog groups the warnings by record, each under the record's link.
  • Failure. Any other failed confirm shows an error toast.

Theme keys: ModelActionForm for the banner, body, and card, and ActionForm for the action bar, the page gutter, and the validation summary. ModelActionForm.card, ModelActionForm.banner, and ModelActionForm.bannerIcon hold the per-tone treatment and switch on page. ActionForm.content sets the page gutter, and ActionForm.stickyButtons lays out the action bar.

ViewAction ​

ViewAction is the generic confirmation that Action View Resolution falls back to for a model action. Its page title is the action name followed by the model's verbose name, and a "Go Back" button sits in the page actions. An action on several records uses the plural verbose name. It passes its pk values to the form, which looks the records up so its chips show their names. It sends the action as PUT unless requestMethod names another method.

An action that takes input puts its fields in the extra-fields slot, below the prompt panel. For the fields to be validated and sent, the view also takes hasInput and transformSubmitDataFn. The demo below is the real view with the slot filled by a docs-only wrapper. Type into Reason and submit, then clear it and submit again to see the error appear under the field.

The pre-flight is a real request, so it can fail. Here the endpoint rejects the pre-flight with a message for two of the three records. The response keys each message by primary key, which is how a server reports records that cannot take the action.

ViewActivate ​

ViewActivate confirms the activate action in the success tone. It fetches the selected records, so each chip shows the record's formatted name as a link. It sends the action as PATCH. The title reads "Activate" followed by the model's verbose name unless you set the title prop. An action on several records uses the plural verbose name.

The server offers the activate action only for a model that inherits ActivatableBaseModel, on a viewset that mixes in DeactivateActionViewSetMixin. VuedaViewSet does not include that mixin. The action sets is_active to true and rejects a record that is already active.

ViewDeactivate shares this body (ViewSelectedObjectsAction) in the warning tone.

ViewDeactivate ​

ViewDeactivate is the default view for every model's deactivate route. It confirms the deactivate action in the warning tone. Like ViewActivate, it fetches the selected records and sends the action as PATCH. The title reads "Deactivate" followed by the model's verbose name unless you set the title prop. An action on several records uses the plural verbose name.

The server offers the deactivate action under the same conditions as activate: a model that inherits ActivatableBaseModel, on a viewset that mixes in DeactivateActionViewSetMixin. The action sets is_active to false and rejects a record that is already inactive. It changes nothing else, so sessions, tokens, and owned records stay as they are unless your server code changes them.

Self-service account page ​

A page that lets a signed-in user deactivate their own account can wrap ViewDeactivate. This example targets the signed-in user and asks them to type their email address. It also replaces the default prompt with account copy:

vue
<script setup>
import { storeUser } from "@vueda/stores/storeUser.js";
import ViewDeactivate from "@vueda/views/ViewDeactivate.vue";

const userStore = storeUser();
</script>

<template>
    <ViewDeactivate
        app="accounts"
        model="user"
        :pk="String(userStore.loggedInUser.id)"
        :confirm-text="userStore.loggedInUser.email"
        banner-title="Deactivate your account"
        action-success-summary="Account deactivated"
    >
        <template #confirm-message>
            <p>Deactivate your account? Type your email address below to confirm.</p>
        </template>
    </ViewDeactivate>
</template>
  • Replace accounts and user with your user model's app label and model name. The viewset that serves your user model must mix in DeactivateActionViewSetMixin.
  • confirmText adds a TypedConfirmField, and the confirm button stays disabled until the typed value matches. The VUEDA user model signs users in by email and requires one, so every account has a value to type.
  • bannerTitle and actionSuccessSummary replace the banner title and the success toast. By default both combine the action and model names.
  • The confirm-message slot replaces the default prompt.

The prompt describes only the action. Describe other effects, such as ending sessions, only when your server performs them.

ViewExecuteTransition ​

ViewExecuteTransition confirms a workflow Transition when the project supplies no view for its code. It renders the same confirmation as ViewAction, in the info tone, so the ViewAction demos above show its layout. Like ViewAction, its chips show the records' names from the form's lookup.

The view differs from ViewAction in its copy and its request:

  • The page title is the transition's name as written, followed by the model's verbose name. Until the workflow metadata loads, the title uses the transition code in title case. The prompt uses the same name in lower case.
  • Both the pre-flight and the confirm execute the transition. Design Transition UX and Redirects describes the request.

The confirmation shows the transition name and the selected records only. A pre-flight rejection shows its message beside the record's chip. To show source and target states or eligibility reasons, supply a project view for the transition code.

Fields in the extra-fields slot render and validate, but their values are not sent with the transition.

Theme keys: ViewExecuteTransition, ModelActionForm, and ActionForm.

ViewHistoryList ​

ViewHistoryList shows the Model History of one record as the actions that produced it. The page title reads "History of" plus the model's verbose name, and a "Back" button sits in the page actions. Each action groups the events it wrote that touch the record, and each event lists its field changes. A meta strip above the grid switches between table and card layouts, and a PaginationFooter follows the grid.

The Model cell names the row that an event wrote. A related row's model name has its object id beside it. A workflow state event reads "Workflow state". Model History Response describes which events the response includes and how they group.

In the table layout, each field change is one row. The first row of an action carries the action's When, Who, Kind, and Action cells. The first row of each event carries its Model and Type cells. An action's first row has data-rev-start, its other rows have data-rev-child, and each event's first row has data-event-start. ViewHistoryList.row draws the action stripe from these attributes, so the grouping survives a reskin.

In the card layout, each event is one card. Its changes stack in the Old and New cells, each value labeled with its field name.

The demo below is the live component against an offline history endpoint. Use the Table and Cards buttons to switch layouts.

A record with no history shows an empty state in place of the meta strip and the grid.

Customization surface ​

ViewAction, ViewActivate, ViewDeactivate, and ViewExecuteTransition pass their attributes and slots through to ModelActionForm, so these props and slots apply to all of them:

The default slot of ViewAction replaces the whole confirmation.

ViewHistoryList takes hideMetaStrip to hide the meta strip. Its slots replace the meta strip, add filter chips to it, replace the empty state, and replace the cells of the When, Who, Kind, Model, Type, Old, and New columns.

Theme keys by area:

Tokens:

  • --info, --success, --warning, and --destructive color the banner and icon tile of their tone. On a card, the success, warning, and danger tones also color the card edge.
  • --primary draws the card prompt panel's rule and the history action stripe.