import { Ability } from '@casl/ability';
import type { WidgetDefinition, WidgetPermissions } from './types';
type Actions = 'view' | 'create' | 'delete';
type Subjects = 'Widget' | 'Dashboard' | 'all';
export type DashboardAbility = Ability<[Actions, Subjects]>;
export declare function createDashboardAbility(userRoles: string[]): DashboardAbility;
/**
 * @deprecated Solo como respaldo de `resolveWidgetPermissions` para hosts cuyo backend no evalua
 * acceso por instancia. **No llamarla directamente para decidir si un widget se ve**: cruza roles
 * con `Array.includes`, o sea un OR, y por tanto puede *ensanchar* lo que el servidor ya restringio
 * por ACL. Se conserva exportada porque es API publica del kit desde el primer release.
 */
export declare function canUserViewWidget(userRoles: string[], widgetRoles: string[]): boolean;
/** Lo que el widget del catalogo necesita traer para resolver sus verbos. */
type WidgetAccessShape = Pick<WidgetDefinition, 'permissions' | 'roles_permitidos' | 'propietario_id'>;
/** El contexto del usuario, que **solo** se usa cuando el servidor no dijo nada. */
export interface WidgetPermissionsFallback {
    userRoles: string[];
    /** Si el usuario administra el catalogo. En el kit venia de `userRoles.includes('admin')`. */
    isAdmin: boolean;
}
/**
 * Los cuatro verbos del usuario sobre un widget, **con el servidor primero**.
 *
 * ## Por que existe
 *
 * El kit tenia dos criterios de acceso corriendo a la vez: el backend filtraba el catalogo por su
 * regla de instancia (ACL ∩ RBAC) y el kit lo volvia a filtrar por su cuenta con
 * `canUserViewWidget(userRoles, roles_permitidos)`. Ese segundo filtro es un OR de roles, asi que
 * podia hacer dos cosas, las dos malas:
 *
 * - **Esconder** un widget que el servidor si concedio — el caso de compartir una instancia con una
 *   persona que no tiene el modulo del widget: el backend lo manda en el catalogo, el kit lo tira
 *   por no cruzar roles, y la persona con quien se compartio no lo ve nunca. Sin error ni log.
 * - **Mostrar** acciones que el servidor va a rechazar, porque `isAdmin` era global: el boton de
 *   borrar aparecia para todo widget con dueño, sin importar la ACL de esa fila.
 *
 * ## La regla
 *
 * Si el widget trae `permissions`, se usan **tal cual y sin mezclar**: son la decision del servidor,
 * que ya compuso capacidad (RBAC) ∩ grant de instancia (ACL). Ni se amplian con `isAdmin` ni se
 * recortan con los roles — cualquiera de las dos cosas reintroduce el segundo criterio.
 *
 * Si no los trae, se cae al comportamiento historico. Eso es lo que mantiene funcionando a un host
 * con backend viejo, y es deliberado que el respaldo sea *identico* a lo de antes y no algo mas
 * seguro: cerrar por defecto aqui vaciaria el catalogo de esos hosts en una subida de version de
 * parche.
 */
export declare function resolveWidgetPermissions(widget: WidgetAccessShape, fallback: WidgetPermissionsFallback): WidgetPermissions;
export {};
//# sourceMappingURL=ability.d.ts.map