@things-factory/auth-ui 10.1.4 → 10.1.7

package/dist-client/components/user-detail.d.ts

@@ -0,0 +1,151 @@
+import '@material/web/icon/icon.js';
+import '@material/web/button/elevated-button.js';
+import '@material/web/button/outlined-button.js';
+import '@material/web/checkbox/checkbox.js';
+import './ownership-transfer-popup.js';
+import { LitElement } from 'lit';
+import type { CSSResultGroup } from 'lit';
+declare const UserDetail_base: (new (...args: any[]) => LitElement) & typeof LitElement;
+/**
+ * 한 사람의 역할을 고치는 자리.
+ *
+ * ── 담는 그릇을 모른다 ──────────────────────────────────────────────────────
+ * 팝업이든 서랍이든 그 안에 들어간다. 그래서 여기서는 **아무것도 열거나 닫지 않고** 두 가지만
+ * 알린다 — 저장이 끝났다(`user-updated`), 닫아 달라(`close`). 그릇이 어느 것이 될지는 아직
+ * 정해지지 않았고, 그 결정이 이 파일을 바꾸지 않게 한다.
+ *
+ * ── 옛 화면이 하던 것 (`components/user-role-editor.ts`) ────────────────────
+ * 저장할 때 `querySelectorAll('role-selector')` 로 **화면을 훑어** 「가능한 역할 전부」와
+ * 「고른 역할」을 만들어 보냈다.
+ *
+ * `updateUserRoles` 의 계약은 이렇다 — `availableRoles` 는 **부르는 쪽이 책임지는 범위**이고,
+ * 그 범위 안의 역할을 일단 다 뗀 다음 `selectedRoles` 를 다시 붙인다. 범위 밖의 역할은
+ * 건드리지 않는다(`user-mutation.ts` 의 `updateUserRoles`).
+ *
+ * 계약 자체는 옳다 — 화면이 일부만 편집할 수 있게 해 준다. 잘못된 것은 **그 범위를 DOM 에서
+ * 만든 것**이다. 목록이 늦게 오거나 잘려 있으면 화면은 그것을 모른 채 좁은 범위를 보내고,
+ * 안 보낸 역할이 어떻게 되는지가 그날의 렌더링에 달린다.
+ *
+ * 여기서는 범위를 **상태에서** 만든다. 읽어 온 목록이 곧 범위이고, 아직 못 읽었으면 저장하지
+ * 않는다.
+ */
+export declare class UserDetail extends UserDetail_base {
+    static styles: CSSResultGroup;
+    /** 목록이 골라 준 사람. `id` 와 `username`(없으면 `email`)이 있어야 한다. */
+    user: any;
+    private availableRoles;
+    private selected;
+    private loading;
+    private saving;
+    private canManage;
+    private canOwn;
+    private myEmail;
+    /** 기본 비밀번호가 설정돼 있지 않으면 초기화는 서버에서 던진다 — 단추를 내주지 않는다. */
+    private defaultPasswordConfigured;
+    /**
+     * 이 도메인(과 부모)의 역할 id.
+     *
+     * 소유권 이전은 **받는 사람이 이 도메인에 역할을 하나라도 가질 때만** 된다
+     * (`transferOwner` 가 상속 역할까지 자격으로 인정하고, 그 밖은 던진다). 파트너십으로 넘어온
+     * 역할은 자격이 아니므로 `availableRoles`(합친 것)로는 판정할 수 없다.
+     */
+    private domainRoleIds;
+    private unsubscribe?;
+    private get savable();
+    render(): import("lit-html").TemplateResult<1>;
+    /**
+     * 되돌릴 수 없는 조치.
+     *
+     * ── 왜 아래에 따로 두나 ─────────────────────────────────────────────────────
+     * 옛 화면은 저장·소유권 이전·초기화·제외·비활성화를 **한 줄에 나란히** 뒀다. 매일 누르는
+     * 「저장」 옆에 한 번 누르면 끝인 「제외」가 같은 크기로 있었다.
+     *
+     * 그래서 선을 하나 긋고, 위는 채운 단추(주 동작), 아래는 테두리 단추로 둔다. 색은
+     * error 짝으로 글자에만 쓴다 — 면을 다 칠하면 「지금 문제가 있다」로 읽힌다.
+     *
+     * ── 무엇을 언제 내주나 ──────────────────────────────────────────────────────
+     * 조건은 전부 **서버가 실제로 던지는 것**을 그대로 옮긴 것이다. 눌리는 단추를 보여 주고
+     * 서버가 거절하면 그것은 안내가 아니라 오류다.
+     *
+     *   비밀번호 초기화  기본 비밀번호가 설정돼 있고, 내가 아니다
+     *   소유권 이전      활성 상태고, 소유자가 아니고, 이 도메인에 역할이 하나라도 있다
+     *   도메인에서 제외  소유자가 아니고, 내가 아니다
+     *
+     * ── 이름 ────────────────────────────────────────────────────────────────────
+     * `deleteDomainUser` 는 계정을 지우지 않는다 — **이 도메인에서만 뗀다**(서버 설명도 그렇게
+     * 적혀 있다). 옛 화면의 「사용자 삭제」는 하지 않는 일을 말하고 있었다.
+     */
+    private renderDangerZone;
+    /**
+     * 계정 상태와, 그것을 되돌리는 단추.
+     *
+     * **잠금 해제와 활성화는 서버에서 같은 것이다** — `activateUser` 가 `failCount` 를 0 으로
+     * 두고 `ACTIVATED` 로 되돌린다. 그래서 부르는 것은 하나이고, **글자만 상황에 맞춰 바꾼다.**
+     * 잠긴 사람에게 「활성화」라고 하면 무슨 일이 일어나는지 알 수 없다.
+     *
+     * 비활성화는 소유자와 나 자신에게는 내주지 않는다. 서버도 같은 것을 막지만
+     * (`inactivateUser` 가 소유자·admin 을 거절한다), **화면이 눌리는 단추를 보여 주고 서버가
+     * 거절하면 그것은 안내가 아니라 오류다.**
+     */
+    private renderAccountState;
+    private renderRoles;
+    connectedCallback(): void;
+    disconnectedCallback(): void;
+    private applyMe;
+    /**
+     * 서버 지시자에 적힌 인자를 그대로 되묻는다.
+     *
+     * 기본 비밀번호 여부도 여기서 함께 읽는다. 서버에 같은 답을 주는 질의가 둘 있는데
+     * (`checkDefaultPassword` 와 `checkResettablePasswordToDefault` — 둘 다
+     * `Boolean(defaultPassword)`), 하나만 쓴다.
+     */
+    private checkGates;
+    updated(changes: Map<string, unknown>): void;
+    /**
+     * 부여할 수 있는 역할을 읽는다.
+     *
+     * **이 사람이 지금 가진 역할은 다시 묻지 않는다** — 목록이 이미 실어 왔다(`user.roles`).
+     * 옛 화면은 email 로 사용자를 다시 찾았는데, 역할 이름과 달리 email 은 유일하긴 해도
+     * 손에 든 `id` 를 두고 다른 열쇠로 같은 사람을 찾는 것이었다. 안 물으면 그 문제가 없다.
+     *
+     * **이 도메인의 역할과 파트너십으로 넘어온 역할을 한 목록으로 합친다.** 옛 화면은 그 둘을
+     * 따로 그리고 저장할 때 화면에서 다시 모았는데, 합치는 자리가 화면이면 화면이 못 그린 것은
+     * 저장에서도 빠진다.
+     */
+    private fetch;
+    /** 잠금 해제와 활성화가 같은 부름이다 — 서버가 `failCount` 도 0 으로 되돌린다. */
+    private onActivate;
+    private onInactivate;
+    /**
+     * 비밀번호를 기본값으로 되돌린다.
+     *
+     * **무엇이 되는지 사람이 알 수 있게 말한다.** 「초기화하시겠습니까」는 그 뒤에 무엇을 알려
+     * 줘야 하는지를 안 말한다 — 초기화된 비밀번호는 관리자가 상대에게 따로 전해야 한다(서버가
+     * 메일을 보내지 않는다).
+     */
+    private onResetPassword;
+    /**
+     * 이 도메인에서만 뗀다 — 계정은 남는다.
+     *
+     * 그래서 확인 문구도 「지웁니다」가 아니다. 이 사람은 다른 도메인에서 계속 일할 수 있고,
+     * 다시 부르면 된다.
+     */
+    private onRemoveFromDomain;
+    /**
+     * 소유권을 넘긴다.
+     *
+     * 이미 있는 `ownership-transfer-popup` 을 그대로 쓴다 — 그 안에 **이메일을 다시 적게 하는**
+     * 확인이 들어 있다. 되돌릴 수 없는 것 중에서 유일하게 두 단계인 것이고, 그 판단이 맞다.
+     */
+    private onTransfer;
+    private runUserMutation;
+    private onToggle;
+    /**
+     * **범위를 상태에서 만든다.** 읽어 온 목록이 곧 `availableRoles` 다.
+     *
+     * 빈 범위를 보내면 서버는 「뗄 것이 없다」로 읽어 아무것도 안 한다 — 우연히 무해한 것이지
+     * 뜻한 바가 아니므로, 그 경우는 여기까지 오지 않는다(`savable`).
+     */
+    private onSave;
+}
+export {};