import { AmountComparator, AmountCriteria, ApprovalUpdateActionType, BillPayApprovalRuleWithUser, BillPaySetupApproverUpdateDataView, ID } from '@zeniai/client-epic-state';
import { ResponsiveSized } from '../../../../context/windowSizeProvider';
import { ApprovalStageData } from '../../../commonSetUp/approval/ApprovalStageRow';
import { IsOrIsNotOperator } from '../../../commonSetUp/approval/OperatorIsOrIsNotPicker';
declare const name = "name";
declare const description = "description";
declare const amountCriteria = "amountCriteria";
declare const vendorCriteria = "vendorCriteria";
declare const departmentCriteria = "departmentCriteria";
declare const steps = "steps";
declare const separationOfDuties = "separationOfDuties";
declare const isFallback = "isFallback";
declare const applyToExistingBills = "applyToExistingBills";
/**
 * Form-side shape for vendor / department conditions.
 *
 * The widget primitive (`LabeledMultiSelectField`) stores its value as
 * `{allOptions, selectedOptions}`, which doesn't match the wire shape
 * `{type, operator, vendorIds | departmentIds}`. The form stores the
 * widget-native shape under each slot and the screen connector
 * translates to the canonical `VendorCriteria` / `DepartmentCriteria`
 * at save time.
 *
 * The `operator` slot is driven by `SingleSelectField`, which writes
 * the wrapped `{allOptions, selectedOption}` shape to form state, so
 * we declare it inline as `{allOptions, selectedOption}` here.
 * `getDefaultValues` seeds the wrapped shape too, so the runtime
 * always matches the type. Readers do `value.operator.selectedOption`.
 */
export interface MultiSelectFormValue {
    allOptions: string[];
    selectedOptions: string[];
}
export interface VendorConditionFormValue {
    operator: {
        allOptions: IsOrIsNotOperator[];
        selectedOption?: IsOrIsNotOperator;
    };
    selection: MultiSelectFormValue;
}
export interface DepartmentConditionFormValue {
    operator: {
        allOptions: IsOrIsNotOperator[];
        selectedOption?: IsOrIsNotOperator;
    };
    selection: MultiSelectFormValue;
}
/**
 * Form-side amount shape. Same reason as vendor/department: the
 * comparator slot is `SingleSelectField`-driven, so its runtime shape
 * is the wrapper. The min/max remain canonical `Amount` because they
 * are driven by `TextField` which writes bare values.
 */
export interface AmountConditionFormValue {
    comparator: {
        allOptions: AmountComparator[];
        selectedOption?: AmountComparator;
    };
    type: "amount";
    max?: AmountCriteria["max"];
    min?: AmountCriteria["min"];
}
/**
 * Full Approval Rules 3.0 form data shape.
 *
 * Each top-level slot corresponds to one section of the form. Bindings
 * land incrementally — the slots are declared up front so the contract is
 * stable across tasks:
 *   - amountCriteria — task #8
 *   - vendorCriteria / departmentCriteria — tasks #9–#10 (this change)
 *   - separationOfDuties — task #14
 *   - isFallback — task #15
 */
export interface FormData {
    [applyToExistingBills]: string[];
    [steps]: ApprovalStageData[];
    [amountCriteria]?: AmountConditionFormValue;
    [departmentCriteria]?: DepartmentConditionFormValue;
    [description]?: string;
    [isFallback]?: boolean;
    [name]?: string;
    [separationOfDuties]?: boolean;
    [vendorCriteria]?: VendorConditionFormValue;
}
export interface BillPayApprovalRuleDetailPageProps {
    /**
     * User-resolved approval rules used by the overlap warning surface
     * (RuleOverlapBanner). Threaded separately from `localData` because
     * the update-data view exposes only the raw `ApprovalRule[]` (no
     * resolved user actors on the steps), and the banner's per-rule
     * card renders resolved actor names in its 'Then:' section.
     */
    allApprovalRulesWithUser: BillPayApprovalRuleWithUser[];
    /**
     * Vendor list available to the rule. Threaded from `state.contactState`
     * by the screen connector. Empty when the contact slice hasn't loaded
     * yet — the multi-select renders no options in that case.
     */
    allVendorIds: string[];
    approvalUpdateActionType: ApprovalUpdateActionType;
    localData: BillPaySetupApproverUpdateDataView;
    vendorNamesById: Record<string, string>;
    /**
     * When editing an existing rule, the rule being edited. Used to
     * exclude it from the overlap check (a rule should not flag itself
     * as conflicting). Undefined for create flows.
     */
    editingRuleId?: ID;
    onApprovalRuleDataUpdated: (formData: FormData) => void;
    onBackClick: () => void;
    /**
     * Approval Rules 3.0 — invoked from RuleOverlapBanner when the user
     * clicks Edit on one of the conflicting rules. The screen connector
     * wires this to a same-tab navigation to that rule's detail page.
     */
    onEditExistingRule: (ruleId: string) => void;
    onResetClick: () => void;
    onSaveRuleClick: () => void;
    onSaveRuleSuccess: () => void;
}
/**
 * Dimensions
 */
export declare const D: {
    footerPadding: ResponsiveSized;
};
declare function BillPayApprovalRuleDetailPage({ localData, approvalUpdateActionType, allApprovalRulesWithUser, allVendorIds, editingRuleId, vendorNamesById, onBackClick, onApprovalRuleDataUpdated, onEditExistingRule, onResetClick, onSaveRuleClick, onSaveRuleSuccess, }: BillPayApprovalRuleDetailPageProps): import("react/jsx-runtime").JSX.Element;
export default BillPayApprovalRuleDetailPage;
export declare const uniqueFormName: (sectionId: ID) => `${string}_form`;
type FormDataKeys = keyof FormData;
export declare const uniqueName: (key: FormDataKeys) => "description" | "name" | "steps" | "isFallback" | "separationOfDuties" | "amountCriteria" | "departmentCriteria" | "vendorCriteria" | "applyToExistingBills";
export type FormDataKeyUniqueNames = ReturnType<typeof uniqueName>;
