/**
 * Agilicus API
 * Agilicus is API-first. Modern software is controlled by other software, is open, is available for you to use the way you want, securely, simply.  The OpenAPI Specification in YAML format is available on [www](https://www.agilicus.com/www/api/agilicus-openapi.yaml) for importing to other tools.  A rendered, online viewable and usable version of this specification is available at [api](https://www.agilicus.com/api). You may try the API inline directly in the web page. To do so, first obtain an Authentication Token (the simplest way is to install the Python SDK, and then run `agilicus-cli --issuer https://MYISSUER get-token`). You will need an org-id for most calls (and can obtain from `agilicus-cli --issuer https://MYISSUER list-orgs`). The `MYISSUER` will typically be `auth.MYDOMAIN`, and you will see it as you sign-in to the administrative UI.  This API releases on Bearer-Token authentication. To obtain a valid bearer token you will need to Authenticate to an Issuer with OpenID Connect (a superset of OAUTH2).  Your \"issuer\" will look like https://auth.MYDOMAIN. For example, when you signed-up, if you said \"use my own domain name\" and assigned a CNAME of cloud.example.com, then your issuer would be https://auth.cloud.example.com.  If you selected \"use an Agilicus supplied domain name\", your issuer would look like https://auth.myorg.agilicus.cloud.  For test purposes you can use our [Python SDK](https://pypi.org/project/agilicus/) and run `agilicus-cli --issuer https://auth.MYDOMAIN get-token`.  This API may be used in any language runtime that supports OpenAPI 3.0, or, you may use our [Python SDK](https://pypi.org/project/agilicus/), our [Typescript SDK](https://www.npmjs.com/package/@agilicus/angular), or our [Golang SDK](https://git.agilicus.com/pub/sdk-go).  100% of the activities in our system our API-driven, from our web-admin, through our progressive web applications, to all internals: there is nothing that is not accessible.  For more information, see [developer resources](https://www.agilicus.com/developer).
 *
 * The version of the OpenAPI document: 2025.12.16
 * Contact: dev@agilicus.com
 *
 * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
 * https://openapi-generator.tech
 * Do not edit the class manually.
 */
import { RuleCondition } from './ruleCondition';
import { RuleAction } from './ruleAction';
import { RuleScopeEnum } from './ruleScopeEnum';
import { HttpRule } from './httpRule';
export interface _RuleConfig {
    /**
     * The name of the rule.
     */
    name: string;
    /**
     * The list of roles assigned to this rule.
     */
    roles?: Array<string>;
    /**
     * The list of roles excluded from this rule.
     */
    excluded_roles?: Array<string>;
    /**
     * A description of the rule. The comments have no functional effect, but can help to clarify the purpose of a rule when the name is not sufficient.
     */
    comments?: string;
    condition?: HttpRule;
    scope?: RuleScopeEnum;
    extended_condition?: RuleCondition;
    /**
     * The priority of the rule relative to other rules at the top level: that is, if this rule is not being evaluated as part of a RuleSet, it is assumed to be within a \'global\' RuleSet that contains all \'root\' rules. In that case, this priority applies.  Rules are evaluated in order of higher priority number to lower priority number.
     */
    priority?: number;
    /**
     * The actions to take if the rule evaluates to true. At least one of allow or deny must be present in the action list for the system to effectively operate on the request. By default, if neither allow nor deny is present in the list of actions resulting from the rule, the request will be allowed. Some actions may conflict.  If there is a conflict, the first action in the preorder depth-first-search traversal of the rule tree will take precedence. For example, deny and allow are conflicting actions. If the parent rule has deny, and a sub_rule has allow, then the request will be denied. Or, if the parent rule has none, the first sub-rule has allow, and the second sub-rule has deny, the request will be allowed.
     */
    actions?: Array<RuleAction>;
}
export interface RuleConfig extends _RuleConfig {
    _builtin_original?: _RuleConfig;
    _remove_builtin_extensions?: () => void;
}
export declare class RuleConfigImpl implements _RuleConfig {
    _builtin_original?: _RuleConfig;
    name: string;
    roles: Array<string> | undefined;
    excluded_roles: Array<string> | undefined;
    comments: string | undefined;
    condition: HttpRule | undefined;
    scope: RuleScopeEnum | undefined;
    extended_condition: RuleCondition | undefined;
    priority: number | undefined;
    actions: Array<RuleAction> | undefined;
    constructor(base: _RuleConfig);
    _remove_builtin_extensions(): void;
}
export declare function newRuleConfigImpl(base: _RuleConfig): RuleConfigImpl;