import { ClsService } from "nestjs-cls";
import { AbstractRepository } from "../../../core/neo4j/abstracts/abstract.repository";
import { Neo4jService } from "../../../core/neo4j/services/neo4j.service";
import { SecurityService } from "../../../core/security/services/security.service";
import { Company } from "../../company";
import { User } from "../../user/entities/user";
import { AuthCode } from "../entities/auth.code";
import { Auth, AuthDescriptor } from "../entities/auth";
/**
 * Auth is deliberately NOT company-scoped (see entities/auth.ts) and every
 * method here is bespoke — JWT signing lives in AuthService, and reads
 * enrich the user with role/company/feature/module permissions via a
 * hand-written Cypher CASE cascade that doesn't map onto the generic
 * descriptor CRUD (create/put/patch/find/findById). None of
 * AbstractRepository's inherited generic methods are used; extending it
 * here is for descriptor typing consistency only.
 *
 * Two methods collide by name with AbstractRepository's generic surface but
 * have incompatible signatures/return types (this repo's `findById` takes
 * `{ authId }` and does permission-enrichment; its `create` takes
 * `{ authId, userId, token, expiration }` and returns the created Auth) —
 * both were renamed (`findAuthById`, `createSession`) to resolve the
 * TS2416 override collision. AuthRepository has no external callers other
 * than AuthService, so these are internal-only renames.
 */
export declare class AuthRepository extends AbstractRepository<Auth, typeof AuthDescriptor.relationships> {
    protected readonly descriptor: import("../../..").EntityDescriptor<Auth, {
        user: {
            model: import("../../../common/interfaces/datamodel.interface").DataMeta;
            direction: "in";
            relationship: string;
            cardinality: "one";
            description: string;
        };
    }>;
    constructor(neo4j: Neo4jService, securityService: SecurityService, clsService: ClsService);
    /**
     * Models are resolved from the registry rather than referenced statically so
     * that an application which registers an extended model (extra
     * childrenTokens, extra relationships) is served ITS model here — mirrors
     * ContentRepository.getContentModel().
     */
    private getAuthModel;
    private getAuthCodeModel;
    private getUserModel;
    /**
     * Bespoke constraint set: the inherited AbstractRepository.onModuleInit would
     * also derive a FULLTEXT index over the descriptor's string fields — which
     * here are the live session token and the company-selection token. Neither
     * has any business being searchable text.
     */
    onModuleInit(): Promise<void>;
    setLastLogin(params: {
        userId: string;
    }): Promise<void>;
    findByCode(params: {
        code: string;
    }): Promise<AuthCode>;
    findAuthById(params: {
        authId: string;
    }): Promise<Auth>;
    deleteByCode(params: {
        code: string;
    }): Promise<void>;
    deleteByToken(params: {
        token: string;
    }): Promise<void>;
    createCode(params: {
        authCodeId: string;
        authId: string;
        expiration: Date;
    }): Promise<void>;
    refreshToken(params: {
        authId: string;
        token: string;
    }): Promise<Auth>;
    findByRefreshToken(params: {
        authId: string;
    }): Promise<Auth>;
    findValidToken(params: {
        userId: string;
    }): Promise<Auth>;
    /**
     * Reads the user together with the roles effective in a single company.
     *
     * `companyId` scopes BOTH the company hydration and the membership role read to
     * one explicit company (login/company-switch/refresh); platform memberships (no
     * IN_COMPANY edge) always resolve regardless. When omitted, `$companyId` keeps
     * the CLS value injected by `initQuery()` — identical to the previous behaviour.
     */
    findUserById(params: {
        userId: string;
        companyId?: string;
    }): Promise<User>;
    countUserCompanies(params: {
        userId: string;
    }): Promise<number>;
    /**
     * The companies the user belongs to — the list rendered by the company-selection
     * screen and the company switcher.
     */
    findUserCompanies(params: {
        userId: string;
    }): Promise<Company[]>;
    /**
     * `companyId` pins the session being created to one company: the roles baked
     * into the JWT (signed by AuthService from the same user object) and the roles
     * hydrated onto the returned Auth payload must describe the SAME company, or a
     * user who belongs to more than one company would get a session whose company
     * and roles disagree.
     */
    createSession(params: {
        authId: string;
        userId: string;
        token: string;
        expiration: Date;
        companyId?: string;
    }): Promise<Auth>;
    findByToken(params: {
        token: string;
    }): Promise<Auth>;
    deleteById(params: {
        authId: string;
    }): Promise<void>;
    startResetPassword(params: {
        userId: string;
    }): Promise<User>;
    resetPassword(params: {
        userId: string;
        password: string;
    }): Promise<void>;
    acceptInvitation(params: {
        userId: string;
        password: string;
    }): Promise<void>;
    activateAccount(params: {
        userId: string;
    }): Promise<void>;
    deleteExpiredAuths(params: {
        userId: string;
    }): Promise<void>;
}
//# sourceMappingURL=auth.repository.d.ts.map