Initial wireframe planning
This commit is contained in:
david committed
commit
7ac52911fd
82 files changed
+8105
No files matched your search
@@ -0,0 +1,2 @@
|
||||
# Referenz-Codebase nicht in das Wireframe-Repo pushen.
|
||||
hivegrid-cloud/
|
||||
Vendored
+1
@@ -0,0 +1 @@
|
||||
{}
|
||||
Vendored
+3
@@ -0,0 +1,3 @@
|
||||
{
|
||||
"cssTheme": "Obsidian gruvbox"
|
||||
}
|
||||
Vendored
+3
@@ -0,0 +1,3 @@
|
||||
[
|
||||
"editor-width-slider"
|
||||
]
|
||||
Vendored
+33
@@ -0,0 +1,33 @@
|
||||
{
|
||||
"file-explorer": true,
|
||||
"global-search": true,
|
||||
"switcher": true,
|
||||
"graph": true,
|
||||
"backlink": true,
|
||||
"canvas": true,
|
||||
"outgoing-link": true,
|
||||
"tag-pane": true,
|
||||
"footnotes": false,
|
||||
"properties": true,
|
||||
"page-preview": true,
|
||||
"daily-notes": true,
|
||||
"templates": true,
|
||||
"note-composer": true,
|
||||
"command-palette": true,
|
||||
"slash-command": false,
|
||||
"editor-status": true,
|
||||
"bookmarks": true,
|
||||
"markdown-importer": false,
|
||||
"zk-prefixer": false,
|
||||
"random-note": false,
|
||||
"outline": true,
|
||||
"word-count": true,
|
||||
"slides": false,
|
||||
"audio-recorder": false,
|
||||
"workspaces": false,
|
||||
"file-recovery": true,
|
||||
"publish": false,
|
||||
"sync": true,
|
||||
"bases": true,
|
||||
"webviewer": false
|
||||
}
|
||||
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"sliderPercentage": "100",
|
||||
"sliderPercentageDefault": "20",
|
||||
"sliderWidth": "150"
|
||||
}
|
||||
+258
@@ -0,0 +1,258 @@
|
||||
/*
|
||||
THIS IS A GENERATED/BUNDLED FILE BY ESBUILD
|
||||
if you want to view the source, please visit the github repository of this plugin
|
||||
*/
|
||||
|
||||
var __defProp = Object.defineProperty;
|
||||
var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
|
||||
var __getOwnPropNames = Object.getOwnPropertyNames;
|
||||
var __hasOwnProp = Object.prototype.hasOwnProperty;
|
||||
var __export = (target, all) => {
|
||||
for (var name in all)
|
||||
__defProp(target, name, { get: all[name], enumerable: true });
|
||||
};
|
||||
var __copyProps = (to, from, except, desc) => {
|
||||
if (from && typeof from === "object" || typeof from === "function") {
|
||||
for (let key of __getOwnPropNames(from))
|
||||
if (!__hasOwnProp.call(to, key) && key !== except)
|
||||
__defProp(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable });
|
||||
}
|
||||
return to;
|
||||
};
|
||||
var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
|
||||
|
||||
// src/main.ts
|
||||
var main_exports = {};
|
||||
__export(main_exports, {
|
||||
default: () => EditorWidthSlider
|
||||
});
|
||||
module.exports = __toCommonJS(main_exports);
|
||||
var import_obsidian3 = require("obsidian");
|
||||
|
||||
// src/settings/settings.ts
|
||||
var import_obsidian = require("obsidian");
|
||||
var DEFAULT_SETTINGS = {
|
||||
sliderPercentage: "20",
|
||||
sliderPercentageDefault: "20",
|
||||
sliderWidth: "150"
|
||||
};
|
||||
var EditorWidthSliderSettingTab = class extends import_obsidian.PluginSettingTab {
|
||||
constructor(app2, plugin) {
|
||||
super(app2, plugin);
|
||||
this.plugin = plugin;
|
||||
}
|
||||
// this.settings.sliderWidth
|
||||
display() {
|
||||
const { containerEl } = this;
|
||||
containerEl.empty();
|
||||
new import_obsidian.Setting(containerEl).setName("Slider Width").setDesc("How wide do you want your slider to be?").addText((text) => text.setPlaceholder("Slider width in px").setValue(this.plugin.settings.sliderWidth).onChange(async (value) => {
|
||||
this.plugin.settings.sliderWidth = value;
|
||||
this.plugin.updateSliderStyle();
|
||||
await this.plugin.saveSettings();
|
||||
}));
|
||||
new import_obsidian.Setting(containerEl).setName("Slider Default Percentage").setDesc("What do you want the default percentage of the slider to be?").addText((text) => text.setPlaceholder("Slider width in px").setValue(this.plugin.settings.sliderPercentageDefault).onChange(async (value) => {
|
||||
this.plugin.settings.sliderPercentageDefault = value;
|
||||
this.plugin.updateSliderStyle();
|
||||
await this.plugin.saveSettings();
|
||||
}));
|
||||
new import_obsidian.Setting(containerEl).setName("Note:").setDesc(`The field should be named "editor-width" in the YAML frontmatter of the note in order to customize the editor width of that repective note. It won't work globally for all notes unless you specify it in each note's frontmatter.`);
|
||||
}
|
||||
};
|
||||
|
||||
// src/modal/warning.ts
|
||||
var import_obsidian2 = require("obsidian");
|
||||
var WarningModal = class extends import_obsidian2.Modal {
|
||||
constructor(app2) {
|
||||
super(app2);
|
||||
}
|
||||
onOpen() {
|
||||
const { contentEl } = this;
|
||||
contentEl.setText("Editor width must be a number from 0 to 100!");
|
||||
}
|
||||
onClose() {
|
||||
const { contentEl } = this;
|
||||
contentEl.empty();
|
||||
}
|
||||
};
|
||||
|
||||
// src/main.ts
|
||||
var EditorWidthSlider = class extends import_obsidian3.Plugin {
|
||||
constructor() {
|
||||
super(...arguments);
|
||||
this.pattern = /^(?:[0-9]{1,2}|100)$/;
|
||||
}
|
||||
// most important function, this gets executed everytime the plugin is first
|
||||
// loaded, e.g. when obsidian starts, or when the user just installed the
|
||||
// plugin
|
||||
async onload() {
|
||||
await this.loadSettings();
|
||||
this.addStyle();
|
||||
this.app.workspace.on("file-open", () => {
|
||||
this.updateEditorStyleYAML();
|
||||
});
|
||||
this.createSlider();
|
||||
this.addSettingTab(new EditorWidthSliderSettingTab(this.app, this));
|
||||
}
|
||||
// async onLoadFile(file: TFile) {
|
||||
// }
|
||||
onunload() {
|
||||
this.cleanUpResources();
|
||||
}
|
||||
// ---------------------------- SLIDER -------------------------------------
|
||||
createSlider() {
|
||||
const slider = document.createElement("input");
|
||||
slider.classList.add("editor-width-slider");
|
||||
slider.id = "editor-width-slider";
|
||||
slider.type = "range";
|
||||
slider.min = "0";
|
||||
slider.max = "100";
|
||||
slider.value = this.settings.sliderPercentage;
|
||||
slider.style.width = this.settings.sliderWidth + "px";
|
||||
slider.addEventListener("input", (event) => {
|
||||
const value = parseInt(slider.value);
|
||||
this.settings.sliderPercentage = value.toString();
|
||||
this.saveSettings();
|
||||
this.updateEditorStyle();
|
||||
sliderValueText.textContent = value.toString();
|
||||
console.log("Slider value:", value);
|
||||
});
|
||||
const sliderValueText = document.createElement("span");
|
||||
sliderValueText.textContent = slider.value;
|
||||
sliderValueText.classList.add("editor-width-slider-value");
|
||||
sliderValueText.id = "editor-width-slider-value";
|
||||
sliderValueText.style.color = "white";
|
||||
sliderValueText.style.padding = "8px 5px";
|
||||
sliderValueText.style.display = "inline";
|
||||
sliderValueText.style.borderRadius = "18%";
|
||||
sliderValueText.style.border = "0";
|
||||
sliderValueText.style.margin = "0px 10px";
|
||||
sliderValueText.style.background = "var(--interactive-accent)";
|
||||
sliderValueText.style.fontSize = "13px";
|
||||
sliderValueText.style.lineHeight = "50%";
|
||||
sliderValueText.style.width = "auto";
|
||||
sliderValueText.style.height = "auto";
|
||||
sliderValueText.style.boxSizing = "content-box";
|
||||
sliderValueText.style.transition = "background 0.3s";
|
||||
sliderValueText.style.cursor = "pointer";
|
||||
sliderValueText.addEventListener("mouseenter", function() {
|
||||
sliderValueText.style.background = "red";
|
||||
});
|
||||
sliderValueText.addEventListener("mouseleave", function() {
|
||||
sliderValueText.style.background = "var(--interactive-accent)";
|
||||
});
|
||||
sliderValueText.addEventListener("click", () => {
|
||||
console.log("test");
|
||||
this.resetEditorWidth();
|
||||
});
|
||||
const statusBarItemEl = this.addStatusBarItem();
|
||||
statusBarItemEl.appendChild(slider);
|
||||
statusBarItemEl.appendChild(sliderValueText);
|
||||
}
|
||||
// ---------------------------- SLIDER -------------------------------------
|
||||
cleanUpResources() {
|
||||
this.resetEditorWidth();
|
||||
}
|
||||
resetEditorWidth() {
|
||||
this.settings.sliderPercentage = this.settings.sliderPercentageDefault;
|
||||
const styleElements = document.getElementsByClassName("editor-width-slider");
|
||||
const slider = document.getElementById("editor-width-slider");
|
||||
const sliderValue = document.getElementById("editor-width-slider-value");
|
||||
if (slider) {
|
||||
if (sliderValue) {
|
||||
console.log("2");
|
||||
slider.value = this.settings.sliderPercentageDefault;
|
||||
sliderValue.textContent = this.settings.sliderPercentageDefault.toString();
|
||||
}
|
||||
}
|
||||
this.saveSettings();
|
||||
this.updateEditorStyleYAML();
|
||||
}
|
||||
// add element that contains all of the styling elements we need
|
||||
addStyle() {
|
||||
const css = document.createElement("style");
|
||||
css.id = "additional-editor-css";
|
||||
document.getElementsByTagName("head")[0].appendChild(css);
|
||||
document.body.classList.add("additional-editor-css");
|
||||
}
|
||||
// update the styles (at the start, or as the result of a settings change)
|
||||
updateEditorStyle() {
|
||||
const styleElement = document.getElementById("additional-editor-css");
|
||||
if (!styleElement)
|
||||
throw "additional-editor-css element not found!";
|
||||
else {
|
||||
styleElement.innerText = `
|
||||
body {
|
||||
--file-line-width: calc(700px + 10 * ${this.settings.sliderPercentage}px) !important;
|
||||
}
|
||||
`;
|
||||
}
|
||||
}
|
||||
// update the styles (at the start, or as the result of a settings change)
|
||||
updateEditorStyleYAMLHelper(editorWidth) {
|
||||
const styleElement = document.getElementById("additional-editor-css");
|
||||
if (!styleElement)
|
||||
throw "additional-editor-css element not found!";
|
||||
else {
|
||||
styleElement.innerText = `
|
||||
body {
|
||||
--file-line-width: calc(100px + ${editorWidth}vw) !important;
|
||||
}
|
||||
`;
|
||||
}
|
||||
}
|
||||
validateString(inputString) {
|
||||
return this.pattern.test(inputString);
|
||||
}
|
||||
updateEditorStyleYAML() {
|
||||
console.log("1.1");
|
||||
const file = this.app.workspace.getActiveFile();
|
||||
console.log("1.2");
|
||||
if (file.name) {
|
||||
const metadata = app.metadataCache.getFileCache(file);
|
||||
if (metadata) {
|
||||
if (metadata.frontmatter) {
|
||||
try {
|
||||
if (metadata.frontmatter["editor-width"]) {
|
||||
if (this.validateString(metadata.frontmatter["editor-width"])) {
|
||||
this.updateEditorStyleYAMLHelper(metadata.frontmatter["editor-width"]);
|
||||
} else {
|
||||
new WarningModal(this.app).open();
|
||||
throw new Error("Editor width must be a number from 0 to 100.");
|
||||
}
|
||||
} else {
|
||||
this.updateEditorStyle();
|
||||
}
|
||||
} catch (e) {
|
||||
console.error("Error:", e.message);
|
||||
}
|
||||
} else {
|
||||
this.updateEditorStyle();
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
// update the styles (at the start, or as the result of a settings change)
|
||||
updateSliderStyle() {
|
||||
const styleElements = document.getElementsByClassName("editor-width-slider");
|
||||
if (styleElements.length === 0) {
|
||||
throw new Error("editor-width-slider-value element not found!");
|
||||
} else {
|
||||
const styleElement = styleElements[0];
|
||||
styleElement.style.width = this.settings.sliderWidth + "px";
|
||||
}
|
||||
}
|
||||
// Method to load settings
|
||||
async loadSettings() {
|
||||
this.settings = Object.assign(
|
||||
{},
|
||||
DEFAULT_SETTINGS,
|
||||
await this.loadData()
|
||||
);
|
||||
}
|
||||
// Method to store settings
|
||||
async saveSettings() {
|
||||
await this.saveData(this.settings);
|
||||
}
|
||||
};
|
||||
|
||||
/* nosourcemap */
|
||||
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"id": "editor-width-slider",
|
||||
"name": "Editor Width Slider",
|
||||
"version": "1.0.5",
|
||||
"minAppVersion": "0.15.0",
|
||||
"description": "Customize Obsidian's editor width with a slider for a tailored editing experience.",
|
||||
"author": "@MugishoMp",
|
||||
"authorUrl": "https://github.com/MugishoMp",
|
||||
"fundingUrl": "https://www.paypal.com/donate/?hosted_button_id=E4APAMMHVJE4N",
|
||||
"isDesktopOnly": true
|
||||
}
|
||||
@@ -0,0 +1,8 @@
|
||||
/*
|
||||
|
||||
This CSS file will be included with your plugin, and
|
||||
available in the app when your plugin is enabled.
|
||||
|
||||
If your plugin does not need CSS, delete this file.
|
||||
|
||||
*/
|
||||
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"name": "Obsidian gruvbox",
|
||||
"version": "0.2.1",
|
||||
"minAppVersion": "0.16.0",
|
||||
"author": "insanum",
|
||||
"authorUrl": "https://insanum.com"
|
||||
}
|
||||
+579
@@ -0,0 +1,579 @@
|
||||
|
||||
:root
|
||||
{
|
||||
--dark0-hard_x: 29,32,33; /* #1d2021 */
|
||||
--dark0-hard: rgb(var(--dark0-hard_x));
|
||||
--dark0_x: 40,40,40; /* #282828 */
|
||||
--dark0: rgb(var(--dark0_x));
|
||||
--dark0-soft_x: 50,48,47; /* #32302f */
|
||||
--dark0-soft: rgb(var(--dark0-soft_x));
|
||||
--dark1_x: 60,56,54; /* #3c3836 */
|
||||
--dark1: rgb(var(--dark1_x));
|
||||
--dark2_x: 80,73,69; /* #504945 */
|
||||
--dark2: rgb(var(--dark2_x));
|
||||
--dark3_x: 102,92,84; /* #665c54 */
|
||||
--dark3: rgb(var(--dark3_x));
|
||||
--dark4_x: 124,111,100; /* #7c6f64 */
|
||||
--dark4: rgb(var(--dark4_x));
|
||||
--gray_x: 146,131,116; /* #928374 */
|
||||
--gray: rgb(var(--gray_x));
|
||||
|
||||
--light0-hard_x: 249,245,215; /* #f9f5d7 */
|
||||
--light0-hard: rgb(var(--light0-hard_x));
|
||||
--light0_x: 251,241,199; /* #fbf1c7 */
|
||||
--light0: rgb(var(--light0_x));
|
||||
--light0-soft_x: 242,229,188; /* #f2e5bc */
|
||||
--light0-soft: rgb(var(--light0-soft_x));
|
||||
--light1_x: 235,219,178; /* #ebdbb2 */
|
||||
--light1: rgb(var(--light1_x));
|
||||
--light2_x: 213,196,161; /* #d5c4a1 */
|
||||
--light2: rgb(var(--light2_x));
|
||||
--light3_x: 189,174,147; /* #bdae93 */
|
||||
--light3: rgb(var(--light3_x));
|
||||
--light4_x: 168,153,132; /* #a89984 */
|
||||
--light4: rgb(var(--light4_x));
|
||||
|
||||
--bright-red_x: 251,73,52; /* #fb4934 */
|
||||
--bright-red: rgb(var(--bright-red_x));
|
||||
--bright-green_x: 184,187,38; /* #b8bb26 */
|
||||
--bright-green: rgb(var(--bright-green_x));
|
||||
--bright-yellow_x: 250,189,47; /* #fabd2f */
|
||||
--bright-yellow: rgb(var(--bright-yellow_x));
|
||||
--bright-blue_x: 131,165,152; /* #83a598 */
|
||||
--bright-blue: rgb(var(--bright-blue_x));
|
||||
--bright-purple_x: 211,134,155; /* #d3869b */
|
||||
--bright-purple: rgb(var(--bright-purple_x));
|
||||
--bright-aqua_x: 142,192,124; /* #8ec07c */
|
||||
--bright-aqua: rgb(var(--bright-aqua_x));
|
||||
--bright-orange_x: 254,128,25; /* #fe8019 */
|
||||
--bright-orange: rgb(var(--bright-orange_x));
|
||||
|
||||
--neutral-red_x: 204,36,29; /* #cc241d */
|
||||
--neutral-red: rgb(var(--neutral-red_x));
|
||||
--neutral-green_x: 152,151,26; /* #98971a */
|
||||
--neutral-green: rgb(var(--neutral-green_x));
|
||||
--neutral-yellow_x: 215,153,33; /* #d79921 */
|
||||
--neutral-yellow: rgb(var(--neutral-yellow_x));
|
||||
--neutral-blue_x: 69,133,136; /* #458588 */
|
||||
--neutral-blue: rgb(var(--neutral-blue_x));
|
||||
--neutral-purple_x: 177,98,134; /* #b16286 */
|
||||
--neutral-purple: rgb(var(--neutral-purple_x));
|
||||
--neutral-aqua_x: 104,157,106; /* #689d6a */
|
||||
--neutral-aqua: rgb(var(--neutral-aqua_x));
|
||||
--neutral-orange_x: 214,93,14; /* #d65d0e */
|
||||
--neutral-orange: rgb(var(--neutral-orange_x));
|
||||
|
||||
--faded-red_x: 157,0,6; /* #9d0006 */
|
||||
--faded-red: rgb(var(--faded-red_x));
|
||||
--faded-green_x: 121,116,14; /* #79740e */
|
||||
--faded-green: rgb(var(--faded-green_x));
|
||||
--faded-yellow_x: 181,118,20; /* #b57614 */
|
||||
--faded-yellow: rgb(var(--faded-yellow_x));
|
||||
--faded-blue_x: 7,102,120; /* #076678 */
|
||||
--faded-blue: rgb(var(--faded-blue_x));
|
||||
--faded-purple_x: 143,63,113; /* #8f3f71 */
|
||||
--faded-purple: rgb(var(--faded-purple_x));
|
||||
--faded-aqua_x: 66,123,88; /* #427b58 */
|
||||
--faded-aqua: rgb(var(--faded-aqua_x));
|
||||
--faded-orange_x: 175,58,3; /* #af3a03 */
|
||||
--faded-orange: rgb(var(--faded-orange_x));
|
||||
}
|
||||
|
||||
body
|
||||
{
|
||||
--accent-h: 12; /* --faded-red #9d0006 */
|
||||
--accent-s: 107%;
|
||||
--accent-l: 32%;
|
||||
|
||||
--link-decoration: none;
|
||||
--link-decoration-hover: none;
|
||||
--link-external-decoration: none;
|
||||
--link-external-decoration-hover: none;
|
||||
|
||||
--tag-decoration: none;
|
||||
--tag-decoration-hover: underline;
|
||||
--tag-padding-x: .5em;
|
||||
--tag-padding-y: .2em;
|
||||
--tag-radius: .5em;
|
||||
|
||||
--tab-font-weight: 600;
|
||||
--bold-weight: 600;
|
||||
|
||||
--checkbox-radius: 0;
|
||||
|
||||
/* --list-indent: 2em; */
|
||||
|
||||
--embed-border-left: 6px double var(--interactive-accent);
|
||||
}
|
||||
|
||||
.theme-dark
|
||||
{
|
||||
--color-red-rgb: var(--neutral-red_x);
|
||||
--color-red: var(--neutral-red);
|
||||
--color-purple-rgb: var(--neutral-purple_x);
|
||||
--color-purple: var(--neutral-purple);
|
||||
--color-green-rgb: var(--neutral-green_x);
|
||||
--color-green: var(--neutral-green);
|
||||
--color-cyan-rgb: var(--neutral-blue_x);
|
||||
--color-cyan: var(--neutral-blue);
|
||||
--color-blue-rgb: var(--faded-blue_x);
|
||||
--color-blue: var(--faded-blue);
|
||||
--color-yellow-rgb: var(--neutral-yellow_x);
|
||||
--color-yellow: var(--neutral-yellow);
|
||||
--color-orange-rgb: var(--neutral-orange_x);
|
||||
--color-orange: var(--neutral-orange);
|
||||
--color-pink-rgb: var(--bright-purple_x);
|
||||
--color-pink: var(--bright-purple);
|
||||
|
||||
--background-primary: var(--dark0);
|
||||
--background-primary-alt: var(--dark0);
|
||||
--background-secondary: var(--dark0-hard);
|
||||
--background-secondary-alt: var(--dark1);
|
||||
--background-modifier-border: var(--dark1);
|
||||
|
||||
--cursor-line-background: rgba(var(--dark1_x), 0.5);
|
||||
|
||||
--text-normal: var(--light0);
|
||||
--text-faint: var(--light1);
|
||||
--text-muted: var(--light2);
|
||||
|
||||
--link-url: var(--neutral-green);
|
||||
|
||||
--h1-color: var(--neutral-red);
|
||||
--h2-color: var(--neutral-yellow);
|
||||
--h3-color: var(--neutral-green);
|
||||
--h4-color: var(--neutral-aqua);
|
||||
--h5-color: var(--neutral-blue);
|
||||
--h6-color: var(--neutral-purple);
|
||||
|
||||
--text-highlight-bg: var(--neutral-yellow);
|
||||
--text-highlight-fg: var(--dark0-hard);
|
||||
|
||||
--text-accent: var(--neutral-orange);
|
||||
--text-accent-hover: var(--bright-aqua);
|
||||
|
||||
--tag-color: var(--bright-aqua);
|
||||
--tag-background: var(--dark2);
|
||||
--tag-background-hover: var(--dark1);
|
||||
|
||||
--titlebar-text-color-focused: var(--bright-red);
|
||||
|
||||
--inline-title-color: var(--bright-yellow);
|
||||
|
||||
--bold-color: var(--neutral-yellow);
|
||||
--italic-color: var(--neutral-yellow);
|
||||
|
||||
--checkbox-color: var(--light4);
|
||||
--checkbox-color-hover: var(--light4);
|
||||
--checkbox-border-color: var(--light4);
|
||||
--checkbox-border-color-hover: var(--light4);
|
||||
--checklist-done-color: rgba(var(--light2_x), 0.5);
|
||||
|
||||
--table-header-background: rgba(var(--dark0_x), 0.2);
|
||||
--table-header-background-hover: var(--dark2);
|
||||
--table-row-even-background: rgba(var(--dark2_x), 0.2);
|
||||
--table-row-odd-background: rgba(var(--dark2_x), 0.4);
|
||||
--table-row-background-hover: var(--dark2);
|
||||
|
||||
--text-selection: rgba(var(--neutral-red_x), 0.6);
|
||||
--flashing-background: rgba(var(--neutral-red_x), 0.3);
|
||||
|
||||
--code-normal: var(--bright-blue);
|
||||
--code-background: var(--dark1);
|
||||
|
||||
--mermaid-note: var(--neutral-blue);
|
||||
--mermaid-actor: var(--dark2);
|
||||
--mermaid-loopline: var(--neutral-blue);
|
||||
--mermaid-exclude: var(--dark4);
|
||||
--mermaid-seqnum: var(--dark0);
|
||||
|
||||
--icon-color-hover: var(--bright-red);
|
||||
--icon-color-focused: var(--bright-blue);
|
||||
|
||||
--nav-item-color-hover: var(--bright-red);
|
||||
--nav-item-color-active: var(--bright-aqua);
|
||||
--nav-file-tag: rgba(var(--neutral-yellow_x), 0.9);
|
||||
|
||||
--graph-line: var(--dark2);
|
||||
--graph-node: var(--light3);
|
||||
--graph-node-tag: var(--neutral-red);
|
||||
--graph-node-attachment: var(--neutral-green);
|
||||
|
||||
--calendar-hover: var(--bright-red);
|
||||
--calendar-background-hover: var(--dark1);
|
||||
--calendar-week: var(--neutral-orange);
|
||||
--calendar-today: var(--neutral-orange);
|
||||
|
||||
--dataview-key: var(--text-faint);
|
||||
--dataview-key-background: rgba(var(--faded-red_x), 0.5);
|
||||
--dataview-value: var(--text-faint);
|
||||
--dataview-value-background: rgba(var(--neutral-green_x), 0.3);
|
||||
|
||||
--tab-text-color-focused-active: var(--neutral-yellow);
|
||||
--tab-text-color-focused-active-current: var(--bright-red);
|
||||
}
|
||||
|
||||
.theme-light
|
||||
{
|
||||
--color-red-rgb: var(--neutral-red_x);
|
||||
--color-red: var(--neutral-red);
|
||||
--color-purple-rgb: var(--neutral-purple_x);
|
||||
--color-purple: var(--neutral-purple);
|
||||
--color-green-rgb: var(--neutral-green_x);
|
||||
--color-green: var(--neutral-green);
|
||||
--color-cyan-rgb: var(--neutral-blue_x);
|
||||
--color-cyan: var(--neutral-blue);
|
||||
--color-blue-rgb: var(--faded-blue_x);
|
||||
--color-blue: var(--faded-blue);
|
||||
--color-yellow-rgb: var(--neutral-yellow_x);
|
||||
--color-yellow: var(--neutral-yellow);
|
||||
--color-orange-rgb: var(--neutral-orange_x);
|
||||
--color-orange: var(--neutral-orange);
|
||||
--color-pink-rgb: var(--bright-purple_x);
|
||||
--color-pink: var(--bright-purple);
|
||||
|
||||
--background-primary: var(--light0-hard);
|
||||
--background-primary-alt: var(--light0-hard);
|
||||
--background-secondary: var(--light1);
|
||||
--background-secondary-alt: var(--light1);
|
||||
--background-modifier-border: var(--light2);
|
||||
|
||||
--cursor-line-background: rgba(var(--light1_x), 0.5);
|
||||
|
||||
--text-normal: var(--dark0);
|
||||
--text-faint: var(--dark3);
|
||||
--text-muted: var(--dark2);
|
||||
|
||||
--link-url: var(--neutral-green);
|
||||
|
||||
--h1-color: var(--neutral-red);
|
||||
--h2-color: var(--neutral-yellow);
|
||||
--h3-color: var(--neutral-green);
|
||||
--h4-color: var(--neutral-aqua);
|
||||
--h5-color: var(--neutral-blue);
|
||||
--h6-color: var(--neutral-purple);
|
||||
|
||||
--text-highlight-bg: var(--bright-yellow);
|
||||
--text-highlight-fg: var(--dark0);
|
||||
|
||||
--text-accent: var(--neutral-orange);
|
||||
--text-accent-hover: var(--bright-aqua);
|
||||
|
||||
--tag-color: var(--neutral-aqua);
|
||||
--tag-background: var(--light1);
|
||||
--tag-background-hover: rgba(var(--light1_x), 0.6);
|
||||
|
||||
--titlebar-text-color-focused: var(--bright-red);
|
||||
|
||||
--inline-title-color: var(--bright-yellow);
|
||||
|
||||
--bold-color: var(--neutral-yellow);
|
||||
--italic-color: var(--neutral-yellow);
|
||||
|
||||
--checkbox-color: var(--light4);
|
||||
--checkbox-color-hover: var(--light4);
|
||||
--checkbox-border-color: var(--light4);
|
||||
--checkbox-border-color-hover: var(--light4);
|
||||
--checklist-done-color: rgba(var(--dark2_x), 0.4);
|
||||
|
||||
--table-header-background: rgba(var(--light3_x), 0.4);
|
||||
--table-header-background-hover: var(--light2);
|
||||
--table-row-even-background: rgba(var(--light1_x), 0.2);
|
||||
--table-row-odd-background: rgba(var(--light1_x), 0.7);
|
||||
--table-row-background-hover: var(--light2);
|
||||
|
||||
--text-selection: rgba(var(--neutral-red_x), 0.6);
|
||||
--flashing-background: rgba(var(--neutral-red_x), 0.3);
|
||||
|
||||
--code-normal: var(--bright-blue);
|
||||
--code-background: var(--light1);
|
||||
|
||||
--mermaid-note: var(--bright-blue);
|
||||
--mermaid-actor: var(--light3);
|
||||
--mermaid-loopline: var(--neutral-blue);
|
||||
--mermaid-exclude: var(--light2);
|
||||
--mermaid-seqnum: var(--light0);
|
||||
|
||||
--icon-color-hover: var(--bright-red);
|
||||
--icon-color-focused: var(--bright-blue);
|
||||
|
||||
--nav-item-color-hover: var(--bright-red);
|
||||
--nav-item-color-active: var(--neutral-blue);
|
||||
--nav-file-tag: rgba(var(--neutral-blue_x), 0.9);
|
||||
|
||||
--graph-line: var(--light1);
|
||||
--graph-node: var(--gray);
|
||||
--graph-node-tag: var(--neutral-red);
|
||||
--graph-node-attachment: var(--bright-green);
|
||||
|
||||
--calendar-hover: var(--bright-red);
|
||||
--calendar-background-hover: var(--light1);
|
||||
--calendar-week: var(--bright-red);
|
||||
--calendar-today: var(--bright-red);
|
||||
|
||||
--dataview-key: var(--text-faint);
|
||||
--dataview-key-background: rgba(var(--faded-red_x), 0.3);
|
||||
--dataview-value: var(--text-faint);
|
||||
--dataview-value-background: rgba(var(--neutral-green_x), 0.2);
|
||||
|
||||
--tab-text-color-focused-active: var(--neutral-yellow);
|
||||
--tab-text-color-focused-active-current: var(--bright-red);
|
||||
}
|
||||
|
||||
table
|
||||
{
|
||||
border: 1px solid var(--background-secondary) !important;
|
||||
border-collapse: collapse;
|
||||
}
|
||||
|
||||
thead
|
||||
{
|
||||
border-bottom: 2px solid var(--background-modifier-border) !important;
|
||||
}
|
||||
|
||||
th
|
||||
{
|
||||
font-weight: 600 !important;
|
||||
border: 1px solid var(--background-secondary) !important;
|
||||
}
|
||||
|
||||
td
|
||||
{
|
||||
border-left: 1px solid var(--background-secondary) !important;
|
||||
border-right: 1px solid var(--background-secondary) !important;
|
||||
border-bottom: 1px solid var(--background-secondary) !important;
|
||||
}
|
||||
|
||||
.markdown-rendered tbody tr:nth-child(even)
|
||||
{
|
||||
background-color: var(--table-row-even-background) !important;
|
||||
}
|
||||
|
||||
.markdown-rendered tbody tr:nth-child(odd)
|
||||
{
|
||||
background-color: var(--table-row-odd-background) !important;
|
||||
}
|
||||
|
||||
.markdown-rendered tbody tr:nth-child(even):hover,
|
||||
.markdown-rendered tbody tr:nth-child(odd):hover
|
||||
{
|
||||
background-color: var(--table-row-background-hover) !important;
|
||||
}
|
||||
|
||||
.markdown-rendered mark
|
||||
{
|
||||
background-color: var(--text-highlight-bg);
|
||||
color: var(--text-highlight-fg);
|
||||
}
|
||||
|
||||
.markdown-rendered mark a
|
||||
{
|
||||
color: var(--red) !important;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.search-result-file-matched-text
|
||||
{
|
||||
color: var(--text-highlight-fg) !important;
|
||||
}
|
||||
|
||||
.cm-hashtag-begin:hover, .cm-hashtag-end:hover
|
||||
{
|
||||
color: var(--text-accent);
|
||||
/* background-color: var(--tag-background-hover); */
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
input[type=checkbox]
|
||||
{
|
||||
border: 1px solid var(--checkbox-color);
|
||||
}
|
||||
|
||||
input[type=checkbox]:checked
|
||||
{
|
||||
background-color: var(--checkbox-color);
|
||||
box-shadow: inset 0 0 0 2px var(--background-primary);
|
||||
}
|
||||
|
||||
input[type=checkbox]:checked:after
|
||||
{
|
||||
display: none;
|
||||
}
|
||||
|
||||
code[class*="language-"],
|
||||
pre[class*="language-"]
|
||||
{
|
||||
line-height: var(--line-height-tight) !important;
|
||||
}
|
||||
|
||||
.cm-url
|
||||
{
|
||||
color: var(--link-url) !important;
|
||||
}
|
||||
|
||||
.cm-url:hover
|
||||
{
|
||||
color: var(--text-accent-color) !important;
|
||||
}
|
||||
|
||||
/* Keep highlight/marks the same between viewer and editor. */
|
||||
.cm-highlight
|
||||
{
|
||||
color: var(--text-highlight-fg) !important;
|
||||
}
|
||||
|
||||
/* Keep inline code the same between viewer and editor. */
|
||||
.cm-inline-code
|
||||
{
|
||||
border-radius: var(--radius-s);
|
||||
font-size: var(--code-size);
|
||||
padding: 0.1em 0.25em;
|
||||
}
|
||||
|
||||
.cm-line .cm-strong
|
||||
{
|
||||
color: var(--bold-color) !important;
|
||||
}
|
||||
|
||||
/*
|
||||
* Keep list bullet padding the same between viewer and editor.
|
||||
* This is annoying with the cursor in the editor as there is a gap.
|
||||
*/
|
||||
/*
|
||||
.cm-formatting-list
|
||||
{
|
||||
padding-right: 4px !important;
|
||||
}
|
||||
*/
|
||||
|
||||
/*
|
||||
* Keep sub-list indenting the same between viewer and editor.
|
||||
* This assumes --list-indent is default at 2em.
|
||||
*/
|
||||
/*
|
||||
.cm-indent
|
||||
{
|
||||
text-indent: 1em !important;
|
||||
}
|
||||
*/
|
||||
|
||||
.mermaid .note
|
||||
{
|
||||
fill: var(--mermaid-note) !important;
|
||||
}
|
||||
|
||||
.mermaid .actor
|
||||
{
|
||||
fill: var(--mermaid-actor) !important;
|
||||
}
|
||||
|
||||
.mermaid .loopLine
|
||||
{
|
||||
stroke: var(--mermaid-loopline) !important;
|
||||
}
|
||||
|
||||
.mermaid .loopText>tspan,
|
||||
.mermaid .entityLabel
|
||||
{
|
||||
fill: var(--neutral-red) !important;
|
||||
}
|
||||
|
||||
.mermaid .exclude-range
|
||||
{
|
||||
fill: var(--mermaid-exclude) !important;
|
||||
}
|
||||
|
||||
.mermaid .sequenceNumber
|
||||
{
|
||||
fill: var(--mermaid-seqnum) !important;
|
||||
}
|
||||
|
||||
.calendar .week-num
|
||||
{
|
||||
color: var(--calendar-week) !important;
|
||||
}
|
||||
|
||||
.calendar .today
|
||||
{
|
||||
color: var(--calendar-today) !important;
|
||||
}
|
||||
|
||||
.calendar .week-num:hover,
|
||||
.calendar .day:hover
|
||||
{
|
||||
color: var(--calendar-hover) !important;
|
||||
background-color: var(--calendar-background-hover) !important;
|
||||
}
|
||||
|
||||
.markdown-embed-title
|
||||
{
|
||||
color: var(--yellow);
|
||||
font-weight: 600 !important;
|
||||
}
|
||||
|
||||
.cm-active
|
||||
{
|
||||
background-color: var(--cursor-line-background) !important;
|
||||
}
|
||||
|
||||
.nav-file-tag
|
||||
{
|
||||
color: var(--nav-file-tag) !important;
|
||||
}
|
||||
|
||||
.is-flashing
|
||||
{
|
||||
background-color: var(--flashing-background) !important;
|
||||
}
|
||||
|
||||
.dataview.inline-field-key
|
||||
{
|
||||
border-top-left-radius: var(--radius-s);
|
||||
border-bottom-left-radius: var(--radius-s);
|
||||
padding-left: 4px;
|
||||
font-family: var(--font-monospace);
|
||||
font-size: var(--font-smaller);
|
||||
color: var(--dataview-key) !important;
|
||||
background-color: var(--dataview-key-background) !important;
|
||||
}
|
||||
|
||||
.dataview.inline-field-value
|
||||
{
|
||||
border-top-right-radius: var(--radius-s);
|
||||
border-bottom-right-radius: var(--radius-s);
|
||||
padding-right: 4px;
|
||||
font-family: var(--font-monospace);
|
||||
font-size: var(--font-smaller);
|
||||
color: var(--dataview-value) !important;
|
||||
background-color: var(--dataview-value-background) !important;
|
||||
}
|
||||
|
||||
.suggestion-highlight
|
||||
{
|
||||
color: var(--bright-red);
|
||||
}
|
||||
|
||||
body {
|
||||
--callout-border-width: 1px;
|
||||
--callout-border-opacity: 0.4;
|
||||
/* Order as defined in app.css */
|
||||
--callout-default: var(--neutral-blue_x);
|
||||
--callout-note: var(--neutral-blue_x);
|
||||
--callout-summary: var(--neutral-aqua_x);
|
||||
--callout-info: var(--neutral-blue_x);
|
||||
--callout-todo: var(--neutral-blue_x);
|
||||
--callout-important: var(--neutral-aqua_x);
|
||||
--callout-tip: var(--neutral-aqua_x);
|
||||
--callout-success: var(--neutral-green_x);
|
||||
--callout-question: var(--neutral-yellow_x);
|
||||
--callout-warning: var(--neutral-orange_x);
|
||||
--callout-fail: var(--neutral-red_x);
|
||||
--callout-error: var(--neutral-red_x);
|
||||
--callout-bug: var(--neutral-red_x);
|
||||
--callout-example: var(--neutral-purple_x);
|
||||
--callout-quote: var(--gray_x);
|
||||
}
|
||||
|
||||
.callout {
|
||||
background-color: rgba(var(--callout-color), 0.2);
|
||||
}
|
||||
Vendored
+237
@@ -0,0 +1,237 @@
|
||||
{
|
||||
"main": {
|
||||
"id": "b741307f012c6c82",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "3191879d32e51458",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "716943f64774c290",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "canvas",
|
||||
"state": {
|
||||
"file": "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas",
|
||||
"viewState": {
|
||||
"x": 893.2958606826328,
|
||||
"y": 1014.1714018415311,
|
||||
"zoom": -0.35771249981815517
|
||||
}
|
||||
},
|
||||
"icon": "lucide-layout-dashboard",
|
||||
"title": "WF-P2 Admin RBAC"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "vertical"
|
||||
},
|
||||
"left": {
|
||||
"id": "c60ac6c168fcc346",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "619cad1e354c5111",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "641e6094f7934e28",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "file-explorer",
|
||||
"state": {
|
||||
"sortOrder": "alphabetical",
|
||||
"autoReveal": false
|
||||
},
|
||||
"icon": "lucide-folder-closed",
|
||||
"title": "Files"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "1c5acae913f15f67",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "search",
|
||||
"state": {
|
||||
"query": "",
|
||||
"matchingCase": false,
|
||||
"explainSearch": false,
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical"
|
||||
},
|
||||
"icon": "lucide-search",
|
||||
"title": "Search"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "5e3db645e8d39109",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "bookmarks",
|
||||
"state": {},
|
||||
"icon": "lucide-bookmark",
|
||||
"title": "Bookmarks"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "horizontal",
|
||||
"width": 300
|
||||
},
|
||||
"right": {
|
||||
"id": "9a2b29e007036e47",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "d3ee1dedc0dff4c8",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "de35e85ca527f8f4",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "backlink",
|
||||
"state": {
|
||||
"file": "02 Wireframes/_Templates/Wireframe Paket Template.md",
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical",
|
||||
"showSearch": false,
|
||||
"searchQuery": "",
|
||||
"backlinkCollapsed": false,
|
||||
"unlinkedCollapsed": true
|
||||
},
|
||||
"icon": "links-coming-in",
|
||||
"title": "Backlinks for Wireframe Paket Template"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "829c4eac50f34830",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "outgoing-link",
|
||||
"state": {
|
||||
"file": "02 Wireframes/_Templates/Wireframe Paket Template.md",
|
||||
"linksCollapsed": false,
|
||||
"unlinkedCollapsed": true
|
||||
},
|
||||
"icon": "links-going-out",
|
||||
"title": "Outgoing links from Wireframe Paket Template"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "24f2b9ae0b1c593f",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "tag",
|
||||
"state": {
|
||||
"sortOrder": "frequency",
|
||||
"useHierarchy": true,
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-tags",
|
||||
"title": "Tags"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "9d900d312445f8dc",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "all-properties",
|
||||
"state": {
|
||||
"sortOrder": "frequency",
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-archive",
|
||||
"title": "All properties"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "2bb50056cef4b029",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "outline",
|
||||
"state": {
|
||||
"file": "02 Wireframes/_Templates/Wireframe Paket Template.md",
|
||||
"followCursor": false,
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-list",
|
||||
"title": "Outline of Wireframe Paket Template"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "horizontal",
|
||||
"width": 300,
|
||||
"collapsed": true
|
||||
},
|
||||
"left-ribbon": {
|
||||
"hiddenItems": {
|
||||
"switcher:Open quick switcher": false,
|
||||
"graph:Open graph view": false,
|
||||
"canvas:Create new canvas": false,
|
||||
"daily-notes:Open today's daily note": false,
|
||||
"templates:Insert template": false,
|
||||
"command-palette:Open command palette": false,
|
||||
"bases:Create new base": false
|
||||
}
|
||||
},
|
||||
"active": "716943f64774c290",
|
||||
"lastOpenFiles": [
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas",
|
||||
"02 Wireframes/Screen Paket Tracker.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/M02 Wiederherstellungscode eingeben.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/M01 Admin kontaktieren.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/S01 Passwort Reset anfordern.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Signup/Screens/S03 E-Mail bestaetigen.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Signup/Screens/S02 Signup erfolgreich Workspace wird vorbereitet.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Signup/Screens/S01 Signup.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.md",
|
||||
"01 Regeln/Wireframing Playbook.md",
|
||||
"01 Regeln/Obsidian Struktur.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle erstellen bearbeiten.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S02 Rollen und Berechtigungen.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D01 Rollen-Dropdown in Mitarbeiterliste.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S01 Mitarbeiterliste.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/M01 Loeschung anfragen.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/S01 Settings Workspaces Loeschbereich.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/Screens/S01 Profil Settings.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens/M03 2FA deaktivieren.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens/M02 Device Token hinzufuegen.md",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Varianten",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Varianten",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens",
|
||||
"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Varianten",
|
||||
"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Change Password/Varianten",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Change Password/Screens",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/Varianten",
|
||||
"02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/Screens"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,38 @@
|
||||
# HiveGrid Screen Project
|
||||
|
||||
Das ist der Obsidian-Vault fuer HiveGrid Wireframes, Screen-Pakete und UX-Handoffs.
|
||||
|
||||
Ziel: Alle Wireframe-Regeln, Pakete, Screen-Notizen, Banner, Toasts, Zustaende und Subframe-Links an einem Ort sammeln.
|
||||
|
||||
---
|
||||
|
||||
## Wo liegt was?
|
||||
|
||||
| Bereich | Zweck |
|
||||
|---|---|
|
||||
| [[01 Regeln/Wireframing Playbook]] | Grundregeln: Was wird gebaut, was nur dokumentiert, wie laufen Brainstorming und Handoff? |
|
||||
| [[01 Regeln/Obsidian Struktur]] | Wie dieser Vault aufgebaut ist und wie Dateien benannt werden. |
|
||||
| [[02 Wireframes/Screen Paket Tracker]] | Zentrale Kontrolltabelle fuer alle Flows, Screens, Canvas- und Subframe-Links. |
|
||||
| [[02 Wireframes/_Templates/Wireframe Paket Template]] | Vorlage fuer ein neues Wireframe-Paket. |
|
||||
| [[02 Wireframes/_Templates/Screen Template]] | Vorlage fuer eine einzelne Screen-Datei. |
|
||||
| [[03 Quellen und Repo/Repo Notizen]] | Wo das Gitea-Repo liegt und wie du die Planning-Dateien aktualisierst. |
|
||||
|
||||
---
|
||||
|
||||
## Arbeitsregel
|
||||
|
||||
Vor jedem neuen Flow:
|
||||
|
||||
1. Klaeren, was ueberhaupt gewollt ist.
|
||||
2. Planning-Quellen lesen.
|
||||
3. Scope sammeln.
|
||||
4. Genau einen kleinen Flow auswaehlen.
|
||||
5. Varianten brainstormen.
|
||||
6. David entscheidet die Richtung.
|
||||
7. Danach erst Screen-Kandidaten sammeln.
|
||||
8. Jeden Screen einzeln validieren.
|
||||
9. Erst dann in Subframe/Canvas einbauen.
|
||||
10. Danach als Markdown-Paket ablegen.
|
||||
11. Handoff-Check machen.
|
||||
|
||||
Keine riesigen Boards. Lieber kleine, saubere Flow-Pakete.
|
||||
@@ -0,0 +1,153 @@
|
||||
---
|
||||
kind: rule
|
||||
project: HiveGrid Screen Project
|
||||
area: Obsidian
|
||||
status: active
|
||||
---
|
||||
|
||||
# Obsidian Struktur
|
||||
|
||||
Dieser Vault ist der Arbeitsbereich fuer Screens, Wireframes und Handoffs.
|
||||
|
||||
---
|
||||
|
||||
## Ordner
|
||||
|
||||
| Ordner | Zweck |
|
||||
|---|---|
|
||||
| `01 Regeln` | dauerhafte Regeln und Arbeitsweisen |
|
||||
| `02 Wireframes` | alle Wireframe-Pakete, Screen-Dateien und Canvas-Dateien |
|
||||
| `02 Wireframes/_Templates` | Vorlagen fuer neue Pakete und Screens |
|
||||
| `03 Quellen und Repo` | Hinweise zum Gitea-Repo und lokalen Planning-Dateien |
|
||||
| `hivegrid-cloud` | technisches Repo mit Planning-Quellen |
|
||||
|
||||
---
|
||||
|
||||
## Dateiarten
|
||||
|
||||
| Dateiart | Beispiel | Zweck |
|
||||
|---|---|---|
|
||||
| Paket-Datei | `WF-[Ticket] [Flow Name].md` | sammelt Scope, Brainstorming, Screen-Liste und Handoff |
|
||||
| Screen-Datei | `S01 Profil auswaehlen.md` | beschreibt genau einen Screen |
|
||||
| State-Datei | `ST01 Keine Suchergebnisse.md` | beschreibt einen Zustand, der nicht als eigener Frame gebaut wird |
|
||||
| Canvas-Datei | `WF-[Ticket] [Flow Name].canvas` | visueller Flow-Tree in Obsidian Canvas |
|
||||
| Tracker | `Screen Paket Tracker.md` | Uebersicht ueber Pakete und Status |
|
||||
|
||||
---
|
||||
|
||||
## Flow-Typen
|
||||
|
||||
| Typ | Bedeutung |
|
||||
|---|---|
|
||||
| Normaler Flow | eigener Nutzerweg mit Start, Entscheidung und Ziel |
|
||||
| Zubringerflow | klaert Vorbedingungen und fuehrt in einen anderen Flow |
|
||||
| Auth-Core-Flow | zentraler Sicherheitsflow, der von mehreren Zubringerflows genutzt wird |
|
||||
|
||||
Aktuelle Auth-Core-Entscheidung:
|
||||
|
||||
- `WF-P2 Set Password` ist ein zentraler Auth-Core-Flow.
|
||||
- Passwort Reset, Einladung/initialer Mitarbeiterzugang, Passwort aendern, Admin-Reset und Security-Incident koennen dorthin fuehren.
|
||||
- Neukunden-Signup ist die Ausnahme und setzt das Passwort direkt im Signup-Flow.
|
||||
|
||||
---
|
||||
|
||||
## Benennung
|
||||
|
||||
Pakete:
|
||||
|
||||
```text
|
||||
WF-[Ticket] [Name].md
|
||||
```
|
||||
|
||||
Screens:
|
||||
|
||||
```text
|
||||
S01 [Screen Name].md
|
||||
S02 [Screen Name].md
|
||||
B01 [Branch Name].md
|
||||
ST01 [State Name].md
|
||||
```
|
||||
|
||||
IDs:
|
||||
|
||||
- `S01`, `S02`, `S03` = Hauptflow
|
||||
- `B01`, `B02`, `B03` = Branch/Variante
|
||||
- `M01`, `M02` = Modal/Overlay
|
||||
- `ST01`, `ST02` = Zustand
|
||||
|
||||
---
|
||||
|
||||
## Link-Anzeige in Tabellen
|
||||
|
||||
In Tabellen werden lange Links mit normalen Markdown-Links gekuerzt.
|
||||
|
||||
Warum: Obsidian-Wiki-Aliase nutzen `|`, und dieses Zeichen kann Markdown-Tabellen kaputt machen.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```md
|
||||
[MD](<P2 Auth/WF-P2 Login und 2FA/Screens/S01 Login.md>)
|
||||
[Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>)
|
||||
```
|
||||
|
||||
Regel:
|
||||
|
||||
- In Tracker-Tabellen kurze Labels verwenden: `MD`, `Canvas`, `Subframe`.
|
||||
- In Tabellen keine `[[Pfad|Alias]]`-Links verwenden.
|
||||
- Lange Pfade nur in der Datei selbst oder im Frontmatter ausschreiben.
|
||||
- Der sichtbare Tabelleninhalt soll scanbar bleiben.
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter
|
||||
|
||||
Jede Paket- und Screen-Datei bekommt oben Metadaten. Dadurch kann Obsidian spaeter Tabellen daraus bauen.
|
||||
|
||||
Beispiel Screen:
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: screen
|
||||
ticket: P2
|
||||
package: WF-[Ticket] [Flow Name]
|
||||
id: S01
|
||||
screen: Profil auswaehlen
|
||||
umsetzung: Bauen
|
||||
status: Validiert
|
||||
subframe: ""
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Obsidian Canvas
|
||||
|
||||
Canvas-Dateien liegen direkt im jeweiligen Paketordner.
|
||||
|
||||
Grid-Regel:
|
||||
|
||||
- Hauptflow nach rechts
|
||||
- Varianten nach unten
|
||||
- Varianten laufen danach wieder nach rechts weiter
|
||||
- wenn es unuebersichtlich wird, entsteht ein neues Paket
|
||||
|
||||
Qualitaetsregel:
|
||||
|
||||
- keine ueberlappenden Nodes
|
||||
- keine verdeckten Labels
|
||||
- keine Kante durch andere Karten
|
||||
- kurze Kantenlabels mit genug Abstand
|
||||
- Canvas nach dem Erstellen mit JSON-Check pruefen
|
||||
|
||||
---
|
||||
|
||||
## Subframe-Schutz
|
||||
|
||||
Subframe wird nicht automatisch aus dem Tracker heraus bearbeitet.
|
||||
|
||||
Regel:
|
||||
|
||||
- Bestehende Subframe-Screens bleiben unberuehrt, auch wenn sie gleich heissen.
|
||||
- Der Assistant darf Subframe nur nach expliziter Freigabe fuer einen konkreten Flow nutzen.
|
||||
- Ohne Freigabe werden nur Obsidian-Dateien vorbereitet: Paket, Screens, Canvas, Tracker.
|
||||
- David kann bestehende oder gleichnamige Subframe-Screens spaeter selbst pruefen, ersetzen oder loeschen.
|
||||
@@ -0,0 +1,560 @@
|
||||
---
|
||||
kind: rule
|
||||
project: HiveGrid Screen Project
|
||||
area: Wireframing
|
||||
status: active
|
||||
---
|
||||
|
||||
# Wireframing Playbook
|
||||
|
||||
Stand: 2026-06-24
|
||||
|
||||
Dieses Playbook definiert, wie Wireframe-Pakete fuer HiveGrid in Obsidian vorbereitet, validiert und als Markdown/Canvas abgelegt werden. Subframe wird nur nach expliziter Freigabe genutzt.
|
||||
|
||||
Ziel: Nicht jeden Spezialzustand einzeln bauen, sondern nur die Screens bauen, die Struktur, Aufgabe, Entscheidung oder Risiko sichtbar machen.
|
||||
|
||||
---
|
||||
|
||||
## 1. Grundprinzip
|
||||
|
||||
Ein Wireframe klaert:
|
||||
|
||||
- was der Nutzer auf diesem Screen tun soll
|
||||
- welche Daten sichtbar sind
|
||||
- welche Aktionen moeglich sind
|
||||
- welche Entscheidungen oder Blocker existieren
|
||||
- welche Komponenten/Archetypen wiederverwendet werden
|
||||
|
||||
Subframe wird erst nach expliziter Freigabe genutzt. Mikro-Zustaende werden dokumentiert, aber nicht jedes Mal als eigener Frame gebaut.
|
||||
|
||||
Wichtig: Der Assistant bereitet Flows, Screen-Dateien und Canvas in Obsidian vor. David validiert und kann die Screens selbst in Subframe bauen. Bestehende Subframe-Screens werden nicht automatisch bearbeitet, ueberschrieben oder geloescht, auch wenn sie gleich heissen.
|
||||
|
||||
---
|
||||
|
||||
## 2. Arbeitsablauf pro Wireframe-Paket
|
||||
|
||||
Kein Flow wird direkt gebaut. Vorher gibt es immer ein kurzes Brainstorming und eine Validierung.
|
||||
|
||||
Es wird immer nur **ein kleines Paket nach dem anderen** bearbeitet. Nicht mehrere Flows gleichzeitig finalisieren.
|
||||
|
||||
Grundregel:
|
||||
|
||||
```text
|
||||
Ein Flow -> Varianten brainstormen -> Entscheidung treffen -> Screen-Kandidaten sammeln -> jeden Screen validieren -> erst dann bauen/ablegen.
|
||||
```
|
||||
|
||||
Screen-Listen entstehen aus dem Brainstorming. Sie werden nicht vorab automatisch festgelegt.
|
||||
|
||||
0. **Intent Check: Was ist ueberhaupt gewollt?**
|
||||
- Welches Ticket oder Modul ist betroffen?
|
||||
- Was soll der Nutzer am Ende schaffen?
|
||||
- Geht es um einen echten Flow, einen einzelnen Screen, einen Zustand oder nur Dokumentation?
|
||||
- Welche Planning-Quellen muessen gelesen werden?
|
||||
- Welche Annahmen sind noch unsicher?
|
||||
- Was ist ausdruecklich nicht Teil dieses Pakets?
|
||||
|
||||
1. **Scope sammeln**
|
||||
- Ticket/Modul
|
||||
- Ziel des Flows
|
||||
- Nutzerrolle
|
||||
- Rollenunterschiede: normale Rolle vs. Admin
|
||||
- Startpunkt
|
||||
- wichtige Daten
|
||||
- wichtige Aktionen
|
||||
- bekannte Constraints aus Planning/Specs
|
||||
|
||||
2. **Mini-Brainstorming**
|
||||
- Was ist der Happy Path?
|
||||
- Wo verzweigt der Flow?
|
||||
- Wo kann der Nutzer blockiert sein?
|
||||
- Welche Fehler, Warnungen, Success-Zustaende und Hinweise koennen auftreten?
|
||||
- Welche davon sind Inline, Banner, Toast, Modal oder eigener Screen?
|
||||
- Welche UX-Varianten sind denkbar?
|
||||
- Was spricht fuer oder gegen jede Variante?
|
||||
- Welche Variante empfiehlt der Assistant?
|
||||
- Welche Variante entscheidet David?
|
||||
- Erst danach: Welche Screens/Zustaende koennten daraus entstehen?
|
||||
|
||||
3. **Entscheidungsschritt**
|
||||
- David entscheidet die UX-Richtung.
|
||||
- Offene Fragen werden markiert.
|
||||
- Wenn keine Entscheidung moeglich ist, wird das Paket nicht gebaut.
|
||||
- Erst nach der Entscheidung entsteht eine Screen-Kandidatenliste.
|
||||
|
||||
4. **Screen Validation Gate**
|
||||
- Jeder Screen-Kandidat wird einzeln entschieden.
|
||||
- Kein Screen wird in Subframe gebaut, bevor er validiert ist.
|
||||
- Kein Screen wird in den Flow eingebaut, nur weil er "vielleicht gebraucht" wird.
|
||||
- Fehler-/Meldungszustaende werden einzeln entschieden: Inline, Banner, Toast, Modal, eigener Screen oder nur Dokumentation.
|
||||
- Ein Screen bekommt erst danach eine Umsetzung: `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter` oder `Raus`.
|
||||
|
||||
5. **Validierung vor dem Bau**
|
||||
- Screen-Liste steht
|
||||
- Reuse-vs-Bauen ist entschieden
|
||||
- offene Fragen sind markiert
|
||||
- Hauptflow und Varianten sind verstanden
|
||||
- jeder Screen wurde einzeln geprueft
|
||||
|
||||
6. **Screen-Dateien/Canvas vorbereiten**
|
||||
- nur die validierten Screens
|
||||
- Canvas nur fuer den validierten Flow anlegen
|
||||
- vorhandene D0-Komponenten und Archetypen dokumentieren
|
||||
- keine unnoetigen Sonderkomponenten erfinden
|
||||
- kein Subframe-Bau ohne ausdrueckliche Freigabe von David
|
||||
|
||||
7. **Markdown-Paket schreiben**
|
||||
- Screen-Liste
|
||||
- Subframe-Links
|
||||
- Daten je Screen
|
||||
- Aktionen je Screen
|
||||
- Banner, Toasts und Inline-Meldungen
|
||||
- Zustaende
|
||||
- offene Fragen
|
||||
|
||||
8. **Handoff-Check**
|
||||
- jedes sichtbare Feld hat eine Datenquelle
|
||||
- jeder Button hat eine Aktion
|
||||
- die relevanten Zustaende sind beschrieben
|
||||
- der Screen ist als `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter` oder `Raus` markiert
|
||||
|
||||
---
|
||||
|
||||
## 2a. Brainstorming-Regeln
|
||||
|
||||
Brainstorming ist Pflicht, bevor Screens festgelegt werden.
|
||||
|
||||
Der Assistant darf nicht direkt eine finale Screen-Liste erzeugen. Er arbeitet zuerst mit Optionen.
|
||||
|
||||
### Ablauf
|
||||
|
||||
1. **Flow-Frage formulieren**
|
||||
- Worum geht es in diesem Flow?
|
||||
- Welches Nutzerproblem wird geloest?
|
||||
- Was ist der Startpunkt und was ist das Ziel?
|
||||
|
||||
2. **Varianten anbieten**
|
||||
- mindestens 2 sinnvolle Varianten, wenn es echte UX-Entscheidungen gibt
|
||||
- pro Variante kurz: Vorteil, Nachteil, Aufwand, Risiko
|
||||
- keine Scheingenauigkeit, wenn eine Variante offensichtlich falsch ist
|
||||
|
||||
3. **Empfehlung geben**
|
||||
- der Assistant darf eine Empfehlung geben
|
||||
- die Empfehlung ist nicht automatisch die Entscheidung
|
||||
|
||||
4. **David entscheidet**
|
||||
- Entscheidung markieren als `genommen`, `spaeter`, `raus` oder `unklar`
|
||||
- bei `unklar` wird nicht gebaut
|
||||
|
||||
5. **Screen-Kandidaten ableiten**
|
||||
- erst nach Davids Entscheidung
|
||||
- Kandidaten sind noch nicht final
|
||||
- Meldungs-/Error-State-Kandidaten werden separat gesammelt
|
||||
|
||||
6. **Screen Validation Gate**
|
||||
- jeder Kandidat wird einzeln geprueft
|
||||
- danach erst finale Liste
|
||||
- jeder relevante Fehler-/Meldungszustand bekommt eine UI-Form
|
||||
|
||||
### Entscheidungsformat
|
||||
|
||||
Fuer Brainstorming wird dieses Format genutzt:
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | - | - | - | - |
|
||||
| B | - | - | - | - |
|
||||
|
||||
Danach:
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| - | genommen / spaeter / raus / unklar | - |
|
||||
|
||||
### Meldungs-/Error-State-Check im Brainstorming
|
||||
|
||||
Bei jedem Flow wird waehrend des Brainstormings abgefragt:
|
||||
|
||||
- Was kann erfolgreich passieren?
|
||||
- Was kann fehlschlagen?
|
||||
- Was kann den Nutzer blockieren?
|
||||
- Was muss der Nutzer sofort korrigieren koennen?
|
||||
- Was darf nicht verschwinden?
|
||||
- Was ist copy-kritisch oder sicherheitskritisch?
|
||||
- Welche Meldungen duerfen nicht dem Developer ueberlassen werden?
|
||||
|
||||
Diese Matrix wird fuer jedes Paket genutzt:
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| - | Inline / Banner / Toast / Modal / Screen | ja / nein | ja / nein | - |
|
||||
|
||||
Regel: Ein Fehler wird nicht danach entschieden, ob er technisch ein Error ist, sondern danach, was der Nutzer als Naechstes tun muss.
|
||||
|
||||
---
|
||||
|
||||
## 2b. Rollen- und Permission-Regel
|
||||
|
||||
Bei jedem Flow wird kurz geprueft, ob sich die UX fuer Admin und normale Nutzer unterscheidet.
|
||||
|
||||
Standardannahme:
|
||||
|
||||
- **Normale Rolle** = hoechste Rolle unter Admin.
|
||||
- **Admin** = eigene Variante nur dann, wenn Ziel, Rechte, Daten oder Weiterleitung sichtbar anders sind.
|
||||
|
||||
Regeln:
|
||||
|
||||
- Wenn Admin nur nach erfolgreichem Login woanders landet, wird das als **Outcome** dokumentiert, nicht automatisch als eigener Screen gebaut.
|
||||
- Wenn Admin andere Daten, andere Aktionen oder andere Risiken sieht, wird eine eigene Variante geprueft.
|
||||
- Tenant-/Workspace-/Profil-Auswahl fuer Admin wird als eigener Flow behandelt, wenn sie mehr ist als eine reine Weiterleitung.
|
||||
- Permission-Denied, gesperrte Funktionen und sichtbare Rechte-Unterschiede werden im Screen-Paket dokumentiert.
|
||||
|
||||
Beispiel Login:
|
||||
|
||||
| Rolle | Nach erfolgreichem Login |
|
||||
|---|---|
|
||||
| Normale Rolle | Home/Dashboard |
|
||||
| Admin | Tenant-/Workspace-Auswahl oder Admin-Startpunkt |
|
||||
|
||||
---
|
||||
|
||||
## 2c. Zentrale Auth-Core-Flows
|
||||
|
||||
Manche Auth-Flows sind zentrale Sicherheitsbausteine und werden von mehreren anderen Flows angesteuert.
|
||||
|
||||
Aktuelle Produktentscheidung:
|
||||
|
||||
`Set Password` wird als zentraler Flow behandelt.
|
||||
|
||||
Er kann aus mehreren Zubringer-Flows gestartet werden:
|
||||
|
||||
- Passwort Reset
|
||||
- Einladung / initialer Mitarbeiterzugang
|
||||
- Passwort aendern
|
||||
- Admin-Reset
|
||||
- Sicherheitsmassnahme nach Incident
|
||||
|
||||
Regeln:
|
||||
|
||||
- Der zentrale Flow wird als eigenes Paket gebrainstormt und validiert.
|
||||
- Zubringer-Flows dokumentieren nur, wie der Nutzer in den zentralen Flow kommt.
|
||||
- Sonderregeln des Zubringer-Flows werden nicht im zentralen Flow versteckt, sondern im jeweiligen Paket dokumentiert.
|
||||
- Auth-Core-Flows brauchen eine dokumentierte Zurueck-/Abbrechen-Aktion, wenn ein Nutzer den Einstieg versehentlich geoeffnet haben kann, z. B. bei Passwort Reset.
|
||||
- Die Zurueck-Aktion ist normalerweise kein eigener Screen, sondern eine sekundare Navigation im jeweiligen Auth-Screen.
|
||||
- 2FA wird im Set-Password-Flow grundsaetzlich angeboten.
|
||||
- Wenn 2FA fuer den konkreten Einstieg verpflichtend ist, wird das im Zubringerpaket oder als Regel im Set-Password-Paket markiert.
|
||||
- Admin-Reset kann bestimmen, ob 2FA verpflichtend oder freiwillig ist.
|
||||
- Neukunden-Signup ist eine bewusste Ausnahme: Das Passwort wird direkt im Signup-Flow gesetzt, damit der Einstieg moeglichst wenig Reibung hat.
|
||||
|
||||
Wichtig: Diese Entscheidung weicht bewusst von der einfachen D-P2-Planung ab und ist eine UX-/Produktentscheidung nach Abstimmung mit Development.
|
||||
|
||||
---
|
||||
|
||||
## 2e. Subframe-Schutzregel
|
||||
|
||||
Subframe ist kein automatischer naechster Schritt.
|
||||
|
||||
Regeln:
|
||||
|
||||
- Kein bestehender Subframe-Screen wird ohne ausdrueckliche Freigabe bearbeitet.
|
||||
- Kein bestehender Subframe-Screen wird geloescht oder ueberschrieben.
|
||||
- Gleichnamige vorhandene Subframe-Screens sind nur Kontext, keine Arbeitsanweisung.
|
||||
- Neue Subframe-Screens werden nur angelegt, wenn David den konkreten Flow und den Subframe-Bau freigibt.
|
||||
- Bis zur Freigabe arbeitet der Assistant ausschliesslich in Obsidian: Paket-MD, Screen-MD, Canvas und Tracker.
|
||||
- Wenn Subframe spaeter genutzt wird, werden neue Screens eindeutig verlinkt und im Tracker dokumentiert.
|
||||
|
||||
---
|
||||
|
||||
## 2d. Screen Validation Gate
|
||||
|
||||
Bevor ein Screen in einen Flow eingebaut wird, muss er einzeln validiert werden.
|
||||
|
||||
### Validierungsfragen
|
||||
|
||||
- Ist das ein eigener Arbeitsmoment fuer den Nutzer?
|
||||
- Wird hier eine neue Struktur gebraucht?
|
||||
- Gibt es eine neue Entscheidung oder einen Risiko-Moment?
|
||||
- Reicht ein vorhandener Archetyp?
|
||||
- Ist es nur ein Zustand, Banner, Toast oder Inline-Hinweis?
|
||||
- Muss dieser Screen jetzt gebaut werden, oder reicht `Spaeter`?
|
||||
- Welche Daten und Aktionen sind wirklich noetig?
|
||||
|
||||
### Ergebnis
|
||||
|
||||
Jeder Screen-Kandidat bekommt eine klare Entscheidung:
|
||||
|
||||
| Entscheidung | Bedeutung |
|
||||
|---|---|
|
||||
| Bauen | wird als eigener Subframe-Frame gebaut |
|
||||
| Wiederverwenden | vorhandener Archetyp reicht |
|
||||
| Nur dokumentieren | im MD festhalten, kein Frame |
|
||||
| Spaeter | relevant, aber nicht fuer dieses Paket |
|
||||
| Raus | bewusst nicht Teil des Scopes |
|
||||
|
||||
Erst nach dieser Entscheidung darf der Screen in die finale Screen-Liste.
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
Manche Zustaende sind technisch nur Banner, Inline-Meldung oder Erfolgsscreen, muessen aber trotzdem gebaut werden.
|
||||
|
||||
Grund: Der Text, die Tonalitaet und die naechste Handlung sollen vom Design entschieden werden, nicht spaeter zufaellig vom Developer.
|
||||
|
||||
Ein Zustand wird eher gebaut, wenn:
|
||||
|
||||
- er sehr haeufig vorkommt
|
||||
- der Nutzer danach wissen muss, was als Naechstes passiert
|
||||
- Sicherheit, Vertrauen oder Zugang betroffen ist
|
||||
- der Text sensibel ist
|
||||
- die Meldung ein eigener mentaler Schritt im Flow ist
|
||||
- die Entscheidung nicht dem Developer ueberlassen werden soll
|
||||
|
||||
Beispiele:
|
||||
|
||||
- Magic-Link gesendet
|
||||
- Passwort geaendert
|
||||
- E-Mail nicht gefunden / neutraler Sicherheitstext
|
||||
- falsche Login-Daten
|
||||
- 2FA gesperrt
|
||||
- Link abgelaufen
|
||||
- Account gesperrt
|
||||
|
||||
Field-Validierungen wie "Passwort zu schwach", "Pflichtfeld fehlt" oder "ungueltige Telefonnummer" werden normalerweise nicht einzeln gebaut, wenn sie durch das Form/Input-Kit abgedeckt sind. Ausnahme: Der Zustand ist fachlich oder rechtlich wichtig.
|
||||
|
||||
---
|
||||
|
||||
## 3. Was gilt als Screen?
|
||||
|
||||
Ein Screen ist ein eigener Arbeitsmoment fuer den Nutzer.
|
||||
|
||||
Ein Screen liegt vor, wenn der Nutzer:
|
||||
|
||||
- auf einer eigenen Seite landet
|
||||
- eine Entscheidung trifft
|
||||
- Daten prueft
|
||||
- etwas erstellt oder bearbeitet
|
||||
- einen Flow startet, fortsetzt oder beendet
|
||||
- blockiert ist und eine Loesung braucht
|
||||
|
||||
Beispiele: Login, 2FA, Profil-Auswahl, Kontaktliste, Projekt-Detail, Flow-Editor, Loeschbestaetigung, Reassign-Workflow.
|
||||
|
||||
---
|
||||
|
||||
## 4. Wann wird ein Screen in Subframe gebaut?
|
||||
|
||||
Ein Screen wird gebaut, wenn mindestens eine Regel zutrifft:
|
||||
|
||||
1. **Neue Struktur**
|
||||
- Das Layout unterscheidet sich sichtbar von den bekannten Archetypen.
|
||||
|
||||
2. **Neue Aufgabe**
|
||||
- Der Nutzer macht hier etwas Eigenes, nicht nur dieselbe Liste mit anderen Daten.
|
||||
|
||||
3. **Neue Entscheidung**
|
||||
- Der Nutzer muss auswaehlen, bestaetigen, abbrechen, wechseln oder fortfahren.
|
||||
|
||||
4. **Risiko-Moment**
|
||||
- Loeschen, sperren, Rechte fehlen, Zahlung offen, Datenverlust, irreversible Aktion.
|
||||
|
||||
5. **Bespoke UI**
|
||||
- Kanban, Kalender, Plantafel, Flow-Editor, Form-Builder, Chat, Cmd+K, Public Booking.
|
||||
|
||||
6. **Auth oder Public**
|
||||
- Screens ohne normale App-Shell oder mit hoher Aussenwirkung.
|
||||
|
||||
---
|
||||
|
||||
## 5. Was wird nicht als eigener Subframe-Screen gebaut?
|
||||
|
||||
Diese Dinge werden meistens dokumentiert, aber nicht als eigener Frame gebaut:
|
||||
|
||||
- normaler Error-Banner auf einer bestehenden Seite
|
||||
- Toast nach Speichern, Loeschen oder Export
|
||||
- Field-Error in einem Standardformular
|
||||
- Empty-State einer normalen Liste, wenn A7 schon greift
|
||||
- Loading-Skeleton einer normalen Seite
|
||||
- Permission-State, wenn er nur Standard-A7 ist
|
||||
- zweite oder dritte Liste mit gleicher Struktur
|
||||
- Standard-Confirm-Modal ohne besondere Logik
|
||||
- Hover, Focus, Disabled, Pressed
|
||||
|
||||
Ausnahme: Wenn der Zustand die Bedienung oder Struktur veraendert, wird er gebaut.
|
||||
|
||||
Beispiel: Account gesperrt und alle Aktionen sind deaktiviert, nur "Zahlung aktualisieren" bleibt moeglich.
|
||||
|
||||
---
|
||||
|
||||
## 6. Banner, Toasts und Inline-Meldungen
|
||||
|
||||
Banner und Meldungen gehoeren immer zum Screen-Paket, auch wenn sie nicht als eigener Frame gebaut werden.
|
||||
|
||||
### Entscheidungs-Hierarchie
|
||||
|
||||
| UI-Form | Wann verwenden? | Typische Beispiele | Meist bauen? |
|
||||
|---|---|---|---|
|
||||
| Inline | betrifft genau ein Feld und kann direkt dort korrigiert werden | Pflichtfeld fehlt, E-Mail ungueltig, Passwort zu kurz, 2FA-Code falsch | nein |
|
||||
| Screen-Banner | betrifft den aktuellen Screen oder das aktuelle Formular | Login-Daten falsch, Captcha erforderlich, Formular konnte nicht gespeichert werden | nur wenn optisch/fachlich wichtig |
|
||||
| Globaler Banner | betrifft App/Shell oder Tenant/Account allgemein | Zahlung offen, Tenant gesperrt, Wartung | D0/App-Shell |
|
||||
| Toast | kurze Rueckmeldung nach Aktion, nicht blockierend | gespeichert, kopiert, Einladung versendet, Export gestartet | nein |
|
||||
| Modal/Dialog | Nutzer muss bestaetigen oder kurz entscheiden, bleibt aber im Kontext | loeschen bestaetigen, Rolle wechseln, Reassign bestaetigen | falls eigener Entscheidmoment |
|
||||
| Eigener Screen | Nutzer ist blockiert, in neuem Flow-Status oder braucht klare naechste Schritte | Link abgelaufen, Magic-Link gesendet, 2FA nicht verfuegbar, Account gesperrt | ja |
|
||||
|
||||
### Entscheidungsfragen
|
||||
|
||||
- Kann der Nutzer direkt im Feld korrigieren? Dann `Inline`.
|
||||
- Bleibt der Nutzer im selben Screen und kann dort weiterarbeiten? Dann `Banner`.
|
||||
- Ist es nur eine kurze Rueckmeldung nach einer Aktion? Dann `Toast`.
|
||||
- Muss der Nutzer bestaetigen oder eine kleine Entscheidung treffen, ohne den Screen zu verlassen? Dann `Modal/Dialog`.
|
||||
- Ist der Nutzer blockiert oder in einem neuen Flow-Zustand? Dann `eigener Screen`.
|
||||
- Ist Sicherheit, Zugang, Vertrauen oder rechtlicher Kontext betroffen? Eher `Banner` oder `Screen`, nicht Toast.
|
||||
- Darf die Meldung verschwinden? Wenn nein, kein Toast.
|
||||
|
||||
### Blockierende Error States
|
||||
|
||||
Blockierende Error States muessen im Screen-Paket genauer beschrieben werden.
|
||||
|
||||
Pflichtangaben:
|
||||
|
||||
- sichtbarer Titel oder Kernaussage
|
||||
- Ursache in Nutzersprache
|
||||
- naechste Primaeraktion
|
||||
- sekundare Aktion, z. B. zurueck oder Support/Admin kontaktieren
|
||||
- ob der Nutzer im aktuellen Screen bleiben kann oder einen eigenen Screen braucht
|
||||
|
||||
Beispiel:
|
||||
|
||||
| Ereignis | UI-Form | Bauen? | Inhalt |
|
||||
|---|---|---|---|
|
||||
| 2FA nicht verfuegbar | Eigener Screen | ja | 2FA kann nicht uebersprungen werden, Admin kontaktieren |
|
||||
| Reset-Link abgelaufen | Eigener Screen | ja | Link ist nicht mehr gueltig, neuen Link anfordern |
|
||||
| 2FA-Code falsch | Inline | nein | Code pruefen und erneut eingeben |
|
||||
|
||||
### Globale Banner
|
||||
|
||||
Gehoeren zur App-Shell/D0 und koennen ueberall auftauchen.
|
||||
|
||||
Beispiele:
|
||||
|
||||
- Zahlung offen
|
||||
- Tenant gesperrt
|
||||
- Account frozen
|
||||
- Loeschung vorgemerkt
|
||||
- Systemwartung
|
||||
|
||||
### Screen-Banner
|
||||
|
||||
Gehoeren direkt zum jeweiligen Screen.
|
||||
|
||||
Beispiele:
|
||||
|
||||
- Projekt ist abgeschlossen
|
||||
- Lead hat keine Weiterverarbeitungsfreigabe
|
||||
- Dieses Formular ist unveroeffentlicht
|
||||
- Verbindung zu Integration fehlgeschlagen
|
||||
|
||||
### Action-Feedback
|
||||
|
||||
Wird bei der jeweiligen Aktion dokumentiert.
|
||||
|
||||
Beispiele:
|
||||
|
||||
- gespeichert
|
||||
- geloescht
|
||||
- Export gestartet
|
||||
- Export fehlgeschlagen
|
||||
- Einladung versendet
|
||||
|
||||
Regel: Banner, Toast oder Inline-Meldung nur bauen, wenn sie den Screen optisch oder funktional wesentlich veraendert. Sonst im Markdown dokumentieren.
|
||||
|
||||
---
|
||||
|
||||
## 7. Subframe-Grid-Regeln
|
||||
|
||||
Subframe wird wie ein Flow-Board genutzt.
|
||||
|
||||
### Hauptflow
|
||||
|
||||
- Der Hauptflow laeuft von links nach rechts.
|
||||
- Jeder naechste Hauptschritt liegt eine Spalte weiter rechts.
|
||||
- Der Happy Path bleibt in einer horizontalen Linie.
|
||||
|
||||
### Varianten und Branches
|
||||
|
||||
- Eine Variante geht eine Reihe nach unten.
|
||||
- Zwei Varianten gehen zwei Reihen nach unten.
|
||||
- Drei Varianten gehen drei Reihen nach unten.
|
||||
- Jede Variante laeuft danach wieder nach rechts weiter.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
S01 Login -> S02 2FA -> S03 Profil-Auswahl -> S04 Dashboard
|
||||
|
|
||||
v
|
||||
B01 2FA gesperrt -> B02 Wiederherstellungscode
|
||||
```
|
||||
|
||||
### Wann wird ein neuer Flow gebaut?
|
||||
|
||||
Ein neuer Flow wird gebaut, wenn:
|
||||
|
||||
- die Variante mehr als 2-3 eigene Screens braucht
|
||||
- die Variante eine eigene Nutzeraufgabe ist
|
||||
- eine andere Rolle betroffen ist
|
||||
- die Grid-Ansicht unuebersichtlich wird
|
||||
- ein Screen sehr spezifisch oder bespoke wird
|
||||
- ein anderer Modulbereich beginnt
|
||||
|
||||
Regel: Lieber ein sauberer kleiner Flow als ein riesiges unlesbares Board.
|
||||
|
||||
### Canvas-Qualitaetsregeln
|
||||
|
||||
Jede Canvas-Datei muss vor Abschluss lesbar geprueft werden.
|
||||
|
||||
Pflichtregeln:
|
||||
|
||||
- Nodes gross genug anlegen, damit Titel und Inhalt lesbar bleiben.
|
||||
- Gruppen brauchen genug Padding; Gruppenlabels duerfen keine Nodes oder Kanten verdecken.
|
||||
- Kanten duerfen nicht durch andere Nodes laufen.
|
||||
- Lange Kantenlabels vermeiden.
|
||||
- Kantenlabels sind erlaubt, wenn genug Abstand zwischen den Karten ist.
|
||||
- Labels kurz halten, z. B. `Magic-Link`, `falsch`, `Captcha`, `gesperrt`, `2FA`, `ok`.
|
||||
- Wenn Labels ueber Nodes oder Gruppen liegen, Karten weiter auseinanderziehen statt die Labels direkt zu entfernen.
|
||||
- Keine direkte Kante bauen, wenn sie durch einen anderen wichtigen Schritt laeuft.
|
||||
- Outcomes duerfen als Text-Node dokumentiert werden, wenn sie keine eigenen Screens sind.
|
||||
- Nach dem Schreiben der Canvas muss JSON validiert werden.
|
||||
|
||||
Richtwerte:
|
||||
|
||||
| Element | Mindestgroesse |
|
||||
|---|---|
|
||||
| File-Node | 360 x 170 |
|
||||
| Text-Node | 420 x 170 |
|
||||
| Gruppe | mindestens 80 px Padding um Nodes |
|
||||
|
||||
---
|
||||
|
||||
## 8. Umsetzung und Status
|
||||
|
||||
### Umsetzung
|
||||
|
||||
`Umsetzung` beschreibt, was mit dem Screen oder Zustand gemacht wird.
|
||||
|
||||
| Wert | Bedeutung |
|
||||
|---|---|
|
||||
| Bauen | Eigener Screen/Frame in Subframe |
|
||||
| Wiederverwenden | vorhandenes Pattern/Archetyp reicht |
|
||||
| Nur dokumentieren | kein Frame, aber im Markdown beschreiben |
|
||||
| Spaeter | bewusst noch nicht jetzt |
|
||||
| Raus | nicht im Scope |
|
||||
|
||||
### Status
|
||||
|
||||
`Status` beschreibt, wie weit der Eintrag gerade ist.
|
||||
|
||||
| Wert | Bedeutung |
|
||||
|---|---|
|
||||
| Idee | noch nicht entschieden |
|
||||
| Brainstormed | grob besprochen |
|
||||
| Validiert | entschieden, kann gebaut/dokumentiert werden |
|
||||
| In Subframe | wird gerade gebaut |
|
||||
| Review | gebaut, muss geprueft werden |
|
||||
| Fertig | bereit zur Uebergabe |
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 2FA Verwalten
|
||||
id: M01
|
||||
screen: 2FA verwalten
|
||||
typ: Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von Profil Settings
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/606baf15-a4cc-468c-b196-c51441f8c6ed/edit"
|
||||
---
|
||||
|
||||
# M01 — 2FA verwalten
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer sieht den aktuellen 2FA-Status und kann 2FA einrichten, ein Device/Token hinzufuegen, ein bestehendes Device entfernen oder 2FA deaktivieren.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Modal / Security Management.
|
||||
|
||||
## Daten
|
||||
|
||||
- 2FA-Status: aktiv / nicht aktiv
|
||||
- Device-/Token-Liste, wenn aktiv
|
||||
- pro Device: Name, Typ `Authenticator-App`, hinzugefuegt am, optional zuletzt verwendet
|
||||
|
||||
## Aktionen
|
||||
|
||||
- 2FA einrichten, wenn nicht aktiv
|
||||
- Device/Token hinzufuegen
|
||||
- Device entfernen als Row-Action + Confirm
|
||||
- 2FA deaktivieren
|
||||
- Modal schliessen
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kurzer Hinweis, dass 2FA das Konto mit einem zweiten Faktor schuetzt.
|
||||
- Bei aktivem Status: Hinweis, dass Entfernen/Deaktivieren Sicherheitswirkung hat.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nach Device entfernen: kurzer Toast oder dokumentierte Benachrichtigung.
|
||||
- Nach 2FA-Aenderungen kann zusaetzlich eine Sicherheitsbenachrichtigung per E-Mail ausgelöst werden.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| 2FA nicht aktiv | Status + CTA `2FA einrichten` | Bauen |
|
||||
| 2FA aktiv | Device-Liste + Aktionen | Bauen |
|
||||
| Device entfernen | Row-Action + Confirm | Nur dokumentieren |
|
||||
| Letztes Device entfernen | blockieren oder zu M03 fuehren | Nur dokumentieren |
|
||||
| Laden | Aktionen werden gespeichert | Wiederverwenden |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nutzer ist eingeloggt.
|
||||
- Start kommt aus Profil Settings oder einem spaeteren Security-Kontext.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
`2FA-Code eingeben` ist kein eigener Screen. Codefelder erscheinen in M02 oder M03.
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 2FA Verwalten
|
||||
id: M02
|
||||
screen: Device/Token hinzufuegen
|
||||
typ: Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von M01
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/ec8c6a18-c0dd-498e-a79d-177b2a634d28/edit"
|
||||
---
|
||||
|
||||
# M02 — Device/Token hinzufuegen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer legt ein neues 2FA-Device bzw. einen neuen Authenticator-Token an und validiert ihn mit einem ersten TOTP-Code.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Modal / Authenticator Setup.
|
||||
|
||||
## Daten
|
||||
|
||||
- Device-Name, optional oder vorgeschlagen
|
||||
- QR-Code
|
||||
- manueller Secret-Key
|
||||
- 6-stelliger TOTP-Code
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Code bestaetigen
|
||||
- Secret/Key kopieren
|
||||
- abbrechen / zurueck zu M01
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kurz erklaeren, dass eine Authenticator-App benoetigt wird.
|
||||
- Device/Token wird erst gespeichert, wenn der eingegebene Code korrekt ist.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nach erfolgreicher Einrichtung: zurueck zu M01 mit aktualisierter Liste.
|
||||
- MFA-Aenderung kann per E-Mail/Toast dokumentiert werden.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Setup | QR + manueller Secret-Key + Codefeld | Bauen |
|
||||
| Laden | Code wird validiert | Wiederverwenden |
|
||||
| Code falsch | Inline-Fehler am Codefeld | Nur dokumentieren |
|
||||
| Code abgelaufen | Inline-Hinweis, neuen Code eingeben | Nur dokumentieren |
|
||||
| Setup fehlgeschlagen | technische Meldung ohne Rohfehler | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nutzer ist eingeloggt.
|
||||
- Start aus M01.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Das Pattern kann sich an `WF-P2 Set Password / S04 2FA einrichten` orientieren, besitzt hier aber Device-/Token-Kontext.
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 2FA Verwalten
|
||||
id: M03
|
||||
screen: 2FA deaktivieren
|
||||
typ: Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von M01
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/cfaa0e6a-6656-4363-bba7-7409b9c26bc9/edit"
|
||||
---
|
||||
|
||||
# M03 — 2FA deaktivieren
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer deaktiviert 2FA bewusst und bestaetigt die Aktion mit einem aktuellen 2FA-Code.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Confirm-Modal mit Inline-Reauth.
|
||||
|
||||
## Daten
|
||||
|
||||
- Warnhinweis zur Sicherheitsauswirkung
|
||||
- 2FA-Code
|
||||
- bestaetigende Checkbox oder Confirm-Text, falls noetig
|
||||
|
||||
## Aktionen
|
||||
|
||||
- 2FA deaktivieren
|
||||
- abbrechen / zurueck zu M01
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Hinweis: Nach der Deaktivierung ist fuer den Account kein zweiter Faktor mehr aktiv.
|
||||
- Keine technische Anleitung zum Umgehen von 2FA.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nach erfolgreicher Deaktivierung: zurueck zu M01 mit Status `2FA nicht aktiv`.
|
||||
- MFA-Aenderung kann per E-Mail/Toast dokumentiert werden.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Confirm | Warnung + 2FA-Code + Deaktivieren-Action | Bauen |
|
||||
| Laden | Deaktivierung wird gespeichert | Wiederverwenden |
|
||||
| Code falsch | Inline-Fehler am Codefeld | Nur dokumentieren |
|
||||
| Zu viele Versuche | temporaerer Blocker/Retry spaeter | Nur dokumentieren |
|
||||
| Technischer Fehler | Deaktivierung fehlgeschlagen | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nutzer ist eingeloggt.
|
||||
- 2FA ist aktiv.
|
||||
- Start aus M01.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Code-Eingabe und Confirm bleiben in diesem Modal. Es gibt keinen eigenen `2FA bestaetigen`-Flow.
|
||||
@@ -0,0 +1,21 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":1900,"height":420,"label":"Hauptflow"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":1700,"height":360,"label":"Dokumentierte Zustaende"},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens/M01 2FA verwalten.md","x":0,"y":0,"width":420,"height":200},
|
||||
{"id":"m02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens/M02 Device Token hinzufuegen.md","x":640,"y":0,"width":420,"height":200},
|
||||
{"id":"m03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens/M03 2FA deaktivieren.md","x":1280,"y":0,"width":420,"height":200},
|
||||
{"id":"note-inline","type":"text","text":"# Inline-Zustaende\n\n2FA-Code falsch/abgelaufen bleibt Inline in M02/M03.\n\nKein eigener `2FA bestaetigen`-Flow.","x":0,"y":680,"width":420,"height":200},
|
||||
{"id":"note-remove","type":"text","text":"# Device entfernen\n\nRow-Action + Confirm in M01.\n\nLetztes Device nicht still entfernen: blockieren oder zu M03 leiten.","x":540,"y":680,"width":420,"height":220},
|
||||
{"id":"note-notify","type":"text","text":"# MFA-Aenderung\n\nNach Setup, Remove oder Disable Security-Benachrichtigung dokumentieren: E-Mail und/oder Toast.\n\nKein eigener Screen.","x":1080,"y":680,"width":420,"height":220}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-m01-m02","fromNode":"m01","fromSide":"right","toNode":"m02","toSide":"left","label":"hinzufuegen"},
|
||||
{"id":"edge-m01-m03","fromNode":"m01","fromSide":"right","toNode":"m03","toSide":"left","label":"deaktivieren"},
|
||||
{"id":"edge-m02-m01","fromNode":"m02","fromSide":"bottom","toNode":"m01","toSide":"bottom","label":"validiert"},
|
||||
{"id":"edge-m03-m01","fromNode":"m03","fromSide":"bottom","toNode":"m01","toSide":"bottom","label":"deaktiviert"},
|
||||
{"id":"edge-m01-remove","fromNode":"m01","fromSide":"bottom","toNode":"note-remove","toSide":"top","label":"Device entfernen"},
|
||||
{"id":"edge-m02-inline","fromNode":"m02","fromSide":"bottom","toNode":"note-inline","toSide":"top","label":"Codefehler"},
|
||||
{"id":"edge-m03-inline","fromNode":"m03","fromSide":"bottom","toNode":"note-inline","toSide":"top","label":"Codefehler"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,201 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 2FA Verwalten
|
||||
typ: Auth-Core Modal Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/4de27a18-0e2f-43de-b39b-01a94b0c93b8/edit"
|
||||
canvas: WF-P2 2FA Verwalten.canvas
|
||||
---
|
||||
|
||||
# WF-P2 2FA Verwalten
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/4de27a18-0e2f-43de-b39b-01a94b0c93b8/edit
|
||||
Canvas: [[WF-P2 2FA Verwalten.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
`2FA Verwalten` ist ein eigener wiederverwendbarer Sicherheitsflow.
|
||||
|
||||
Der Flow wird aus Profil Settings getriggert, bleibt aber getrennt, damit 2FA spaeter auch aus anderen Sicherheitskontexten gestartet werden kann. Die UI ist als Modal-/Dialogsequenz gedacht.
|
||||
|
||||
Wichtig: `2FA-Code eingeben` ist hier kein eigener Flow. Code-Eingaben sind Inline-Zustaende in den jeweiligen Modals, z. B. bei Device hinzufuegen oder 2FA deaktivieren.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 / Auth-Core |
|
||||
| Was soll der Nutzer am Ende schaffen? | 2FA einrichten, vorhandene 2FA-Devices sehen, neue Devices hinzufuegen, Devices entfernen oder 2FA deaktivieren |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | eigener Sicherheitsflow als Modal-/Dialogsequenz |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, Profil-und-Sicherheit-Entscheidung, Set-Password-2FA-Pattern |
|
||||
| Was ist sicher im Scope? | 2FA Status, 2FA aktivieren/einrichten, Device hinzufuegen, Device entfernen, 2FA deaktivieren mit Code + Confirm |
|
||||
| Was ist sicher nicht im Scope? | Profil bearbeiten, Passwort aendern, Session-Verwaltung, Trust-Device-Liste als eigene Seite |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | nein; gleicher Self-Service-Flow fuer eingeloggte Nutzer |
|
||||
| Welche Annahmen sind noch unsicher? | ob v1 mehrere Authenticator-Devices wirklich unterstuetzt oder die UI erstmal nur darauf vorbereitet wird |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 / Auth-Core |
|
||||
| Nutzerrolle | eingeloggter Nutzer |
|
||||
| Admin-Variante | keine eigene UI |
|
||||
| Normale Rolle | gleicher Flow |
|
||||
| Startpunkt | Trigger aus Profil Settings oder spaeter anderer Sicherheitskontext |
|
||||
| Ziel | 2FA-Status sicher verwalten |
|
||||
| Haupt-Archetyp | A5 Modal/Wizard + A4 Auth Form |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | aktive Sessions, Trust-Device-Liste als eigene Security-Seite, Passwort aendern |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Wie viel eigene Struktur braucht 2FA-Verwaltung, ohne aus einfachen Code-Eingaben eigene Flows zu machen?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | 2FA komplett im Profil-Screen einbetten | wenig Modals | Profil wird sicherheitslastig und schlechter wiederverwendbar | raus |
|
||||
| B | Eigener 2FA-Verwalten-Flow, aber Code-Eingaben bleiben Inline-Zustaende | wiederverwendbar, schlank, klarer Security-Kontext | braucht saubere Modal-Zustaende | genommen |
|
||||
| C | Jede 2FA-Bestaetigung als eigener Flow | sehr formal | zu kompliziert fuer diesen Scope | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| 2FA-Verwaltung ist eigener Flow | genommen | Profil ist nur Trigger |
|
||||
| UI als Modal-/Dialogsequenz | genommen | bleibt innerhalb der App-Shell |
|
||||
| 2FA-Code-Eingaben sind keine eigenen Flows | genommen | Codefelder liegen im jeweiligen Modal |
|
||||
| Inaktiver und aktiver Status liegen in demselben Start-Modal | genommen | spart eigenen Empty-State-Screen |
|
||||
| Device/Token hinzufuegen ist ein eigener Modal-Step | genommen | QR/Secret + Code brauchen eigenen Arbeitsmoment |
|
||||
| Device entfernen ist kein eigener Screen | genommen | Row-Action + Confirm reicht |
|
||||
| Letztes Device nicht still entfernen | genommen | blockieren oder zu 2FA deaktivieren fuehren |
|
||||
| 2FA deaktivieren ist eigener Confirm-Modal | genommen | hoher Risiko-Branch, aber Code + Confirm im selben Modal |
|
||||
| MFA-Aenderung benachrichtigen | genommen | E-Mail/Toast nur dokumentieren, kein eigener Screen |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer klickt in Profil Settings auf 2FA verwalten.
|
||||
2. Modal `2FA verwalten` oeffnet sich.
|
||||
3. Wenn 2FA nicht aktiv ist, sieht der Nutzer den Status und kann 2FA einrichten.
|
||||
4. Wenn 2FA aktiv ist, sieht der Nutzer vorhandene Devices und Aktionen.
|
||||
5. Nutzer fuegt ein Device hinzu oder entfernt ein Device.
|
||||
6. Nutzer kann 2FA deaktivieren; dafuer gibt er den 2FA-Code im Deaktivieren-Modal ein und bestaetigt bewusst die Deaktivierung.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- 2FA ist nicht aktiv: Start-Modal zeigt CTA `2FA einrichten`.
|
||||
- 2FA ist aktiv: Start-Modal zeigt Device-Liste und Aktionen.
|
||||
- Neues Device hinzufuegen: QR/Secret + Code im Setup-Modal.
|
||||
- Device entfernen: Row-Action mit kleiner Confirm-Abfrage.
|
||||
- Letztes Device entfernen: blockiert oder fuehrt zu `2FA deaktivieren`.
|
||||
- 2FA deaktivieren: Code + Confirm im selben Modal.
|
||||
- Code ist falsch: Inline-Fehler, kein eigener Screen.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- falscher 2FA-Code
|
||||
- letztes Device entfernen
|
||||
- Setup-Code abgelaufen/ungueltig
|
||||
- technische Setup-/Disable-Fehler
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| 2FA nicht aktiv | Zustand in M01 | nein | nein | CTA zum Einrichten |
|
||||
| 2FA aktiv | Zustand in M01 | nein | nein | Device-Liste + Aktionen |
|
||||
| neues Device hinzufuegen | Modal-Step M02 | ja | pruefen | QR/Secret + Code |
|
||||
| Device entfernen | Row-Action + Confirm | teilweise | nein | wenn nicht letztes Device |
|
||||
| letztes Device entfernen | Inline/Confirm-Hinweis | ja | nein | Nutzer soll 2FA deaktivieren statt letztes Device still entfernen |
|
||||
| 2FA deaktivieren | Modal M03 | ja | pruefen | Code + bewusster Confirm im selben Modal |
|
||||
| 2FA-Code falsch | Inline im Modal | ja | nein | korrigierbar |
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| 2FA verwalten | Start-Modal fuer aktiven/inaktiven Status | Bauen |
|
||||
| 2FA einrichten / Device hinzufuegen | QR/Secret + Code | Bauen |
|
||||
| 2FA deaktivieren | sicherheitskritischer Branch | Bauen |
|
||||
| Device entfernen | kleinere Aktion | Nur dokumentieren |
|
||||
| 2FA-Code falsch | Inline-Zustand | Nur dokumentieren |
|
||||
| Letztes Device entfernen blockiert | Inline-/Confirm-Zustand | Nur dokumentieren |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| M01 | 2FA verwalten | ja | ja, eigener Sicherheitsstart | Bauen | Status, Device-Liste, Einstieg zu Aktionen |
|
||||
| M02 | Device/Token hinzufuegen | ja | ja, QR/Secret + Code | Bauen | eigener Setup-Arbeitsmoment |
|
||||
| M03 | 2FA deaktivieren | ja | ja, hohes Risiko | Bauen | Code + Confirm im selben Modal |
|
||||
| D01 | Device entfernen | teilweise | ja, Zugriff wird entzogen | Nur dokumentieren | Row-Action + Confirm reicht |
|
||||
| D02 | 2FA-Code falsch | nein | nein | Nur dokumentieren | Inline-Fehler |
|
||||
| D03 | Letztes Device entfernen | nein | ja | Nur dokumentieren | blockieren oder zu 2FA deaktivieren fuehren |
|
||||
| D04 | MFA-Aenderung Benachrichtigung | nein | ja, Security Audit | Nur dokumentieren | E-Mail/Toast nach Setup, Remove, Disable |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| M01 | 2FA verwalten | Modal | Bauen | von Profil Settings | Validiert |
|
||||
| M02 | Device/Token hinzufuegen | Modal | Bauen | von M01 | Validiert |
|
||||
| M03 | 2FA deaktivieren | Modal | Bauen | von M01 | Validiert |
|
||||
| D01 | Device entfernen | Row-Action/Confirm | Nur dokumentieren | in M01 | Validiert |
|
||||
| D02 | 2FA-Code falsch/abgelaufen | Inline | Nur dokumentieren | in M02/M03 | Validiert |
|
||||
| D03 | Letztes Device entfernen | Inline/Confirm | Nur dokumentieren | in M01 | Validiert |
|
||||
| D04 | MFA-Aenderung Benachrichtigung | E-Mail/Toast | Nur dokumentieren | nach Setup/Remove/Disable | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
```text
|
||||
Profil Settings -> M01 2FA verwalten
|
||||
M01 -> M02 Device/Token hinzufuegen
|
||||
M01 -> M03 2FA deaktivieren
|
||||
M01 -> Device entfernen (dokumentierte Row-Action)
|
||||
M02/M03 -> 2FA-Code falsch (Inline)
|
||||
M02/M03/Device entfernen -> MFA-Aenderung Benachrichtigung (dokumentiert)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
| ID | Datei |
|
||||
|---|---|
|
||||
| M01 | [[Screens/M01 2FA verwalten.md]] |
|
||||
| M02 | [[Screens/M02 Device Token hinzufuegen.md]] |
|
||||
| M03 | [[Screens/M03 2FA deaktivieren.md]] |
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Eigenes Paket ist angelegt.
|
||||
- [x] Profil ist nur Trigger, nicht Besitzer des Flows.
|
||||
- [x] 2FA-Code-Bestaetigung ist kein eigener Flow.
|
||||
- [x] 2FA deaktivieren verlangt Code + Confirm im selben Modal.
|
||||
- [x] David hat die Kandidaten validiert.
|
||||
- [ ] Subframe-Link ist eingetragen.
|
||||
+65
@@ -0,0 +1,65 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: D01
|
||||
screen: Rollen-Dropdown in Mitarbeiterliste
|
||||
typ: Inline-Zustand
|
||||
umsetzung: Nur dokumentieren
|
||||
status: In Subframe
|
||||
route: in S01
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/80f691a7-e8a9-4502-be74-69795066e105/edit"
|
||||
---
|
||||
|
||||
# D01 - Rollen-Dropdown in Mitarbeiterliste
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Admin kann die Rolle eines Mitarbeiters direkt in der Liste aendern und bei Bedarf zur Rollenverwaltung springen.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Inline Select / Dropdown in Tabelle.
|
||||
|
||||
## Daten
|
||||
|
||||
- aktuelle Rolle(n) des Mitarbeiters
|
||||
- verfuegbare Rollen
|
||||
- Rolle `Admin`
|
||||
- Rollen, die wegen Policy nicht gesetzt oder entfernt werden duerfen
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Rolle auswaehlen
|
||||
- `Rollen und Berechtigungen bearbeiten` -> S02
|
||||
- Dropdown schliessen
|
||||
|
||||
## Verhalten
|
||||
|
||||
- Dropdown zeigt aktuelle Rolle und verfuegbare Rollen.
|
||||
- Unterhalb der Rollen steht ein Eintrag `Rollen und Berechtigungen bearbeiten`.
|
||||
- Dieser Eintrag navigiert zu `Settings -> Mitarbeiter`, Tab `Rollen und Berechtigungen`.
|
||||
- Wenn ein Rollenwechsel den letzten Admin entfernen wuerde, wird V01 genutzt.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Standard | Rollen auswahlen | Nur dokumentieren |
|
||||
| Speichern | Rollenwechsel wird gespeichert | Wiederverwenden |
|
||||
| Keine Berechtigung | Dropdown disabled oder nicht sichtbar | Nur dokumentieren |
|
||||
| Letzter Admin | Rollenwechsel blockiert | V01 |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Rollenwechsel braucht Rollen-/Mitarbeiter-Berechtigung.
|
||||
- Technische Admin-Schutzregeln koennen Rollenwechsel blockieren.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Kein separates Rollen-Modal aus der Mitarbeiterliste. Rollen bearbeiten passiert in S02/M02.
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: D03
|
||||
screen: Rolle in Nutzung blockiert
|
||||
typ: Admin Blocker
|
||||
umsetzung: Nur dokumentieren
|
||||
status: In Subframe
|
||||
route: von S02/M02
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/99f96d31-4cb5-4d7c-a252-3f8bef9f1b59/edit"
|
||||
---
|
||||
|
||||
# D03 - Rolle in Nutzung blockiert
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Admin versteht, warum eine Rolle nicht geloescht werden kann.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Kleines Blocker-Modal / Inline-Blocker.
|
||||
|
||||
## Daten
|
||||
|
||||
- Rolle
|
||||
- Anzahl zugewiesener Mitarbeiter
|
||||
|
||||
## Aktionen
|
||||
|
||||
- `Verstanden`
|
||||
- Modal schliessen
|
||||
|
||||
## Inhalt / Copy-Richtung
|
||||
|
||||
Headline: `Rolle kann nicht geloescht werden`
|
||||
|
||||
Text: `Diese Rolle kann nicht geloescht werden, solange Mitarbeiter zugewiesen sind. Weise die Mitarbeiter zuerst manuell einer anderen Rolle zu.`
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Rolle in Nutzung | Loeschen wird blockiert | Nur dokumentieren |
|
||||
| Rolle ohne Mitglieder | Loeschen ist moeglich | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Loeschen ist nur fuer berechtigte Admins sichtbar.
|
||||
- Rolle `Admin` hat keine Loeschen-Aktion.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Ersatzrolle waehlen und Bulk-Reassign sind Backlog/V2.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: M01
|
||||
screen: Mitarbeiter einladen
|
||||
typ: Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von S01
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/0338fed6-2624-4e92-9d42-0b959fafe8c2/edit"
|
||||
---
|
||||
|
||||
# M01 - Mitarbeiter einladen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Admin laedt einen neuen Mitarbeiter in den Workspace ein und weist direkt die passende Rolle zu.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Modal / Invite Form.
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail-Adresse, Pflichtfeld
|
||||
- optional Name
|
||||
- optional Abteilung
|
||||
- Rolle, Pflichtauswahl mit Default/Seed-Rollen
|
||||
- aktueller Workspace
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Einladung senden
|
||||
- abbrechen / Modal schliessen
|
||||
- Rolle auswaehlen
|
||||
|
||||
## Layout / Inhalt
|
||||
|
||||
1. Headline `Mitarbeiter einladen`.
|
||||
2. Hinweis, dass die Einladung fuer den aktuellen Workspace gilt.
|
||||
3. Felder: E-Mail, Name optional, Abteilung optional, Rolle.
|
||||
4. Aktionen: `Einladung senden`, `Abbrechen`.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Erfolg: Toast `Einladung wurde gesendet`.
|
||||
- Danach zurueck zu S01; Nutzer erscheint mit Status `Eingeladen`.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | Pflichtfelder leer | Bauen |
|
||||
| Validierungsfehler | E-Mail fehlt/ungueltig, Rolle fehlt | Bauen |
|
||||
| Einladung existiert | Hinweis mit Option erneut senden | Nur dokumentieren |
|
||||
| Laden | Einladung wird gesendet | Wiederverwenden |
|
||||
| Fehler | Einladung konnte nicht gesendet werden | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Admin oder Rolle mit Mitarbeiter-einladen-Berechtigung.
|
||||
|
||||
## Subframe
|
||||
|
||||
- Umsetzung als echtes Subframe-Modal mit `DialogLayout`-Root, nicht als nachgebautes Overlay ueber einer duplizierten Mitarbeiterliste.
|
||||
|
||||
## Notizen
|
||||
|
||||
Kein eigener Fullscreen. Der Invite bleibt ein kompaktes Modal aus der Mitarbeiterliste.
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: M02
|
||||
screen: Rolle erstellen/bearbeiten
|
||||
typ: Grosses Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von S02
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/3d51deee-0d41-456f-a507-ccfc284e6e0a/edit"
|
||||
---
|
||||
|
||||
# M02 - Rolle erstellen/bearbeiten
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Admin erstellt eine eigene Rolle oder bearbeitet eine vorhandene/Seed-Rolle und sieht, wie Berechtigungen pro Bereich gesetzt werden.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Grosses Modal / Role Editor.
|
||||
|
||||
## Daten
|
||||
|
||||
- Rollenname
|
||||
- Beschreibung
|
||||
- Typ: Systemrolle, Seed-Rolle, Eigene Rolle
|
||||
- optional Vorlage
|
||||
- Permission-Bereiche als Arbeitsgeruest
|
||||
- konkrete Permission-Zeilen nach Beispielmuster
|
||||
|
||||
## Aktionen
|
||||
|
||||
- speichern
|
||||
- abbrechen / Modal schliessen
|
||||
- Rolle loeschen, wenn erlaubt
|
||||
- Permission-Auswahl aendern
|
||||
- Permission suchen
|
||||
- Sidebar-Bereich oeffnen
|
||||
|
||||
## Layout / Inhalt
|
||||
|
||||
1. Grosses Modal ueber S02, mit Schliessen-Icon.
|
||||
2. Kopfbereich mit Rollenname, Beschreibung und optional Vorlage.
|
||||
3. Globale Suche ueber alle Permissions.
|
||||
4. Linke Sidebar mit Bereichen: Ueberblick, Mitarbeiter, Rollen und Berechtigungen, Workspace Settings, Abrechnung, Audit & Sicherheit, Integrationen/API, CRM/Kunden, Leads/Vertrieb, Projekte/Auftraege, Aufgaben/Dateien, Kommunikation/Support.
|
||||
5. Startzustand `Ueberblick`: scrollbare Liste aller Bereiche und Permissions.
|
||||
6. Footer mit `Speichern` und `Abbrechen`.
|
||||
|
||||
## Permission-Zeilenmuster
|
||||
|
||||
Eine Permission wird konkret vorgebaut, damit das Muster klar ist:
|
||||
|
||||
| Element | Inhalt |
|
||||
|---|---|
|
||||
| Ueberschrift | `Mitarbeiter ansehen` |
|
||||
| Beschreibung | `Darf Mitarbeiterliste und Mitarbeiterprofile im Workspace lesen.` |
|
||||
| Control | Segmented Control `Aus`, `Read-only`, `Bearbeiten` |
|
||||
|
||||
Verhalten:
|
||||
|
||||
- `Aus`: kein Zugriff.
|
||||
- `Read-only`: lesen, aber nicht bearbeiten.
|
||||
- `Bearbeiten`: lesen und aendern.
|
||||
- Binaere Permissions koennen spaeter als einfacher Toggle `Aus/An` umgesetzt werden.
|
||||
- Weitere Permissions werden Development-seitig nach diesem Muster ergaenzt.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Neue Rolle | leere Felder + Permission-Auswahl | Bauen |
|
||||
| Rolle bearbeiten | vorhandene Werte vorausgefuellt | Bauen |
|
||||
| Seed-Rolle bearbeiten | Seed-Rolle ist editierbar | Bauen |
|
||||
| Admin-Rolle | kritische Felder/Loeschen geschuetzt | Nur dokumentieren |
|
||||
| Rollenname existiert | Inline-Fehler am Namen | Nur dokumentieren |
|
||||
| Rolle in Nutzung loeschen | Loeschen blockiert | D03 |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nur Admins oder Rollen mit Rollen-/Berechtigungsverwaltung.
|
||||
- Systemrolle `Admin` darf nicht geloescht werden.
|
||||
|
||||
## Subframe
|
||||
|
||||
- Umsetzung als echtes grosses Subframe-Modal mit `DialogLayout` + `Dialog.Content`, nicht als freie Page-Shell.
|
||||
|
||||
## Notizen
|
||||
|
||||
Die Permission-Bundles sind fuer v1 ein Arbeitsgeruest, kein finaler Rechtekatalog. Wichtig ist das UI-Muster und der Einstieg fuer Development.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: M03
|
||||
screen: Mitarbeiter deaktivieren
|
||||
typ: Confirm Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von S01
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/11e3f3dc-451b-4abb-aedf-3aad63704c51/edit"
|
||||
---
|
||||
|
||||
# M03 - Mitarbeiter deaktivieren
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Admin bestaetigt bewusst, dass ein Mitarbeiter keinen Zugriff mehr auf den Workspace haben soll.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Confirm-Modal.
|
||||
|
||||
## Daten
|
||||
|
||||
- Name des Mitarbeiters
|
||||
- E-Mail des Mitarbeiters
|
||||
- aktueller Status
|
||||
- ob der Mitarbeiter letzter Admin ist
|
||||
|
||||
## Aktionen
|
||||
|
||||
- `Deaktivieren`
|
||||
- `Abbrechen`
|
||||
- Modal schliessen
|
||||
|
||||
## Layout / Inhalt
|
||||
|
||||
1. Headline `Mitarbeiter deaktivieren?`
|
||||
2. Name und E-Mail des Mitarbeiters.
|
||||
3. Kurzer Hinweis: Nach der Deaktivierung hat der Mitarbeiter keinen Zugriff mehr auf den Workspace.
|
||||
4. Hinweis: Der Mitarbeiter bleibt in der Liste mit Status `Deaktiviert` sichtbar.
|
||||
5. Aktionen: Danger-Button `Deaktivieren`, sekundar `Abbrechen`.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Erfolg: Toast `Mitarbeiter wurde deaktiviert`.
|
||||
- S01 zeigt danach Status `Deaktiviert`.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Confirm | kurze Sicherheitsfrage | Bauen |
|
||||
| Laden | Deaktivierung wird gespeichert | Wiederverwenden |
|
||||
| Letzter Admin | Aktion wird blockiert | V01 |
|
||||
| Fehler | Deaktivierung fehlgeschlagen | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nur Admins oder Rollen mit Mitarbeiter-deaktivieren-Berechtigung.
|
||||
- Letzter Admin darf nicht deaktiviert werden.
|
||||
|
||||
## Subframe
|
||||
|
||||
- Umsetzung als echtes Subframe-Confirm-Modal mit `DialogLayout`-Root, ohne duplizierte Mitarbeiterliste oder manuell nachgebauten Overlay-Hintergrund.
|
||||
|
||||
## Notizen
|
||||
|
||||
Kein Reassign in v1. Offene Verantwortlichkeiten bleiben Backlog/V2.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: S01
|
||||
screen: Mitarbeiterliste
|
||||
typ: Admin List
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: Settings -> Mitarbeiter, Tab Mitarbeiter
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/a9571d72-15e0-4897-968b-1f700ee4bfbc/edit"
|
||||
---
|
||||
|
||||
# S01 - Mitarbeiterliste
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Admin findet Mitarbeiter schnell, prueft Rollen/Status und startet Einladung, Rollenaenderung oder Deaktivierung.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A2 List + A6 Settings.
|
||||
|
||||
## Daten
|
||||
|
||||
- Mitarbeiter: Avatar, Name, E-Mail, Telefonnummer optional
|
||||
- Abteilung
|
||||
- aktuelle Rolle(n)
|
||||
- Status: Aktiv, Eingeladen, Deaktiviert
|
||||
- 2FA-Status
|
||||
- verfuegbare Rollen fuer das Rollen-Dropdown
|
||||
|
||||
## Aktionen
|
||||
|
||||
- `Mitarbeiter einladen` -> M01
|
||||
- Rolle direkt in der Tabellenzeile aendern -> D01
|
||||
- `Rollen und Berechtigungen bearbeiten` -> S02
|
||||
- Zeilenaktion `Deaktivieren` -> M03
|
||||
- ggf. `Einladung erneut senden`
|
||||
|
||||
## Layout / Inhalt
|
||||
|
||||
1. Header `Mitarbeiter` mit primaerem CTA `Mitarbeiter einladen`.
|
||||
2. Tabs innerhalb `Settings -> Mitarbeiter`: `Mitarbeiter`, `Rollen und Berechtigungen`.
|
||||
3. Toolbar mit Suche nach Name, E-Mail und Telefonnummer.
|
||||
4. Filter: Rolle, Abteilung, Status, 2FA.
|
||||
5. Tabelle mit Spalten: Mitarbeiter, Abteilung, Rolle, Status, 2FA, Aktionen.
|
||||
6. Aktionen rechts als 3-Punkte-Menue.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Einladung gesendet: Toast.
|
||||
- Rolle geaendert: kurzer Toast oder Inline-Saved-State.
|
||||
- Mitarbeiter deaktiviert: Toast nach M03.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Standard | Mitarbeiterliste mit Suche, Filtern und Tabelle | Bauen |
|
||||
| Keine Treffer | Suche/Filter ergibt keine Ergebnisse | Bauen |
|
||||
| Eingeladener Nutzer | Status `Eingeladen`, ggf. `Einladung erneut senden` | Nur dokumentieren |
|
||||
| Deaktivierter Nutzer | Status `Deaktiviert`, bleibt sichtbar | Bauen |
|
||||
| Letzter Admin betroffen | kritische Aktion blockieren | V01 |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nur Admins oder Rollen mit entsprechender Mitarbeiter-/RBAC-Berechtigung.
|
||||
- Normale Nutzer sehen diesen Settings-Bereich nicht.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Reassign offener Aufgaben ist nicht Teil von v1. Deaktivieren bleibt ein kleiner Confirm-Flow.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: S02
|
||||
screen: Rollen und Berechtigungen
|
||||
typ: Settings Subpage
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: Settings -> Mitarbeiter, Tab Rollen und Berechtigungen
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/87c24709-4f22-4181-8543-e21ff169c4d5/edit"
|
||||
---
|
||||
|
||||
# S02 - Rollen und Berechtigungen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Admin verwaltet Systemrolle, Seed-Rollen und eigene Rollen in einer kompakten Rollen-Tabelle.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A2 List + A6 Settings.
|
||||
|
||||
## Daten
|
||||
|
||||
- Rollenliste
|
||||
- Typ: Systemrolle, Seed-Rolle, Eigene Rolle
|
||||
- Beschreibung
|
||||
- Mitgliederanzahl / Avatar-Stack
|
||||
- Status: Aktiv, Pruefen
|
||||
- Permission-Bundles als Arbeitsgeruest
|
||||
|
||||
## Aktionen
|
||||
|
||||
- `Rolle anlegen` -> M02
|
||||
- Zeilenaktion `Bearbeiten` -> M02
|
||||
- Zeilenaktion `Duplizieren` -> M02 mit kopierter Rolle
|
||||
- Zeilenaktion `Loeschen`
|
||||
- bei Rolle in Nutzung -> D03
|
||||
|
||||
## Layout / Inhalt
|
||||
|
||||
1. Header `Rollen und Berechtigungen` mit CTA `Rolle anlegen`.
|
||||
2. Toolbar mit Suche nach Rollenname und Beschreibung.
|
||||
3. Filter: Typ, Permission-Bundle, In Nutzung.
|
||||
4. Tabelle mit Spalten: Rolle, Beschreibung, Typ, Mitglieder, Status, Aktionen.
|
||||
5. Aktionen rechts pro Zeile als 3-Punkte-Menue.
|
||||
6. Nur eine sichtbare Systemrolle: `Admin`.
|
||||
|
||||
## Rollen / Beispiele
|
||||
|
||||
- Admin als einzige Systemrolle.
|
||||
- Seed-Rollen: Geschaeftsfuehrer, Projektleiter, Verwaltung, Vertriebler, Kundensupporter, Monteur.
|
||||
- Eigene Rollen koennen frei benannt werden.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Standard | Rollen-Tabelle mit Suche/Filtern | Bauen |
|
||||
| Keine Treffer | Suche/Filter ohne Ergebnis | Bauen |
|
||||
| Admin-Rolle | Systemrolle ohne Loeschen-Aktion | Bauen |
|
||||
| Rolle ohne Mitglieder loeschen | Loeschen moeglich mit Confirm/Pattern | Nur dokumentieren |
|
||||
| Rolle in Nutzung | Loeschen blockiert | D03 |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nur Admins oder Rollen mit Rollen-/Berechtigungsverwaltung.
|
||||
- Normale Nutzer sehen diesen Tab nicht.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Die Tabelle orientiert sich am validierten Referenzbild: klare Settings-Sidebar, Rollenliste, Mitglieder-Spalte, Status, 3-Punkte-Menue.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
id: V01
|
||||
screen: Letzter Admin blockiert
|
||||
typ: Admin Blocker
|
||||
umsetzung: Nur dokumentieren
|
||||
status: In Subframe
|
||||
route: von S01/M03/Rollenwechsel
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/3e05bfb3-3842-4008-964e-f4c68dea0d9e/edit"
|
||||
---
|
||||
|
||||
# V01 - Letzter Admin blockiert
|
||||
|
||||
## Ziel
|
||||
|
||||
Das System verhindert, dass ein Workspace ohne Admin bleibt.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Blocker-State im jeweiligen Kontext.
|
||||
|
||||
## Ausloeser
|
||||
|
||||
- letzter Admin soll deaktiviert werden
|
||||
- letzter Admin soll seine Admin-Rolle verlieren
|
||||
- Rollenwechsel wuerde dazu fuehren, dass kein Admin mehr existiert
|
||||
|
||||
## Aktionen
|
||||
|
||||
- `Verstanden`
|
||||
- ggf. weiteren Admin bestimmen, wenn spaeter vorhanden
|
||||
- abbrechen
|
||||
|
||||
## Inhalt / Copy-Richtung
|
||||
|
||||
Headline: `Letzter Admin kann nicht entfernt werden`
|
||||
|
||||
Text: `Dieser Workspace braucht mindestens einen Admin. Weise zuerst einem anderen Mitarbeiter die Admin-Rolle zu.`
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Deaktivieren blockiert | M03 kann nicht ausgefuehrt werden | Nur dokumentieren |
|
||||
| Rollenwechsel blockiert | D01 speichert nicht | Nur dokumentieren |
|
||||
| Erweiterter Admin-Schutz | genauere Policy spaeter | Backlog |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Greift unabhaengig davon, ob der ausloesende Nutzer grundsaetzlich Adminrechte hat.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Der konkrete Policy-Feinschliff fuer Selbst-Deaktivierung und kritische Rollenwechsel bleibt Backlog/V2.
|
||||
@@ -0,0 +1,32 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-120,"y":-680,"width":4000,"height":1440,"label":"Admin RBAC Hauptflow"},
|
||||
{"id":"group-notes","type":"group","x":-120,"y":900,"width":4000,"height":430,"label":"Dokumentierte Zustaende und Backlog"},
|
||||
{"id":"d01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D01 Rollen-Dropdown in Mitarbeiterliste.md","x":780,"y":440,"width":440,"height":230},
|
||||
{"id":"m03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md","x":780,"y":45,"width":440,"height":230},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md","x":780,"y":-360,"width":440,"height":230},
|
||||
{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S02 Rollen und Berechtigungen.md","x":1560,"y":440,"width":440,"height":230},
|
||||
{"id":"note-seed","type":"text","text":"# Seed-Rollen\n\nAdmin als einzige Systemrolle.\n\nSeed-Rollen: Geschaeftsfuehrer, Projektleiter, Verwaltung, Vertriebler, Kundensupporter, Monteur.\n\nSeed-Rollen sind editierbar.","x":1520,"y":1020,"width":520,"height":240},
|
||||
{"id":"note-backlog","type":"text","text":"# Backlog / V2\n\nReassign beim Deaktivieren, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Review-Zyklus, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz.","x":3200,"y":1020,"width":600,"height":240},
|
||||
{"id":"d03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md","x":3280,"y":440,"width":440,"height":230},
|
||||
{"id":"note-permission","type":"text","text":"# Permission-Muster\n\nIm Rollen-Modal wird eine konkrete Permission-Zeile vorgebaut:\n\n`Mitarbeiter ansehen`\nBeschreibung darunter\nControl: `Aus / Read-only / Bearbeiten`\n\nFinaler Rechtekatalog liegt bei Development.","x":2360,"y":1010,"width":560,"height":260},
|
||||
{"id":"m02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle erstellen bearbeiten.md","x":2420,"y":440,"width":440,"height":230},
|
||||
{"id":"note-navigation","type":"text","text":"# Navigation\n\nS01 ist der Einstieg unter `Settings -> Mitarbeiter`.\n\nDer Rollen-Tab S02 ist direkt ueber die Settings-Tabs erreichbar und zusaetzlich ueber den Dropdown-Eintrag `Rollen und Berechtigungen bearbeiten`.","x":-40,"y":1020,"width":520,"height":240},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S01 Mitarbeiterliste.md","x":0,"y":45,"width":440,"height":230},
|
||||
{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md","x":2440,"y":-360,"width":440,"height":230}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-m01","fromNode":"s01","fromSide":"right","toNode":"m01","toSide":"left","label":"Mitarbeiter einladen"},
|
||||
{"id":"edge-s01-m03","fromNode":"s01","fromSide":"right","toNode":"m03","toSide":"left","label":"deaktivieren"},
|
||||
{"id":"edge-s01-d01","fromNode":"s01","fromSide":"right","toNode":"d01","toSide":"left","label":"Rolle wechseln"},
|
||||
{"id":"edge-d01-s02","fromNode":"d01","fromSide":"right","toNode":"s02","toSide":"left","label":"Rollen bearbeiten"},
|
||||
{"id":"edge-s02-m02","fromNode":"s02","fromSide":"right","toNode":"m02","toSide":"left","label":"anlegen/bearbeiten"},
|
||||
{"id":"edge-m03-v01","fromNode":"m03","fromSide":"right","toNode":"v01","toSide":"left","label":"letzter Admin"},
|
||||
{"id":"edge-d01-v01","fromNode":"d01","fromSide":"right","toNode":"v01","toSide":"left","label":"Admin entfernen"},
|
||||
{"id":"edge-m02-d03","fromNode":"m02","fromSide":"right","toNode":"d03","toSide":"left","label":"Rolle in Nutzung"},
|
||||
{"id":"edge-m02-permission","fromNode":"m02","fromSide":"bottom","toNode":"note-permission","toSide":"top","label":"Permission UI"},
|
||||
{"id":"edge-s02-seed","fromNode":"s02","fromSide":"bottom","toNode":"note-seed","toSide":"top","label":"Rollenmodell"},
|
||||
{"id":"edge-d03-backlog","fromNode":"d03","fromSide":"bottom","toNode":"note-backlog","toSide":"top","label":"spaeter"},
|
||||
{"id":"edge-s01-navigation","fromNode":"s01","fromSide":"bottom","toNode":"note-navigation","toSide":"top","label":"Settings-Tabs"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,481 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Admin RBAC
|
||||
typ: Admin Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/42c54a17-9c08-4db3-9306-1449f5b874e4/edit"
|
||||
canvas: WF-P2 Admin RBAC.canvas
|
||||
---
|
||||
|
||||
# WF-P2 Admin RBAC
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/42c54a17-9c08-4db3-9306-1449f5b874e4/edit
|
||||
Canvas: [[WF-P2 Admin RBAC.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
Dieses Paket plant die Admin-Flaechen aus D-P2 fuer Rollen, Berechtigungen und Mitarbeiter. Gruppen sind nach Produktentscheidung nicht Teil dieses Pakets.
|
||||
|
||||
Der wichtigste UX-Risikopunkt ist das sichere Bearbeiten von Rollen/Permissions. Reassign beim Deaktivieren wird fuer v1 bewusst in den Backlog gelegt.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / RBAC / Tenant Users |
|
||||
| Was soll der Nutzer am Ende schaffen? | Mitarbeiter einladen/verwalten, Rollen zuweisen und Rollen/Permissions pflegen |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | Admin-Paket mit Listen, Editoren und Modal-/Workflow-Zustaenden |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP §1 Auth-Screens, bestehende Settings-Routen `roles-and-permissions` |
|
||||
| Was ist sicher im Scope? | Mitarbeiter/Rollen-Zuweisung, Rollen-Subpage mit Rechtebereichen, Einladungsmodal, einfache Deaktivieren-Bestaetigung |
|
||||
| Was ist sicher nicht im Scope? | Gruppen, Plattform-Admin, Feature-Flags, Audit-Viewer |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | Ja, nur Admins duerfen diese Flaechen sehen/bearbeiten |
|
||||
| Welche Annahmen sind noch unsicher? | keine fuer v1; konkrete Permission-Zuschnitte werden im Development finalisiert |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 Auth |
|
||||
| Nutzerrolle | Tenant-Admin |
|
||||
| Admin-Variante | Vollzugriff auf Rollen, Permissions-Katalog und Mitarbeiter |
|
||||
| Normale Rolle | Keine Berechtigung / kein Zugriff |
|
||||
| Startpunkt | Settings -> Mitarbeiter |
|
||||
| Ziel | Tenant-Team und Rechte verwalten |
|
||||
| Haupt-Archetyp | A2 List + A5 Modal + A6 Settings |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | Gruppen, Audit, Plattform-Admin, Billing |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Wie schneiden wir RBAC so, dass es genug fuer Dev/Handoff ist, aber nicht zu einem riesigen Admin-Board wird?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | Settings-Bereich mit Tabs: Mitarbeiter, Rollen und Berechtigungen | kompakt, gut scanbar | mehrere Arbeitsmomente | genommen |
|
||||
| B | Ein grosses Team-Admin-Dashboard | alles zentral | zu breit und schwer zu validieren | raus |
|
||||
| C | Nur Mitarbeiter bauen, Rollen spaeter | schneller | D-P2-Luecke bleibt offen | raus |
|
||||
| D | Gruppen als Teil des RBAC-Pakets | bildet D-P2 voll ab | fuer v1 zu viel und fachlich nicht benoetigt | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Settings-Struktur statt separatem Admin-Center | genommen | bestehende Route ist `Settings -> Roles & Permissions` |
|
||||
| Gruppen raus | genommen | Gruppen werden in diesem Paket nicht gebaut |
|
||||
| Vorgebaute Rollen | genommen | Admin startet mit sinnvollen Seed-Rollen |
|
||||
| Eigene Rollen anlegen und benennen | genommen | Rollen-Editor erlaubt Custom Roles |
|
||||
| Rollen-Editor als eigener Arbeitsmoment | genommen | Permission-Bundles + Advanced brauchen Raum |
|
||||
| Kein separater Berechtigungen-Tab | genommen | Berechtigungen sind fuer Admins Teil des Tabs `Rollen und Berechtigungen` |
|
||||
| Einladung als Modal | genommen | A5, kein eigener Fullscreen noetig |
|
||||
| Deaktivieren mit Reassign | Backlog | v1 macht nur einfache Deaktivieren-Bestaetigung |
|
||||
| Keine-Berechtigung-Zustand dokumentieren | genommen | normale Nutzer duerfen Admin-Flaechen nicht sehen |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Admin oeffnet Mitarbeiterliste.
|
||||
2. Admin laedt Nutzer ein und weist eine oder mehrere Rollen zu.
|
||||
3. Admin nutzt vorgebaute Rollen oder erstellt eine eigene Rolle mit eigenem Namen.
|
||||
4. Wenn ein Nutzer deaktiviert wird, bestaetigt der Admin eine kurze Sicherheitsfrage.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- Rolle erstellen: Name, Beschreibung und Permission-Bundles auswaehlen.
|
||||
- Rolle bearbeiten: Permission-Bundles anpassen.
|
||||
- Rolle loeschen: nur moeglich, wenn keine Mitarbeiter zugewiesen sind; sonst kleines Blocker-Modal und manuelle Umzuweisung.
|
||||
- Nutzer deaktivieren: kurzes Confirm-Modal; Status wird danach `Deaktiviert`.
|
||||
- Einladung laeuft ab oder wird erneut gesendet.
|
||||
- Admin versucht letzten Admin zu deaktivieren.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- keine Berechtigung
|
||||
- letzter Admin
|
||||
- Rolle in Benutzung
|
||||
- Rollenname existiert bereits
|
||||
- Einladung bereits vorhanden
|
||||
- Reassign-Ziel fehlt nur spaeter relevant, Backlog
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| Einladung gesendet | Toast | nein | nein | Erfolg |
|
||||
| Einladung existiert | Inline/Modal-Hinweis | ja | nein | erneutes Senden anbieten |
|
||||
| Rolle in Benutzung | kleines Blocker-Modal | ja | Nur dokumentieren | Loeschen erst nach manueller Umzuweisung moeglich |
|
||||
| Rollenname existiert | Inline | ja | nein | Name muss eindeutig sein |
|
||||
| Nutzer deaktivieren | kleines Modal | ja | ja | einfache Bestaetigung |
|
||||
| Letzter Admin | Blocker | ja | pruefen | sicherheitskritisch |
|
||||
| Keine Berechtigung | A7 State | ja | nein | wiederverwenden |
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Mitarbeiter & Rollen | zentrale Zuweisung von Rollen an User | Bauen |
|
||||
| Einladung Modal | neuer Nutzer | Bauen/Wiederverwenden A5 |
|
||||
| Rollen-Dropdown in Mitarbeiterliste | direkte Rollenzuweisung und Sprung zum Tab `Rollen und Berechtigungen` | Nur dokumentieren |
|
||||
| Mitarbeiter deaktivieren | einfache Sicherheitsbestaetigung | Bauen |
|
||||
| Deaktivieren mit Reassign | spaetere Uebertragung offener Verantwortlichkeiten | Backlog |
|
||||
| Rollen und Berechtigungen | vorgebaute und eigene Rollen verwalten | Bauen |
|
||||
| Rolle erstellen/bearbeiten | eigene Rollen anlegen/benennen, Seed-Rollen bearbeiten, Permission-Bundles setzen | In S02 loesen |
|
||||
| Rechtebereiche im Tab `Rollen und Berechtigungen` | erklaert Berechtigungen im Kontext der Rolle | In S02 loesen |
|
||||
| Rolle loeschen mit Ersatzrolle | verhindert Rechteverlust | Backlog |
|
||||
| Letzter Admin blockiert | Sicherheitsblocker | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 6. Rollen- und Permission-Vorschlag
|
||||
|
||||
### Rollenmodell
|
||||
|
||||
| Typ | Rolle | Zweck | Notiz |
|
||||
|---|---|---|---|
|
||||
| Systemrolle | Admin | Vollzugriff auf Mitarbeiter, Rollen, Workspace-Settings und kritische Admin-Funktionen | einzige sichtbare Systemrolle |
|
||||
| Seed-Rolle | Geschaeftsfuehrer | Leitung, voller fachlicher Ueberblick, Team/Rechte/Billing | bearbeitbare Startrolle |
|
||||
| Seed-Rolle | Projektleiter | Projekte, Aufgaben, Teamueberblick, operative Steuerung | bearbeitbare Startrolle |
|
||||
| Seed-Rolle | Verwaltung | Buero, Stammdaten, Rechnungen, Mitglieder-Ueberblick | bearbeitbare Startrolle |
|
||||
| Seed-Rolle | Vertriebler | Leads, Angebote, Kundenkommunikation | bearbeitbare Startrolle |
|
||||
| Seed-Rolle | Kundensupporter | Kundenanfragen, Kommunikation, Servicefaelle | bearbeitbare Startrolle |
|
||||
| Seed-Rolle | Monteur | zugewiesene Auftraege/Tasks mobil bearbeiten | bearbeitbare Startrolle |
|
||||
| Custom Role | frei benennbar | Admin legt eigene Rolle an | Name, Beschreibung, Permission-Bundles |
|
||||
|
||||
Notiz: Die sechs Seed-Rollen sind fachliche Startpunkte und sollen direkt bearbeitbar sein. Admins koennen zusaetzlich eigene Rollen anlegen und benennen.
|
||||
|
||||
### Permission-Bundles fuer den Editor
|
||||
|
||||
Die folgenden Bundles sind nur ein Arbeitsgeruest fuer Planung und Wireframe. Sie muessen nicht vollstaendig vorgebaut werden; Development kann den finalen Rechtekatalog spaeter sauber ausmodellieren. Fuer das UI reicht in v1 ein konkretes Permission-Zeilenmuster im Rollen-Modal.
|
||||
|
||||
| Bundle | Enthalt grob | Relevanz fuer v1 |
|
||||
|---|---|---|
|
||||
| Basiszugriff | Dashboard/App betreten, eigene Daten sehen | direkt |
|
||||
| Mitarbeiter | Mitglieder sehen, einladen, bearbeiten, deaktivieren | direkt |
|
||||
| Rollen & Berechtigungen | Rollen ansehen, Rollen setzen, Custom Roles pflegen | direkt |
|
||||
| Workspace Settings | Workspace/Account Settings sehen und bearbeiten | direkt |
|
||||
| Abrechnung | Subscription, Rechnungen, Rechnungsdaten | direkt/teilweise |
|
||||
| Audit & Sicherheit | Audit-Log sehen, sicherheitsrelevante Admin-Einsicht | direkt/teilweise |
|
||||
| Integrationen/API | API Keys, Plugins, technische Anbindungen | direkt/teilweise |
|
||||
| CRM/Kunden | Kunden/Firmen/Kontakte lesen/schreiben/admin | fachliches Modul, ggf. spaeter |
|
||||
| Leads/Vertrieb | Leads, Angebote, Pipeline, Umsatzfelder | fachliches Modul, ggf. spaeter |
|
||||
| Projekte/Auftraege | Projekte, Auftraege, Planung, Zuweisungen | fachliches Modul, ggf. spaeter |
|
||||
| Aufgaben/Dateien | Tasks, Dokumente, Uploads, Freigaben | fachliches Modul, ggf. spaeter |
|
||||
| Kommunikation/Support | Anfragen, Chat, Telefonie/Support-Kontext | fachliches Modul, ggf. spaeter |
|
||||
|
||||
### Grober Rollenzuschnitt
|
||||
|
||||
| Rolle | Permission-Richtung |
|
||||
|---|---|
|
||||
| Geschaeftsfuehrer | fast alles, inklusive Mitarbeiter, Rollen, Workspace Settings, Abrechnung, Audit |
|
||||
| Projektleiter | Projekte/Auftraege, Aufgaben/Dateien, Team-Ueberblick, Mitglieder nur lesen |
|
||||
| Verwaltung | Mitarbeiter lesen, Workspace/Account-Basis, Abrechnung/Rechnungen, Kunden-/Projekt-Ueberblick |
|
||||
| Vertriebler | CRM/Kunden, Leads/Vertrieb, Angebote, eigene Pipeline |
|
||||
| Kundensupporter | Kundenkommunikation, Supportfaelle, lesender Projekt-/Kundenkontext |
|
||||
| Monteur | eigene/zugewiesene Auftraege, Aufgaben, Dateien, mobile Ausfuehrung |
|
||||
|
||||
---
|
||||
|
||||
## 7. Grober Screen-Aufbau
|
||||
|
||||
### Settings-Aufteilung
|
||||
|
||||
Entscheidung: Option A ist genommen. Das Paket lebt unter `Settings -> Mitarbeiter`. Darin liegen nur die Tabs `Mitarbeiter` und `Rollen und Berechtigungen`.
|
||||
|
||||
| Option | Aufbau | Vorteil | Nachteil |
|
||||
|---|---|---|---|
|
||||
| A | `Settings -> Mitarbeiter` als Oberpunkt mit Tabs `Mitarbeiter`, `Rollen und Berechtigungen` | fuer Admins intuitiv und kompakt | technische Berechtigungen sind nur im Rollen-Kontext sichtbar |
|
||||
| B | `Settings -> Rollen & Berechtigungen` als Oberpunkt mit Tabs `Mitarbeiter`, `Rollen`, `Berechtigungen` | passt zur bestehenden Code-Struktur | zu technisch und weniger kompakt |
|
||||
| C | zwei Settings-Punkte: `Mitarbeiter` und `Rollen & Berechtigungen` | klare Trennung zwischen Menschen und Rechte-System | mehr Navigation, Rollen-Zuweisung springt zwischen Bereichen |
|
||||
|
||||
Die technische Route kann spaeter weiterhin an die bestehende App-Struktur angepasst werden; fuer Wireframes und Navigation ist der sichtbare Einstieg `Settings -> Mitarbeiter`.
|
||||
|
||||
### Validierungsreihenfolge
|
||||
|
||||
Wir validieren einzeln und legen erst danach Screen-Dateien/Canvas an.
|
||||
|
||||
1. `S01 Mitarbeiterliste`
|
||||
2. `M01 Mitarbeiter einladen`
|
||||
3. `D01 Rollen-Dropdown in Mitarbeiterliste`
|
||||
4. `M03 Mitarbeiter deaktivieren`
|
||||
5. `S02 Rollen und Berechtigungen`
|
||||
6. `M02 Rolle erstellen/bearbeiten`
|
||||
7. `D03 Rolle in Nutzung blockiert`
|
||||
|
||||
### S01 Mitarbeiterliste
|
||||
|
||||
Ziel: Admin findet schnell Nutzer und kann Rollen/Status pruefen.
|
||||
|
||||
Layout:
|
||||
|
||||
1. Header: `Mitarbeiter`, kurze Beschreibung, Primaer-CTA `Mitarbeiter einladen`.
|
||||
2. Tab-Leiste innerhalb `Settings -> Mitarbeiter`: `Mitarbeiter`, `Rollen und Berechtigungen`.
|
||||
3. Toolbar:
|
||||
- Suchfeld: Name, E-Mail, Telefonnummer.
|
||||
- Filter `Rolle` als Multi-Select.
|
||||
- Filter `Abteilung` als Multi-Select.
|
||||
- Filter `Status`: Aktiv, Eingeladen, Deaktiviert.
|
||||
- Filter `2FA`: Aktiv, Nicht eingerichtet.
|
||||
- Aktive Filter als Chips mit `Alle zuruecksetzen`.
|
||||
4. Tabelle:
|
||||
- Mitarbeiter: Avatar, Name, E-Mail.
|
||||
- Abteilung.
|
||||
- Rollen als Dropdown/Select.
|
||||
- Status.
|
||||
- 2FA.
|
||||
- Aktionen: 3-Punkte-Menue rechts.
|
||||
5. Empty/Filtered State:
|
||||
- keine Treffer fuer Suche/Filter.
|
||||
- Link/Button zum Filter zuruecksetzen.
|
||||
6. Rollen-Dropdown:
|
||||
- zeigt aktuelle Rolle(n).
|
||||
- erlaubt direkte Rollenauswahl, sofern Admin die Berechtigung hat.
|
||||
- enthaelt Eintrag `Rollen und Berechtigungen bearbeiten`.
|
||||
- `Rollen und Berechtigungen bearbeiten` navigiert in den Tab `Rollen und Berechtigungen` unter `Settings -> Mitarbeiter`.
|
||||
7. Zeilenaktionen:
|
||||
- rechts in jeder Tabellenzeile ein 3-Punkte-Menue.
|
||||
- enthaelt kontextabhaengig `Einladung erneut senden`, `Deaktivieren`, ggf. `Profil oeffnen`.
|
||||
|
||||
### M03 Mitarbeiter deaktivieren
|
||||
|
||||
Ziel: Admin bestaetigt eine einfache Deaktivierung eines Mitarbeiters.
|
||||
|
||||
Layout:
|
||||
|
||||
1. Kleines Confirm-Modal aus der Mitarbeiterliste.
|
||||
2. Headline: `Mitarbeiter deaktivieren?`
|
||||
3. Inhalt:
|
||||
- Name und E-Mail des Mitarbeiters.
|
||||
- kurzer Hinweis, dass der Mitarbeiter danach keinen Zugriff mehr auf den Workspace hat.
|
||||
- Hinweis, dass der Mitarbeiter in der Liste mit Status `Deaktiviert` sichtbar bleibt.
|
||||
4. Aktionen:
|
||||
- Primaer/Danger: `Deaktivieren`
|
||||
- Sekundaer: `Abbrechen`
|
||||
5. Nach Erfolg:
|
||||
- Modal schliesst.
|
||||
- Toast `Mitarbeiter wurde deaktiviert`.
|
||||
- Tabellenstatus wechselt auf `Deaktiviert`.
|
||||
6. Nicht in v1:
|
||||
- Reassign offener Verantwortlichkeiten.
|
||||
- mehrstufiger Workflow.
|
||||
|
||||
### S02 Rollen und Berechtigungen
|
||||
|
||||
Ziel: Admin verwaltet Rollen als eigene Subpage innerhalb `Settings -> Mitarbeiter`, nicht als Modal aus der Mitarbeiterliste. Berechtigungen werden nur hier im Kontext der Rolle sichtbar.
|
||||
|
||||
Layout:
|
||||
|
||||
1. Header: `Rollen und Berechtigungen`, CTA `Rolle anlegen`.
|
||||
2. Toolbar:
|
||||
- Suchfeld: Rollenname, Beschreibung.
|
||||
- Filter `Typ`: Systemrolle, Seed-Rolle, Eigene Rolle.
|
||||
- Filter `Permission-Bundle`: z. B. Mitarbeiter, Abrechnung, Projekte.
|
||||
- Filter `In Nutzung`: mit Mitgliedern / ohne Mitglieder.
|
||||
3. Tabelle:
|
||||
- Rolle.
|
||||
- Beschreibung.
|
||||
- Typ: System, Seed-Rolle, Eigene Rolle.
|
||||
- Mitglieder: Avatar-Stack oder Anzahl.
|
||||
- Status: Aktiv, Pruefen.
|
||||
- Aktionen: 3-Punkte-Menue rechts.
|
||||
4. Zeilenaktionen:
|
||||
- rechts in jeder Tabellenzeile ein 3-Punkte-Menue.
|
||||
- enthaelt `Bearbeiten`, `Duplizieren`, `Loeschen`.
|
||||
- bei Systemrolle `Admin` keine Loeschen-Aktion.
|
||||
5. Rollen-Bearbeitung:
|
||||
- passiert in diesem Tab/Subpage-Kontext.
|
||||
- aus `Bearbeiten`, `Duplizieren` oder `Rolle anlegen` oeffnet sich ein sehr grosses Modal.
|
||||
- das Modal ist nicht aus der Mitarbeiterliste heraus erreichbar, sondern nur aus `Rollen und Berechtigungen`.
|
||||
6. Rechtebereiche:
|
||||
- werden beim Bearbeiten einer Rolle angezeigt.
|
||||
- keine separate Hauptnavigation.
|
||||
- optional mit Advanced-Einzelrechten als ausklappbare Details.
|
||||
7. Loeschzustand:
|
||||
- wenn keine Mitglieder zugewiesen sind, kann eine Rolle geloescht werden.
|
||||
- wenn die Rolle noch genutzt wird, erscheint ein kleines Blocker-Modal.
|
||||
- Copy-Richtung: `Diese Rolle kann nicht geloescht werden, solange Mitarbeiter zugewiesen sind.`
|
||||
- Aktion: `Verstanden`; Admin weist Mitglieder danach manuell einer anderen Rolle zu.
|
||||
- Ersatzrolle/Bulk-Reassign bleibt Backlog.
|
||||
|
||||
### M02 Rolle erstellen/bearbeiten
|
||||
|
||||
Ziel: Admin erstellt eine eigene Rolle oder passt eine vorhandene/Seed-Rolle an, ohne die Rollen-Subpage zu verlassen.
|
||||
|
||||
Layout:
|
||||
|
||||
1. Sehr grosses Modal ueber dem Tab `Rollen und Berechtigungen`.
|
||||
2. Modal kann jederzeit geschlossen werden.
|
||||
3. Kopfbereich:
|
||||
- Rollenname.
|
||||
- Beschreibung.
|
||||
- optional: Start aus Vorlage.
|
||||
- optional: Standardrolle fuer neue Nutzer.
|
||||
4. Globale Berechtigungs-Suche:
|
||||
- Suchfeld oben im Modal.
|
||||
- durchsucht alle Berechtigungen/Rechtebereiche ueber alle Module hinweg.
|
||||
- filtert die sichtbaren Treffer bereichsuebergreifend.
|
||||
- Treffer bleiben ihren Bereichsueberschriften zugeordnet, damit Kontext erhalten bleibt.
|
||||
5. Linke Sidebar:
|
||||
- zeigt die Rechtebereiche/Module als Navigation.
|
||||
- Beispiele: Ueberblick, Mitarbeiter, Rollen und Berechtigungen, Workspace Settings, Abrechnung, Audit & Sicherheit, Integrationen/API, CRM/Kunden, Leads/Vertrieb, Projekte/Auftraege, Aufgaben/Dateien, Kommunikation/Support.
|
||||
- Klick springt zum jeweiligen Bereich im Modal.
|
||||
6. Startzustand `Ueberblick`:
|
||||
- ist initial aktiv.
|
||||
- zeigt eine scrollbare Liste aller Berechtigungen/Rechtebereiche.
|
||||
- die Bereichsueberschriften entsprechen den Eintraegen in der linken Sidebar.
|
||||
- Admin kann bis ganz nach unten scrollen.
|
||||
7. Rechtebereiche:
|
||||
- jeder Bereich hat Toggle/Checkboxen, um Berechtigungen an- oder auszuschalten.
|
||||
- Bereich kann eine Kurzbeschreibung enthalten.
|
||||
- einzelne technische Rechte koennen als Advanced Details aufgeklappt werden, falls noetig.
|
||||
8. Permission-Zeilenmuster:
|
||||
- eine Beispiel-Permission wird im Wireframe konkret vorgebaut.
|
||||
- Aufbau: links Ueberschrift, darunter kurze Beschreibung; rechts die Zugriffsauswahl.
|
||||
- Beispiel-Ueberschrift: `Mitarbeiter ansehen`.
|
||||
- Beispiel-Beschreibung: `Darf Mitarbeiterliste und Mitarbeiterprofile im Workspace lesen.`
|
||||
- Control: Segmented Control `Aus`, `Read-only`, `Bearbeiten`; alternativ Toggle `Aus/An`, wenn die Permission nur binaer ist.
|
||||
- `Read-only` steht fuer lesenden Zugriff ohne Bearbeiten/Aendern.
|
||||
- weitere Permissions koennen Development-seitig nach diesem Muster ergaenzt werden.
|
||||
9. Footer:
|
||||
- Speichern.
|
||||
- Abbrechen.
|
||||
- ggf. Rolle loeschen als Danger Action.
|
||||
|
||||
## 8. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Mitarbeiterliste | ja | ja | Validiert | Suche, Filter, Tabelle und Aktionen passen erstmal |
|
||||
| M01 | Mitarbeiter einladen | ja | ja | Validiert | Modal mit E-Mail, optional Name/Abteilung und Rollen |
|
||||
| D01 | Rollen-Dropdown in Mitarbeiterliste | nein | ja | Validiert | direkte Rollenauswahl; Bearbeiten fuehrt in `Rollen und Berechtigungen` |
|
||||
| M03 | Mitarbeiter deaktivieren | ja | ja | Validiert | kleines Confirm-Modal, kein Reassign |
|
||||
| S02 | Rollen und Berechtigungen | ja | ja | Validiert | Rollen-Tabelle nach Referenz, 3-Punkte-Menue, nur Systemrolle Admin |
|
||||
| M02 | Rolle erstellen/bearbeiten | ja | ja, Permissions | Validiert | grosses Modal mit Sidebar, Ueberblick, globaler Suche und Rechte-Toggles |
|
||||
| D03 | Rolle in Nutzung blockiert | nein | ja | Validiert | Loeschen nur ohne Mitglieder; sonst kleines Blocker-Modal, Ersatzrolle/Bulk-Reassign im Backlog |
|
||||
| V01 | Letzter Admin blockiert | ja | ja, Sicherheitsblocker | Validiert | kleiner Blocker-State im jeweiligen Kontext |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| Mitarbeiter deaktivieren | ja | kurzer Sicherheitsmoment |
|
||||
| Letzter Admin blockiert | ja | kleiner Blocker-State im jeweiligen Kontext |
|
||||
| Rolle in Benutzung | Nur dokumentieren | kleines Blocker-Modal; Ersatzrolle/Bulk-Reassign liegt im Backlog |
|
||||
| Custom Role anlegen | ja | muss klar zwischen Vorlage und eigener Rolle unterscheiden |
|
||||
|
||||
### Blockierende Error States
|
||||
|
||||
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
||||
|---|---|---|---|---|
|
||||
| Letzter Admin | Screen/Modal | weiteren Admin bestimmen | abbrechen | kein Tenant ohne Admin |
|
||||
| Reassign-Ziel fehlt | Backlog | - | - | spaeter fuer Reassign-Workflow |
|
||||
| Rolle in Benutzung | kleines Blocker-Modal | Verstanden | - | Rolle kann erst geloescht werden, wenn keine Mitarbeiter mehr zugewiesen sind |
|
||||
| Rollenname existiert | Inline | Namen aendern | abbrechen | eindeutige Rollennamen |
|
||||
|
||||
---
|
||||
|
||||
## 9. Validierte Screen-Liste
|
||||
|
||||
Alle aktiven Screen-Kandidaten sind von David validiert. Seed-Rollen und Permission-Bundles sind als v1-Arbeitsfassung dokumentiert; der finale Rechtekatalog wird im Development ausgearbeitet.
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Mitarbeiterliste | Admin List | Bauen | `Settings -> Mitarbeiter`, Tab `Mitarbeiter` | Validiert |
|
||||
| M01 | Mitarbeiter einladen | Modal | Bauen | von S01 | Validiert |
|
||||
| D01 | Rollen-Dropdown in Mitarbeiterliste | Inline-Zustand | Nur dokumentieren | in S01 | Validiert |
|
||||
| M03 | Mitarbeiter deaktivieren | Confirm Modal | Bauen | von S01 | Validiert |
|
||||
| S02 | Rollen und Berechtigungen | Settings Subpage | Bauen | `Settings -> Mitarbeiter`, Tab `Rollen und Berechtigungen` | Validiert |
|
||||
| M02 | Rolle erstellen/bearbeiten | Grosses Modal | Bauen | von S02 | Validiert |
|
||||
| D03 | Rolle in Nutzung blockiert | Admin Blocker | Nur dokumentieren | von S02/M02 | Validiert |
|
||||
| V01 | Letzter Admin blockiert | Admin Blocker | Nur dokumentieren | von S01/M03/Rollenwechsel | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 10. Subframe-Grid
|
||||
|
||||
```text
|
||||
S01 Mitarbeiterliste -> M01 Mitarbeiter einladen
|
||||
S01 Mitarbeiterliste -> D01 Rollen-Dropdown
|
||||
S01 Mitarbeiterliste -> M03 Mitarbeiter deaktivieren
|
||||
S01 Mitarbeiterliste -> V01 Letzter Admin blockiert
|
||||
S01 Mitarbeiterliste -> S02 Rollen und Berechtigungen via Dropdown-Eintrag
|
||||
S02 Rollen und Berechtigungen -> M02 Rolle erstellen/bearbeiten
|
||||
S02 Rollen und Berechtigungen -> D03 Rolle in Nutzung blockiert
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 11. Screen-Pakete
|
||||
|
||||
| ID | Datei |
|
||||
|---|---|
|
||||
| S01 | [[Screens/S01 Mitarbeiterliste]] |
|
||||
| M01 | [[Screens/M01 Mitarbeiter einladen]] |
|
||||
| D01 | [[Screens/D01 Rollen-Dropdown in Mitarbeiterliste]] |
|
||||
| M03 | [[Screens/M03 Mitarbeiter deaktivieren]] |
|
||||
| S02 | [[Screens/S02 Rollen und Berechtigungen]] |
|
||||
| M02 | [[Screens/M02 Rolle erstellen bearbeiten]] |
|
||||
| D03 | [[Screens/D03 Rolle in Nutzung blockiert]] |
|
||||
| V01 | [[Screens/V01 Letzter Admin blockiert]] |
|
||||
|
||||
---
|
||||
|
||||
## 12. Backlog / V2
|
||||
|
||||
Diese Punkte sind bewusst nicht Teil der v1-Screen-Liste, sollen aber fuer spaetere Versionen sichtbar bleiben.
|
||||
|
||||
| Thema | Beschreibung | Warum spaeter |
|
||||
|---|---|---|
|
||||
| Deaktivieren mit Reassign | Beim Deaktivieren offene Projekte, Aufgaben, Leads, Kunden, Dateien oder Verantwortlichkeiten auf andere Nutzer uebertragen | v1 bleibt bewusst bei kleinem Confirm-Modal |
|
||||
| Rollen-Loeschen mit Ersatzrolle | Wenn eine Rolle noch Nutzer hat, Ersatzrolle waehlen und Nutzer gesammelt umziehen | v1 blockiert nur und verlangt manuelle Umzuweisung |
|
||||
| Gruppen | Gruppen/Teams/Abteilungen als eigene Verwaltung, ggf. mit Bulk-Zuweisung | fuer v1 aus RBAC rausgenommen |
|
||||
| Rechtekatalog als eigener Tab | Alle technischen Berechtigungen unabhaengig von Rollen durchsuchen/erklaeren | v1 zeigt Rechte nur im Rollen-Editor |
|
||||
| Rollen-Audit | Historie, wer Rollen/Rechte geaendert hat | Audit-Viewer nicht Teil dieses Pakets |
|
||||
| Rollen-Review / Needs Review | Rollen markieren, die geprueft werden muessen, inkl. Review-Zyklus | Status `Pruefen` ist UI-vorbereitet, Prozess spaeter |
|
||||
| Rollen-Templates erweitern | weitere branchenspezifische Seed-Rollen oder Workspace-Templates | aktuelle Seed-Rollen reichen fuer v1 |
|
||||
| Rechte-Matrix | Vergleich mehrerer Rollen nebeneinander | fuer v1 zu breit/technisch |
|
||||
| Bulk-Aktionen | mehrere Mitarbeiter gleichzeitig einladen, deaktivieren oder Rollen zuweisen | spaeter, wenn Teamlisten groesser werden |
|
||||
| Admin-Schutz erweitert | detaillierte Regeln fuer Selbst-Deaktivierung, letzter Admin, kritische Rollenwechsel | v1 dokumentiert Blocker, genaue Policy spaeter mit Dev/Security |
|
||||
|
||||
---
|
||||
|
||||
## 13. Handoff-Check
|
||||
|
||||
- [x] Paket ist angelegt.
|
||||
- [x] D-P2 Admin-Screens sind geprueft.
|
||||
- [x] Gruppen sind fuer dieses Paket rausgenommen.
|
||||
- [x] Vorgebaute Rollen plus eigene Rollen sind als Richtung notiert.
|
||||
- [x] Seed-Rollen- und Permission-Bundle-Vorschlag ist dokumentiert.
|
||||
- [x] Permission-Bundles sind als Arbeitsgeruest markiert, nicht als finaler Rechtekatalog.
|
||||
- [x] Permission-Zeilenmuster fuer das Rollen-Modal ist dokumentiert.
|
||||
- [x] Grober Screen-Aufbau mit Suche/Filtern ist dokumentiert.
|
||||
- [x] S01 Mitarbeiterliste ist validiert.
|
||||
- [x] M01 Mitarbeiter einladen ist validiert.
|
||||
- [x] Rollen-Dropdown in S01 und Sprung zu `Rollen und Berechtigungen` sind dokumentiert.
|
||||
- [x] S02 Rollen und Berechtigungen ist validiert.
|
||||
- [x] M02 Rolle erstellen/bearbeiten ist validiert.
|
||||
- [x] M03 Mitarbeiter deaktivieren ist validiert.
|
||||
- [x] D03 Rolle in Nutzung blockiert ist validiert.
|
||||
- [x] V01 Letzter Admin blockiert ist validiert.
|
||||
- [x] Reassign ist in den Backlog gelegt.
|
||||
- [x] Backlog/V2-Liste ist dokumentiert.
|
||||
- [x] Seed-Rollen und Permission-Bundles sind fuer v1 ausreichend benannt.
|
||||
- [x] David hat die Kandidaten validiert.
|
||||
- [x] Screen-Dateien sind angelegt.
|
||||
- [x] Canvas ist angelegt.
|
||||
- [ ] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Change Password
|
||||
id: M01
|
||||
screen: Identitaet bestaetigen
|
||||
typ: Auth Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von Profil Settings
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/4274da58-939d-414a-b505-b5889911a517/edit"
|
||||
---
|
||||
|
||||
# M01 — Identitaet bestaetigen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer bestaetigt im eingeloggten Zustand, dass er die Passwortaenderung wirklich ausloest.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Modal/Wizard + Auth Form.
|
||||
|
||||
## Daten
|
||||
|
||||
- aktuelle Account-E-Mail, readonly
|
||||
- aktuelles Passwort
|
||||
- 2FA-Code, falls 2FA aktiv oder per Policy erforderlich
|
||||
|
||||
## Aktionen
|
||||
|
||||
- weiter
|
||||
- abbrechen / Modal schliessen
|
||||
- Passwort anzeigen/verbergen
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kurzer Hinweis: Diese Bestaetigung schuetzt das Konto vor Aenderungen aus einer offenen Sitzung.
|
||||
- Keine E-Mail-Link-Kommunikation.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; nach erfolgreicher Bestaetigung geht es direkt zu `WF-P2 Set Password`.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | Passwortfeld leer | Bauen |
|
||||
| Laden | Identitaet wird geprueft | Wiederverwenden |
|
||||
| Passwort falsch | Inline-Fehler am Passwortfeld | Nur dokumentieren |
|
||||
| 2FA erforderlich | 2FA-Codefeld wird im selben Modal angezeigt | Nur dokumentieren |
|
||||
| 2FA-Code falsch | Inline-Fehler am Codefeld | Nur dokumentieren |
|
||||
| Zu viele Fehlversuche | Rate-Limit erreicht | Variante V01 |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nutzer ist eingeloggt.
|
||||
- Start kommt aus Profil Settings oder einem spaeteren Security-Kontext.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Die E-Mail ist nicht editierbar. Der Nutzer soll klar sehen, fuer welches Konto das Passwort geaendert wird.
|
||||
|
||||
`2FA bestaetigen` ist kein eigener Screen in diesem Flow. Wenn 2FA fuer den Account aktiv oder per Policy erforderlich ist, erscheint die Code-Eingabe im selben Reauth-Modal.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Change Password
|
||||
id: V01
|
||||
screen: Zu viele Fehlversuche
|
||||
typ: Auth Blocker
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: nach falscher Reauth
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/abb6c78d-416f-4552-ba3a-b80e3f54c998/edit"
|
||||
---
|
||||
|
||||
# V01 — Zu viele Fehlversuche
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass der Change-Password-Flow wegen zu vieler falscher Bestaetigungsversuche voruebergehend blockiert ist.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Blocker-Modal.
|
||||
|
||||
## Daten
|
||||
|
||||
- generische Rate-Limit-Information
|
||||
- optionaler Hinweis auf erneuten Versuch spaeter
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Modal schliessen
|
||||
- spaeter erneut versuchen
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Keine genaue Sicherheitslogik offenlegen.
|
||||
- Keine Rohfehler oder Counter anzeigen.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Blocker ist das Modal.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Blockiert | Zu viele falsche Passwort- oder 2FA-Versuche | Bauen |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Rate-Limit fuer Reauth oder 2FA-Step-up wurde erreicht.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Der Blocker kann aus M01 erreicht werden. Er soll nicht verraten, ob Passwort oder 2FA-Code der genaue Ausloeser war.
|
||||
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":1900,"height":420,"label":"Hauptflow"},
|
||||
{"id":"group-blocker","type":"group","x":620,"y":560,"width":760,"height":360,"label":"Blocker"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":560,"height":360,"label":"Regeln"},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Change Password/Screens/M01 Identitaet bestaetigen.md","x":0,"y":0,"width":420,"height":200},
|
||||
{"id":"core-set-password","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/WF-P2 Set Password.md","x":640,"y":0,"width":420,"height":200},
|
||||
{"id":"note-core","type":"text","text":"# Core-Uebergabe\n\nNeues Passwort setzen und Abschluss liegen in `WF-P2 Set Password`.\n\n`WF-P2 Change Password` besitzt nur Reauth. 2FA-Code ist ein Zustand in M01, kein eigener Screen.","x":1280,"y":0,"width":420,"height":240},
|
||||
{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Change Password/Varianten/V01 Zu viele Fehlversuche.md","x":760,"y":680,"width":420,"height":200},
|
||||
{"id":"note-reauth","type":"text","text":"# Reauth-Regel\n\nKein E-Mail-Link im eingeloggten Zustand.\n\nAccount-E-Mail readonly anzeigen, aktuelles Passwort pruefen, 2FA erneut verlangen wenn aktiv oder per Policy erforderlich.","x":0,"y":680,"width":420,"height":200}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-m01-core","fromNode":"m01","fromSide":"right","toNode":"core-set-password","toSide":"left","label":"ok"},
|
||||
{"id":"edge-core-note","fromNode":"core-set-password","fromSide":"right","toNode":"note-core","toSide":"left","label":"Core"},
|
||||
{"id":"edge-m01-v01","fromNode":"m01","fromSide":"bottom","toNode":"v01","toSide":"top","label":"Rate Limit"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,199 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Change Password
|
||||
typ: Auth-Core Zubringer/Modal Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/04767909-3c2f-4236-92a8-b08eaa3f51b7/edit"
|
||||
canvas: WF-P2 Change Password.canvas
|
||||
---
|
||||
|
||||
# WF-P2 Change Password
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/04767909-3c2f-4236-92a8-b08eaa3f51b7/edit
|
||||
Canvas: [[WF-P2 Change Password.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
`Change Password` ist ein eigener, wiederverwendbarer Reauth-/Step-up-Flow fuer Passwortaenderungen.
|
||||
|
||||
Der Flow wird aus Profil Settings getriggert, bleibt aber bewusst getrennt, damit er spaeter auch aus anderen Kontexten genutzt werden kann. Da der Nutzer bereits eingeloggt ist, laeuft die Reauth innerhalb der App-Shell als Modal-/Wizard-Flow.
|
||||
|
||||
Validierter Sicherheitsansatz: kein E-Mail-Link. Stattdessen wird die aktuelle Account-E-Mail readonly angezeigt, der Nutzer muss sein aktuelles Passwort eingeben und bei aktiver 2FA im selben Modal zusaetzlich den 2FA-Code bestaetigen. Danach fuehrt der Flow in den Core-Flow `WF-P2 Set Password`, der das neue Passwort und den Abschluss besitzt.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 / Auth-Core |
|
||||
| Was soll der Nutzer am Ende schaffen? | Passwortaenderung im eingeloggten Zustand sicher starten und in `WF-P2 Set Password` wechseln |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | eigener wiederverwendbarer Reauth-/Step-up-Modal-Flow |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, Profil-und-Sicherheit-Entscheidung, OWASP MFA Guidance |
|
||||
| Was ist sicher im Scope? | Account-E-Mail readonly anzeigen, aktuelles Passwort pruefen, optionaler 2FA-Code im selben Reauth-Modal, Uebergabe an `WF-P2 Set Password` |
|
||||
| Was ist sicher nicht im Scope? | Profil Settings selbst, Passwort Reset fuer vergessene Passwoerter, Admin-Reset, E-Mail-Link-Flow, neues Passwort setzen, Abschlussfeedback |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | nein; gleicher Self-Service-Flow fuer eingeloggte Nutzer |
|
||||
| Welche Annahmen sind noch unsicher? | ob 2FA nur bei aktivem 2FA verlangt wird oder fuer bestimmte Rollen/Policies immer |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 / Auth-Core |
|
||||
| Nutzerrolle | eingeloggter Nutzer |
|
||||
| Admin-Variante | keine eigene UI; Policy kann 2FA erzwingen |
|
||||
| Normale Rolle | gleicher Flow |
|
||||
| Startpunkt | Trigger aus Profil Settings oder spaeter anderer Sicherheitskontext |
|
||||
| Ziel | sicherer Uebergang in `WF-P2 Set Password` |
|
||||
| Haupt-Archetyp | A5 Modal/Wizard + A4 Auth Form |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | Profil bearbeiten, 2FA verwalten, Passwort vergessen, E-Mail-Link versenden, neues Passwort setzen, Abschlussfeedback |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Soll Passwort aendern im eingeloggten Zustand ueber E-Mail-Link laufen oder direkt mit Step-up-Authentifizierung innerhalb der App?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | E-Mail-Link senden, danach Set-Password-Flow starten | stark entkoppelt | unnoetiger Medienbruch im eingeloggten Zustand | raus fuer diesen Flow |
|
||||
| B | Modal-Flow: aktuelle E-Mail anzeigen, aktuelles Passwort, optional 2FA-Code im selben Modal, dann Uebergabe an `WF-P2 Set Password` | sicher, schnell, bleibt leichtgewichtig | etwas mehr Inhalt in einem Modal | genommen |
|
||||
| C | Direkt neues Passwort im Profil setzen | sehr schnell | keine ausreichende Step-up-Pruefung | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Eigener Change-Password-Flow | genommen | getrennt vom Profil, spaeter wiederverwendbar |
|
||||
| UI als Modal-/Wizard-Flow | genommen | Start aus eingeloggter App-Shell |
|
||||
| Account-E-Mail readonly anzeigen | genommen | Nutzer sieht, fuer welches Konto geaendert wird |
|
||||
| Aktuelles Passwort verlangen | genommen | Step-up fuer sensible Kontoaenderung |
|
||||
| Kein E-Mail-Link | genommen | bei erfolgreicher Reauth nicht noetig; Passwort Reset bleibt eigener E-Mail-Link-Flow |
|
||||
| 2FA-Code im Reauth-Modal | genommen | wenn 2FA aktiv ist oder Policy es verlangt; kein eigener 2FA-Bestaetigen-Screen |
|
||||
| Neues Passwort setzen liegt im Core | genommen | nach erfolgreicher Reauth fuehrt der Flow zu `WF-P2 Set Password` |
|
||||
| Profil enthaelt nur Trigger | genommen | Profil startet Flow, enthaelt ihn aber nicht |
|
||||
|
||||
### Passwort-Staerke-Bar
|
||||
|
||||
Bei allen Screens, in denen ein neues Passwort gesetzt wird, soll unter dem Passwortfeld eine Staerke-Bar sitzen. Sie fuellt sich dynamisch und wird bei guter Passwortqualitaet gruen. Aktuelles Passwort/Reauth-Felder bekommen keine Staerke-Bar.
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer klickt in Profil Settings auf Passwort aendern.
|
||||
2. Modal `Passwort aendern` oeffnet sich innerhalb der App-Shell.
|
||||
3. Aktuelle Account-E-Mail wird readonly angezeigt.
|
||||
4. Nutzer gibt aktuelles Passwort ein.
|
||||
5. Wenn 2FA aktiv/erforderlich ist, gibt Nutzer den 2FA-Code im selben Modal ein.
|
||||
6. Flow fuehrt in `WF-P2 Set Password`.
|
||||
7. `WF-P2 Set Password` uebernimmt neues Passwort, Passwortregeln und Abschluss.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- Aktuelles Passwort ist falsch.
|
||||
- 2FA-Code ist falsch.
|
||||
- 2FA ist nicht aktiv: 2FA-Schritt wird uebersprungen.
|
||||
- Passwort entspricht nicht den Regeln: liegt in `WF-P2 Set Password`.
|
||||
- Rate Limit nach mehrfach falscher Reauth.
|
||||
- Nutzer bricht ab und kehrt zu Profil Settings zurueck.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- aktuelles Passwort falsch
|
||||
- 2FA-Code falsch
|
||||
- Rate Limit
|
||||
- nachgelagerte Passwortfehler liegen in `WF-P2 Set Password`
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| aktuelles Passwort falsch | Inline | ja | nein | korrigierbar im Modal |
|
||||
| 2FA-Code falsch | Inline | ja | nein | korrigierbar in M01 |
|
||||
| Rate Limit | Modal/Banner | ja | pruefen | erneuter Versuch spaeter |
|
||||
| neues Passwort ungueltig | - | - | nein | liegt in `WF-P2 Set Password` |
|
||||
| Passwort geaendert | - | - | nein | Abschluss liegt in `WF-P2 Set Password` |
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Identitaet bestaetigen | aktuelles Passwort + Account-E-Mail | Bauen |
|
||||
| 2FA-Code eingeben | Zustand in M01, falls 2FA aktiv/Policy | Nur dokumentieren |
|
||||
| Neues Passwort setzen | Passwort-Core | Wiederverwenden `WF-P2 Set Password` |
|
||||
| Passwort geaendert | Abschluss | Wiederverwenden `WF-P2 Set Password` |
|
||||
| Rate Limit / zu viele Fehlversuche | Sicherheitsblocker | Bauen |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| M01 | Identitaet bestaetigen | ja | ja, Security Step-up | Bauen | Account-E-Mail readonly + aktuelles Passwort + optionaler 2FA-Code |
|
||||
| D03 | 2FA-Code eingeben | nein | nein, Teil von Reauth | Nur dokumentieren | kein eigener Screen/Flow |
|
||||
| D01 | Neues Passwort setzen | ja | ja, Passwort-Core | Wiederverwenden | liegt in `WF-P2 Set Password` |
|
||||
| D02 | Passwort geaendert | ja | nein, Feedback | Wiederverwenden | Abschluss liegt in `WF-P2 Set Password` |
|
||||
| V01 | Zu viele Fehlversuche | ja | ja, Security Blocker | Bauen | Rate Limit darf nicht nur inline verschwinden |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| M01 | Identitaet bestaetigen | Modal | Bauen | von Profil Settings | Validiert |
|
||||
| D01 | Neues Passwort setzen | Auth-Core | Wiederverwenden | `WF-P2 Set Password` | Validiert |
|
||||
| D02 | Passwort geaendert | Auth-Core Feedback | Wiederverwenden | `WF-P2 Set Password` | Validiert |
|
||||
| V01 | Zu viele Fehlversuche | Modal/Blocker | Bauen | nach falscher Reauth | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
```text
|
||||
Profil Settings -> M01 Identitaet bestaetigen
|
||||
M01 enthaelt optional 2FA-Code, wenn 2FA aktiv/Policy
|
||||
M01 -> WF-P2 Set Password
|
||||
WF-P2 Set Password -> neues Passwort setzen + Abschluss
|
||||
M01 -> V01 Zu viele Fehlversuche
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
| ID | Datei |
|
||||
|---|---|
|
||||
| M01 | [[Screens/M01 Identitaet bestaetigen.md]] |
|
||||
| V01 | [[Varianten/V01 Zu viele Fehlversuche.md]] |
|
||||
|
||||
Core-Verweis:
|
||||
|
||||
- [[../WF-P2 Set Password/WF-P2 Set Password.md]]
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Eigenes Paket ist angelegt.
|
||||
- [x] Profil ist nur Trigger, nicht Besitzer des Flows.
|
||||
- [x] E-Mail-Link-Variante ist fuer eingeloggte Passwortaenderung rausgenommen.
|
||||
- [x] Reauth mit aktuellem Passwort ist dokumentiert.
|
||||
- [x] 2FA-Code ist als optionaler Zustand in M01 dokumentiert.
|
||||
- [x] David hat die Kandidaten validiert.
|
||||
- [ ] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Konto loeschen
|
||||
id: M01
|
||||
screen: Loeschung anfragen
|
||||
typ: Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von S01
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/e8454b77-b5bc-4c80-b035-bde4318793e7/edit"
|
||||
---
|
||||
|
||||
# M01 — Loeschung anfragen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer bestaetigt bewusst, dass er eine Loeschungsanfrage stellen moechte.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A5 Confirm-Modal.
|
||||
|
||||
## Daten
|
||||
|
||||
- aktueller Account-/Workspace-Kontext
|
||||
- kurzer Erklaerungstext
|
||||
- Datenexport-Hinweis
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Anfrage senden
|
||||
- abbrechen
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarstellen: Dies ist eine Anfrage, keine sofortige Loeschung.
|
||||
- Kurz erklaeren, dass die Anfrage geprueft bzw. bearbeitet wird.
|
||||
- Datenexport-Hinweis integrieren: Vor einer Loeschung koennen Daten exportiert oder angefordert werden.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nach Absenden: Toast und Rueckkehr zu S01.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Confirm | Erklaerung + Anfrage senden | Bauen |
|
||||
| Laden | Anfrage wird gesendet | Wiederverwenden |
|
||||
| Anfrage fehlgeschlagen | Banner/Inline mit Retry | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nutzer hat Berechtigung, eine Loeschungsanfrage zu stellen.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Kein Countdown, keine Confirm-Phrase und kein Reauth-Step in v1. Diese Komplexitaet liegt im Backlog fuer den spaeteren echten Loeschprozess.
|
||||
+67
@@ -0,0 +1,67 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Konto loeschen
|
||||
id: S01
|
||||
screen: Settings -> Workspaces / Loeschbereich
|
||||
typ: Settings
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /settings/workspaces
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/7f54d6e5-df2f-4163-bb36-1310062b2429/edit"
|
||||
---
|
||||
|
||||
# S01 — Settings -> Workspaces / Loeschbereich
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer findet im Settings-Bereich `Workspaces` den minimalen Einstieg, um eine Loeschungsanfrage zu stellen.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A6 Settings / Workspace Settings.
|
||||
|
||||
## Daten
|
||||
|
||||
- aktueller Workspace / Account-Kontext
|
||||
- Status einer bestehenden Loeschungsanfrage, falls vorhanden
|
||||
- Berechtigung fuer Loeschungsanfrage
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Loeschung anfragen -> M01
|
||||
- Status einer bestehenden Anfrage ansehen
|
||||
- Settings verlassen
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klar formulieren: Es wird eine Anfrage gestellt, keine sofortige Loeschung ausgefuehrt.
|
||||
- Workspaces-Bereich ist v1 minimal; weitere Workspace-Settings kommen spaeter.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nach erfolgreicher Anfrage: Toast `Loeschungsanfrage wurde gesendet`.
|
||||
- Zusaetzlich Status im Bereich anzeigen, wenn eine Anfrage bereits offen ist.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Keine Anfrage | CTA `Loeschung anfragen` sichtbar | Bauen |
|
||||
| Anfrage offen | Status/Banner statt erneuter CTA | Nur dokumentieren |
|
||||
| Keine Berechtigung | CTA verborgen oder deaktiviert | Nur dokumentieren |
|
||||
| Anfrage fehlgeschlagen | Banner mit Retry | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Loeschungsanfrage ist permission-gated.
|
||||
- Normale Rollen sehen keinen aktiven CTA.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen ist bewusst der minimale Start eines spaeter groesseren Workspace-Settings-Bereichs.
|
||||
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":1260,"height":420,"label":"Loeschungsanfrage"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":1260,"height":360,"label":"Dokumentierte Zustaende"},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/S01 Settings Workspaces Loeschbereich.md","x":0,"y":0,"width":420,"height":200},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/M01 Loeschung anfragen.md","x":640,"y":0,"width":420,"height":200},
|
||||
{"id":"note-request","type":"text","text":"# Anfrage statt Loeschung\n\nV1 fuehrt keine direkte technische Loeschung aus.\n\nNach M01: Toast + Status `Anfrage offen` in S01.","x":0,"y":680,"width":420,"height":200},
|
||||
{"id":"note-permission","type":"text","text":"# Berechtigung\n\nCTA ist permission-gated.\n\nNormale Rollen sehen keinen aktiven Loeschungs-CTA oder nur disabled state.","x":540,"y":680,"width":420,"height":200},
|
||||
{"id":"note-backlog","type":"text","text":"# Backlog\n\nVoller Loeschprozess, Datenexport-Step, Reauth, Confirm Phrase und Workspace-Loeschungsdetails spaeter.","x":1080,"y":680,"width":420,"height":200}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-m01","fromNode":"s01","fromSide":"right","toNode":"m01","toSide":"left","label":"Loeschung anfragen"},
|
||||
{"id":"edge-m01-s01","fromNode":"m01","fromSide":"bottom","toNode":"s01","toSide":"bottom","label":"Anfrage gesendet"},
|
||||
{"id":"edge-s01-permission","fromNode":"s01","fromSide":"bottom","toNode":"note-permission","toSide":"top","label":"Permission"},
|
||||
{"id":"edge-m01-request","fromNode":"m01","fromSide":"bottom","toNode":"note-request","toSide":"top","label":"Feedback"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,207 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Konto loeschen
|
||||
typ: Settings Request Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/6fec2ec6-eab5-4e25-9c9a-90da47a5047a/edit"
|
||||
canvas: WF-P2 Konto loeschen.canvas
|
||||
---
|
||||
|
||||
# WF-P2 Konto loeschen
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/6fec2ec6-eab5-4e25-9c9a-90da47a5047a/edit
|
||||
Canvas: [[WF-P2 Konto loeschen.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
Dieses Paket plant fuer v1 keinen echten Loesch-Wizard, sondern eine schlanke Loeschungsanfrage aus `Settings -> Workspaces`.
|
||||
|
||||
Der Nutzer bzw. Admin loescht nicht direkt selbst. Er kann eine Anfrage stellen, den Account bzw. Workspace loeschen zu lassen. Was genau operativ geloescht wird und wie der spaetere Workspace-Loeschprozess aussieht, bleibt Backlog. Wichtig fuer v1 ist nur: Der Einstieg existiert versteckt im Settings-Bereich `Workspaces`, die Aktion ist klar als Anfrage formuliert und wird nicht als sofortige Loeschung dargestellt.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / Account Lifecycle / Settings |
|
||||
| Was soll der Nutzer am Ende schaffen? | Eine Loeschungsanfrage fuer Account/Workspace stellen oder bewusst abbrechen |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | schlanker Settings-Request-Flow |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, Settings-Entscheidung, Workspace-Settings-Entscheidung |
|
||||
| Was ist sicher im Scope? | Settings-Unterpunkt `Workspaces`, Loeschungsanfrage-CTA, Sicherheits-/Erklaerungsmodal, Anfrage absenden, Feedback |
|
||||
| Was ist sicher nicht im Scope? | direkte technische Loeschung, vollstaendiger DSGVO-Wizard, detaillierter Export-Flow, Billing-/Legal-Abwicklung, vollstaendige Workspace-Settings |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | wahrscheinlich ja; Loeschungsanfrage ist mindestens permission-gated, Details spaeter mit Admin/RBAC klaeren |
|
||||
| Welche Annahmen sind noch unsicher? | finale Copy: `Account loeschen anfragen` vs. `Workspace loeschen anfragen`; konkrete Berechtigung |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 Auth / Settings |
|
||||
| Nutzerrolle | Admin oder berechtigte Rolle |
|
||||
| Admin-Variante | kann Loeschungsanfrage aus `Settings -> Workspaces` starten |
|
||||
| Normale Rolle | sieht keinen Einstieg oder keinen aktiven CTA |
|
||||
| Startpunkt | `Settings -> Workspaces` |
|
||||
| Ziel | Loeschungsanfrage absenden |
|
||||
| Haupt-Archetyp | A6 Settings + A5 Modal |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | direkte Account-/Workspace-Loeschung, mehrstufiger Wizard, vollstaendiger Datenexport, Workspace-Verwaltung im Detail |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Wie kann Loeschung in v1 vorhanden sein, ohne einen grossen irreversiblen Loesch-Wizard zu bauen?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | Voller Wizard: Erklaerung -> Export -> Reauth -> Confirm | maximal kontrolliert | fuer v1 zu schwer und noch fachlich unklar | raus/backlog |
|
||||
| B | Settings -> Workspaces mit CTA `Loeschung anfragen`, danach Sicherheitsmodal | schlank, klar, keine direkte Loeschung | Details muessen spaeter operationalisiert werden | genommen |
|
||||
| C | Nur Backlog, gar kein Screen | keine Komplexitaet | Nutzer findet keinen Einstieg | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Loeschung nur als Anfrage | genommen | keine sofortige technische Loeschung in v1 |
|
||||
| Einstieg unter Settings -> Workspaces | genommen | Workspaces-Bereich wird spaeter mehr enthalten; v1 minimal |
|
||||
| Settings/Workspaces minimal bauen | genommen | zunaechst nur Loeschungsbereich dokumentieren |
|
||||
| Erklaerung im Modal | genommen | keine eigene Wizard-Seite |
|
||||
| Datenexport als Hinweis/sekundare Option | genommen | kein eigener Export-Step in v1 |
|
||||
| Workspace-Loeschprozess Detail | Backlog | spaeter eigener Flow aus Workspace-Einstellungen |
|
||||
| Voller DSGVO-/Countdown-Wizard | Backlog | nicht Teil dieses schlanken v1-Scopes |
|
||||
| Direkte Loeschung | raus | Nutzer stellt Anfrage, System/Team bearbeitet |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Berechtigter Nutzer oeffnet `Settings -> Workspaces`.
|
||||
2. Nutzer klickt im Loeschbereich auf `Loeschung anfragen`.
|
||||
3. Modal fragt, ob der Nutzer sicher ist, und erklaert kurz die Konsequenzen.
|
||||
4. Modal weist darauf hin, dass es eine Anfrage ist und keine sofortige Loeschung.
|
||||
5. Optionaler Hinweis: Vor der Loeschung koennen Daten exportiert/angefordert werden.
|
||||
6. Nutzer sendet die Anfrage ab.
|
||||
7. System zeigt Feedback: Anfrage wurde uebermittelt.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- Nutzer bricht im Modal ab.
|
||||
- Nutzer hat keine Berechtigung: CTA verborgen oder deaktiviert.
|
||||
- Anfrage wurde bereits gestellt: Status im Workspaces-Bereich anzeigen.
|
||||
- Technischer Fehler beim Absenden: Inline/Banner mit Retry.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- keine Berechtigung
|
||||
- Anfrage bereits offen
|
||||
- technische Anfrage stoert
|
||||
- finale Loesch-Art noch unklar
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| Loeschung anfragen | Modal | ja | ja | bewusst als Anfrage formulieren |
|
||||
| Erklaerung | Modal-Inhalt | nein | ja | kurz, keine Rechtsberatung |
|
||||
| Datenexport | Hinweis/sekundare Aktion | nein | nur dokumentieren | kein eigener Step |
|
||||
| Anfrage gesendet | Toast/Feedback | nein | pruefen | Status sichtbar machen |
|
||||
| Keine Berechtigung | hidden/disabled state | ja | nur dokumentieren | kein eigener Screen |
|
||||
| Anfrage bereits offen | Status im Settings-Bereich | nein | pruefen | verhindert doppelte Anfrage |
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Settings -> Workspaces / Loeschbereich | Einstieg in den minimalen Workspace-Settings-Bereich | Bauen |
|
||||
| Loeschung anfragen Modal | Sicherheits- und Erklaerungsstep | Bauen |
|
||||
| Anfrage gesendet | Feedback/Status | Pruefen, vermutlich Toast + Status reicht |
|
||||
| Keine Berechtigung | Permission State | Nur dokumentieren |
|
||||
| Datenexport Hinweis | DSGVO-relevanter Hinweis | Nur dokumentieren / im Modal integrieren |
|
||||
| Voller Datenexport-Step | zu gross fuer v1 | Backlog |
|
||||
| Direkte Loeschung | nicht gewollt | Raus |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Settings -> Workspaces / Loeschbereich | ja | ja, neuer Settings-Unterpunkt | Bauen | minimaler Workspaces-Bereich mit Loeschungsanfrage |
|
||||
| M01 | Loeschung anfragen | ja | ja, destruktive Anfrage | Bauen | Modal mit Sicher-Abfrage, Erklaerung, Datenexport-Hinweis |
|
||||
| D01 | Anfrage gesendet | nein | nein | Nur dokumentieren | Toast plus Status im S01 reicht |
|
||||
| D02 | Keine Berechtigung | nein | nein | Nur dokumentieren | CTA verborgen/deaktiviert |
|
||||
| D03 | Datenexport Hinweis | nein | ja, Compliance-Hinweis | In M01 integrieren | kein eigener Screen |
|
||||
| D04 | Workspace-Loeschprozess Detail | ja | ja, eigener Scope | Backlog | spaeter aus Workspace-Einstellungen |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| Anfrage statt Loeschung | ja | UI darf keine sofortige Loeschung versprechen |
|
||||
| Erklaerung | ja | Nutzer muss Konsequenzen verstehen |
|
||||
| Datenexport-Hinweis | ja, integriert | Nutzer soll wissen, dass Datenexport vor Loeschung relevant ist |
|
||||
|
||||
### Blockierende Error States
|
||||
|
||||
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
||||
|---|---|---|---|---|
|
||||
| Keine Berechtigung | hidden/disabled | Admin kontaktieren | zurueck | keine technische Rollenlogik |
|
||||
| Anfrage bereits offen | Status/Banner | Status ansehen | Support kontaktieren | keine doppelte Anfrage |
|
||||
| Anfrage fehlgeschlagen | Banner | erneut versuchen | abbrechen | keine Rohfehler |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Settings -> Workspaces / Loeschbereich | Settings | Bauen | `/settings/workspaces` | Validiert |
|
||||
| M01 | Loeschung anfragen | Modal | Bauen | von S01 | Validiert |
|
||||
| D01 | Anfrage gesendet | Toast/Status | Nur dokumentieren | nach M01 | Validiert |
|
||||
| D02 | Keine Berechtigung | Permission State | Nur dokumentieren | in S01 | Validiert |
|
||||
| D03 | Datenexport Hinweis | Modal Content | In M01 integrieren | in M01 | Validiert |
|
||||
| D04 | Workspace-Loeschprozess Detail | Backlog | Backlog | spaeter | Backlog |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
```text
|
||||
Settings -> S01 Workspaces / Loeschbereich
|
||||
S01 -> M01 Loeschung anfragen
|
||||
M01 -> D01 Anfrage gesendet (Toast/Status)
|
||||
S01 -> D02 Keine Berechtigung (hidden/disabled)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
| ID | Datei |
|
||||
|---|---|
|
||||
| S01 | [[Screens/S01 Settings Workspaces Loeschbereich.md]] |
|
||||
| M01 | [[Screens/M01 Loeschung anfragen.md]] |
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Paket ist angelegt.
|
||||
- [x] Scope wurde auf Loeschungsanfrage reduziert.
|
||||
- [x] Voller Loesch-/Export-Wizard ist Backlog.
|
||||
- [x] Settings -> Workspaces ist als Startpunkt dokumentiert.
|
||||
- [x] David hat die Kandidaten validiert.
|
||||
- [ ] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
id: S01
|
||||
screen: Login
|
||||
typ: Auth Form
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /login
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/389ee115-d9ac-45df-9139-b6a443bcf215/edit"
|
||||
---
|
||||
|
||||
# S01 — Login
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer meldet sich mit E-Mail und Passwort an, wechselt bewusst zur Magic-Link-Anmeldung oder geht zur Konto-Erstellung.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / Auth-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail
|
||||
- Passwort
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Einloggen
|
||||
- Per Magic-Link anmelden
|
||||
- Passwort vergessen
|
||||
- Konto erstellen / Registrieren
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kein permanenter Banner im Normalzustand.
|
||||
- Fehler erscheinen in den Varianten V01 und V02.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Success-Toast; erfolgreicher Login leitet weiter.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | leeres Formular | Bauen |
|
||||
| Laden | Button loading nach Klick auf Einloggen | Wiederverwenden |
|
||||
| Fehler | falsche Daten siehe V01 | Bauen |
|
||||
| Keine Berechtigung | nicht relevant fuer Login | Raus |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- keine aktive Rolle vor Login
|
||||
|
||||
## Outcome
|
||||
|
||||
- Wenn 2FA noetig: weiter zu [[S04 2FA Code eingeben]].
|
||||
- Wenn keine 2FA noetig: weiter je Rolle.
|
||||
- Normale Rolle: Home/App.
|
||||
- Admin: Tenant-/Workspace-Auswahl oder Admin-Startpunkt.
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/389ee115-d9ac-45df-9139-b6a443bcf215/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Magic-Link ist als Alternative sichtbar, aber nicht dominanter als Login.
|
||||
|
||||
Es gibt keinen separaten E-Mail-Pre-Screen. Der Login-Screen zeigt E-Mail und Passwort direkt gemeinsam. Unterhalb oder in der Naehe der Auth-Aktionen steht ein klarer Link fuer Nutzer ohne Konto, z. B. "Noch kein Konto? Konto erstellen".
|
||||
|
||||
Subframe-Handoff: Unter dem Passwortfeld liegt eine Passwort-Staerke-Bar. Development kann sie dynamisch fuellen und je nach Passwortqualitaet von schwach/rot bis stark/gruen darstellen.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
id: S02
|
||||
screen: Magic-Link anfordern
|
||||
typ: Auth Form
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /login magic-link
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/f22caacd-e7db-4909-8223-e703ad4630d2/edit"
|
||||
---
|
||||
|
||||
# S02 — Magic-Link anfordern
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer fordert einen Login-Link per E-Mail an.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / Auth-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Magic-Link senden
|
||||
- Zurueck zum Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Hinweis, dass der Link nur begrenzt gueltig ist.
|
||||
- Keine Aussage, ob die E-Mail existiert.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; nach Absenden geht es zu [[S03 Magic-Link gesendet]].
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | E-Mail-Feld leer oder aus Login uebernommen | Bauen |
|
||||
| Laden | Button loading | Wiederverwenden |
|
||||
| Fehler | technische Zustellung fehlgeschlagen | Nur dokumentieren |
|
||||
| Keine Berechtigung | nicht relevant | Raus |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- keine aktive Rolle vor Login
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/f22caacd-e7db-4909-8223-e703ad4630d2/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Wenn der Nutzer auf S01 bereits eine E-Mail eingegeben hat, kann das Feld vorausgefuellt sein. Trotzdem keine sichtbare Aussage, ob der Account existiert.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
id: S03
|
||||
screen: Magic-Link gesendet
|
||||
typ: Auth Feedback
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /login magic-link sent
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/bd2e7c70-721b-4c88-92d0-7ea59aa8fc57/edit"
|
||||
---
|
||||
|
||||
# S03 — Magic-Link gesendet
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass er sein Postfach pruefen soll und was er tun kann, wenn keine E-Mail ankommt.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Feedback-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- maskierte oder wiederholte E-Mail optional
|
||||
|
||||
## Aktionen
|
||||
|
||||
- E-Mail erneut senden
|
||||
- andere E-Mail verwenden
|
||||
- zurueck zum Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Neutraler Text: Wenn ein Konto zu dieser E-Mail existiert, wurde ein Link gesendet.
|
||||
- Hinweis auf Spam-Ordner.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nach erneutem Senden: kurze Inline-Bestaetigung oder Button-Loading.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Erfolg | Link wurde angefordert | Bauen |
|
||||
| Laden | erneutes Senden laeuft | Wiederverwenden |
|
||||
| Fehler | Link konnte nicht erneut gesendet werden | Nur dokumentieren |
|
||||
| Keine Berechtigung | nicht relevant | Raus |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- keine aktive Rolle vor Login
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/bd2e7c70-721b-4c88-92d0-7ea59aa8fc57/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen ist copy-kritisch. Er darf nicht verraten, ob die E-Mail existiert.
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
id: S04
|
||||
screen: 2FA Code eingeben
|
||||
typ: Auth Security
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /login 2fa
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/9a61f957-0c2e-49d3-9c30-47d9a09a262c/edit"
|
||||
---
|
||||
|
||||
# S04 — 2FA Code eingeben
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer bestaetigt den Login mit einem 6-stelligen Code aus der Authenticator-App.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / A5 Auth-Step.
|
||||
|
||||
## Daten
|
||||
|
||||
- 6-stelliger TOTP-Code
|
||||
- Trust-Device-Option
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Code bestaetigen
|
||||
- Diesem Geraet vertrauen
|
||||
- Wiederherstellungscode verwenden
|
||||
- zurueck zum Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Hinweis auf Authenticator-App.
|
||||
- Fehler/Lockout siehe [[../Varianten/V03 2FA gesperrt]].
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Success-Toast; erfolgreicher Code leitet weiter.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | Codefelder leer | Bauen |
|
||||
| Laden | Bestaetigen laeuft | Wiederverwenden |
|
||||
| Fehler | falscher Code als Inline-Fehler | Nur dokumentieren |
|
||||
| Gesperrt | siehe V03 | Bauen |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Login-Daten wurden akzeptiert.
|
||||
- 2FA ist fuer den Account noetig.
|
||||
|
||||
## Outcome
|
||||
|
||||
- Normale Rolle: Home/App.
|
||||
- Admin: Tenant-/Workspace-Auswahl oder Admin-Startpunkt.
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/9a61f957-0c2e-49d3-9c30-47d9a09a262c/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Trust-Device ist integriert und kein eigener Screen.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
id: V01
|
||||
screen: Login falsche Daten
|
||||
typ: Auth Error
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /login
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/2ebdb245-6b2e-4565-8301-d82e1e39a393/edit"
|
||||
---
|
||||
|
||||
# V01 — Login falsche Daten
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass der Login nicht geklappt hat, ohne dass das System verrät, ob E-Mail oder Passwort falsch war.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Variante von [[../Screens/S01 Login]].
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail
|
||||
- Passwort
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Eingaben korrigieren
|
||||
- Passwort vergessen
|
||||
- Per Magic-Link anmelden
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Neutraler Fehlertext: E-Mail oder Passwort ist nicht korrekt.
|
||||
- Keine Aussage, ob die E-Mail existiert.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Fehler erscheint im Screen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Fehler | neutraler Login-Fehler | Bauen |
|
||||
| Nach weiteren Versuchen | Captcha siehe V02 | Bauen |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- keine aktive Rolle vor Login
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/2ebdb245-6b2e-4565-8301-d82e1e39a393/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Copy-kritisch. Nicht als beliebiger roter Feldfehler dem Dev ueberlassen.
|
||||
|
||||
Subframe-Handoff: Unter dem Passwortfeld liegt dieselbe Passwort-Staerke-Bar wie in S01. In dieser Fehler-/schwachen Variante kann sie niedrig/rot dargestellt werden.
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
id: V02
|
||||
screen: Login mit mCaptcha
|
||||
typ: Auth Error
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /login
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/a945cd6f-9f0f-473b-ac6f-fdb9b0e2bfaa/edit"
|
||||
---
|
||||
|
||||
# V02 — Login mit mCaptcha
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer kann nach mehreren Fehlversuchen weiterhin einloggen, muss aber zusaetzlich das Captcha-Feld abschliessen.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Variante von [[../Screens/S01 Login]].
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail
|
||||
- Passwort
|
||||
- mCaptcha-Slot
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Captcha loesen
|
||||
- Einloggen
|
||||
- Passwort vergessen
|
||||
- Per Magic-Link anmelden
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Hinweis, dass nach mehreren Fehlversuchen eine Sicherheitspruefung erforderlich ist.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Captcha bleibt im Screen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Captcha sichtbar | Captcha-Feld im Login-Screen | Bauen |
|
||||
| Captcha fehlgeschlagen | Inline-Hinweis | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- mCaptcha erscheint nach mehreren Fehlversuchen, laut Planning ab 3 Fehlversuchen.
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/a945cd6f-9f0f-473b-ac6f-fdb9b0e2bfaa/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Wird gebaut, weil sich die Struktur des Login-Screens sichtbar veraendert.
|
||||
|
||||
Subframe-Handoff: Unter dem Passwortfeld liegt dieselbe Passwort-Staerke-Bar wie in S01. Development kann die Fuellung und Farbe dynamisch aus der Passwortqualitaet ableiten.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
id: V03
|
||||
screen: 2FA gesperrt
|
||||
typ: Auth Blocker
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /login 2fa
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/2db31f2a-eb97-4c99-aa9f-8f77aa6eb4b6/edit"
|
||||
---
|
||||
|
||||
# V03 — 2FA gesperrt
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass die 2FA-Bestaetigung voruebergehend gesperrt ist und welche Alternative oder Wartezeit gilt.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Variante von [[../Screens/S04 2FA Code eingeben]].
|
||||
|
||||
## Daten
|
||||
|
||||
- Sperrhinweis
|
||||
- optional Wartezeit
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Wiederherstellungscode verwenden
|
||||
- spaeter erneut versuchen
|
||||
- zurueck zum Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Warnhinweis: Zu viele Fehlversuche. Bitte spaeter erneut versuchen oder Wiederherstellungscode verwenden.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Blocker bleibt im Screen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Gesperrt | Code-Eingabe deaktiviert oder stark eingeschraenkt | Bauen |
|
||||
| Wiederherstellung | Link/CTA zu Recovery | Spaeter |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Login-Daten wurden akzeptiert.
|
||||
- 2FA wurde zu oft falsch eingegeben.
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/2db31f2a-eb97-4c99-aa9f-8f77aa6eb4b6/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Copy-kritisch und sicherheitsrelevant.
|
||||
@@ -0,0 +1,27 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":1840,"height":360,"label":"Hauptflow"},
|
||||
{"id":"group-login-variants","type":"group","x":-80,"y":520,"width":1100,"height":430,"label":"Login-Varianten"},
|
||||
{"id":"group-magic","type":"group","x":-760,"y":520,"width":560,"height":760,"label":"Magic-Link Branch"},
|
||||
{"id":"group-2fa-variants","type":"group","x":1120,"y":520,"width":560,"height":430,"label":"2FA-Variante"},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/Screens/S01 Login.md","x":0,"y":0,"width":400,"height":190},
|
||||
{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/Screens/S02 Magic-Link anfordern.md","x":-660,"y":660,"width":400,"height":190},
|
||||
{"id":"s03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/Screens/S03 Magic-Link gesendet.md","x":-660,"y":1000,"width":400,"height":190},
|
||||
{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/Varianten/V01 Login falsche Daten.md","x":40,"y":660,"width":400,"height":190},
|
||||
{"id":"note-layout","type":"text","text":"# Canvas-Regel\n\nHauptflow nach rechts.\nBranches liegen darunter.\nBranch-Kanten bleiben ohne Labels, damit nichts ueberlappt.","x":1220,"y":1000,"width":460,"height":180},
|
||||
{"id":"note-login","type":"text","text":"# Login-Entscheidung\n\nKein E-Mail-Pre-Screen.\n\nS01 zeigt direkt:\n- E-Mail\n- Passwort\n- Magic-Link Alternative\n- Konto erstellen Link","x":-760,"y":-25,"width":460,"height":240},
|
||||
{"id":"outcome","type":"text","text":"# Outcome\n\nNormale Rolle -> Home/App\n\nAdmin -> Tenant-/Workspace-Auswahl oder Admin-Startpunkt\n\nWenn keine 2FA noetig ist, endet S01 direkt hier.\n\nLogin erfolgreich wird nicht als eigener Screen gebaut.","x":1360,"y":-25,"width":360,"height":240},
|
||||
{"id":"s04","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/Screens/S04 2FA Code eingeben.md","x":680,"y":0,"width":400,"height":190},
|
||||
{"id":"v02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/Varianten/V02 Login mit mCaptcha.md","x":560,"y":660,"width":400,"height":190},
|
||||
{"id":"v03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Login und 2FA/Varianten/V03 2FA gesperrt.md","x":1220,"y":660,"width":400,"height":190}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-s04","fromNode":"s01","fromSide":"right","toNode":"s04","toSide":"left","label":"2FA"},
|
||||
{"id":"edge-s04-outcome","fromNode":"s04","fromSide":"right","toNode":"outcome","toSide":"left","label":"ok"},
|
||||
{"id":"edge-s01-s02","fromNode":"s01","fromSide":"bottom","toNode":"s02","toSide":"top","label":"Magic-Link"},
|
||||
{"id":"edge-s02-s03","fromNode":"s02","fromSide":"bottom","toNode":"s03","toSide":"top","label":"gesendet"},
|
||||
{"id":"edge-s01-v01","fromNode":"s01","fromSide":"bottom","toNode":"v01","toSide":"top","label":"falsch"},
|
||||
{"id":"edge-s01-v02","fromNode":"s01","fromSide":"bottom","toNode":"v02","toSide":"top","label":"Captcha"},
|
||||
{"id":"edge-s04-v03","fromNode":"s04","fromSide":"bottom","toNode":"v03","toSide":"top","label":"gesperrt"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,245 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Login und 2FA
|
||||
typ: Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/a457cbaa-9cca-412a-98b2-3bef128338ac/edit"
|
||||
canvas: "02 Wireframes/P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas"
|
||||
---
|
||||
|
||||
# WF-P2 Login und 2FA
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/a457cbaa-9cca-412a-98b2-3bef128338ac/edit
|
||||
Canvas: [[WF-P2 Login und 2FA.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
Dieses Paket beschreibt den Login-Flow mit E-Mail/Passwort, Magic-Link-Alternative und 2FA.
|
||||
|
||||
Ziel ist ein einfacher Standard-Auth-Flow, aber mit bewusst gebauten copy-kritischen Auth-Zustaenden wie Magic-Link gesendet, falsche Login-Daten, Captcha nach mehreren Versuchen und 2FA gesperrt.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / Identitaet |
|
||||
| Was soll der Nutzer am Ende schaffen? | sich sicher einloggen und bei Bedarf 2FA bestaetigen |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | Flow mit Hauptscreens und wichtigen Varianten |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP Auth-Screens |
|
||||
| Was ist sicher im Scope? | Login, Magic-Link, Magic-Link gesendet, 2FA, falsche Login-Daten, Captcha, 2FA gesperrt, Konto-erstellen-Link im Login |
|
||||
| Was ist sicher nicht im Scope? | Signup-Flow selbst, Passwort vergessen, Profil-/Tenant-Auswahl als eigener Flow, Session-Verwaltung |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | Ja, aber nur als Outcome nach erfolgreichem Login |
|
||||
| Welche Annahmen sind noch unsicher? | Ob 2FA wirklich immer kommt oder nur bei aktivierter 2FA; fuer Wireframe reicht "bei Bedarf" |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 Auth |
|
||||
| Nutzerrolle | eingeloggter Nutzer nach erfolgreicher Authentifizierung |
|
||||
| Admin-Variante | Admin geht nach Login zur Tenant-/Workspace-Auswahl oder Admin-Startpunkt |
|
||||
| Normale Rolle | hoechste Rolle unter Admin geht nach Login zur Home/App |
|
||||
| Startpunkt | `/login` |
|
||||
| Ziel | Authentifizierung erfolgreich abschliessen |
|
||||
| Haupt-Archetyp | A4 Form + A5 Auth-Step |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | Tenant-Auswahl-Flow, Signup-Flow selbst, Passwort-Reset |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
Screen-Listen entstehen erst nach dem Brainstorming. Hier wurde zuerst entschieden, ob Login E-Mail-first oder klassisch gebuendelt laufen soll.
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Soll Login zuerst nur die E-Mail abfragen oder direkt E-Mail und Passwort zusammen zeigen?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | E-Mail und Passwort zusammen auf einem Login-Screen | einfach, vertraut, wenig Schritte | weniger Security-Guidance | genommen |
|
||||
| B | E-Mail-first, danach Passwort oder Magic-Link | kontrollierter, modern | mehr Schritte, komplexer | raus fuer v1 |
|
||||
| C | Voller Security-first Flow mit Account-Erkennung und mehreren Pfaden | sehr granular | zu komplex, Risiko fuer Account-Enumeration | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| E-Mail + Passwort zusammen | genommen | einfacher Standardflow; kein E-Mail-Pre-Screen |
|
||||
| Magic-Link direkt auf Login sichtbar | genommen | Alternative sichtbar, aber nicht dominant |
|
||||
| Magic-Link eigener Anforderungs-Screen | genommen | bewusster Wechsel in alternativen Login |
|
||||
| Konto erstellen Link im Login | genommen | Signup ist erreichbar, aber eigener Flow |
|
||||
| Wichtige Auth-Zustaende bauen | genommen | Copy soll von Design entschieden werden |
|
||||
| Admin-Weiterleitung | dokumentieren | eigener Tenant-/Workspace-Flow spaeter |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer oeffnet Login.
|
||||
2. Nutzer gibt E-Mail und Passwort ein.
|
||||
3. Falls 2FA noetig ist, gibt Nutzer den 6-stelligen Code ein.
|
||||
4. Danach geht es je nach Rolle weiter.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- Nutzer waehlt Magic-Link.
|
||||
- Magic-Link wurde gesendet.
|
||||
- Login-Daten sind falsch.
|
||||
- Captcha erscheint nach mehreren Fehlversuchen.
|
||||
- 2FA ist gesperrt oder zu oft falsch eingegeben.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- falsche Login-Daten
|
||||
- Captcha erforderlich
|
||||
- 2FA zu oft falsch
|
||||
- technische Login-Fehler
|
||||
|
||||
### Offene Fragen
|
||||
|
||||
- Kommt 2FA wirklich bei jedem Login oder nur bei aktivierter 2FA?
|
||||
- Admin-/Mehrworkspace-Ziel wird in `WF-P2 Workspace Auswahl` geplant; UI-Begriff ist Workspace.
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Login | Hauptscreen | Bauen |
|
||||
| Magic-Link anfordern | alternativer Auth-Weg | Bauen |
|
||||
| Magic-Link gesendet | copy-kritischer Erfolg | Bauen |
|
||||
| 2FA Code eingeben | eigener Security-Schritt | Bauen |
|
||||
| Login mit falschen Daten | haeufiger, copy-kritischer Fehler | Bauen |
|
||||
| Login mit mCaptcha | Layout aendert sich nach 3 Fehlversuchen | Bauen |
|
||||
| 2FA gesperrt | wichtiger Blocker | Bauen |
|
||||
| Konto erstellen Link | Nutzer ohne Konto braucht klaren Einstieg | in S01 integrieren |
|
||||
| E-Mail-Pre-Screen | alternative UX, aber fuer v1 zu viel Schritt | Raus |
|
||||
| Trust Device | Bestandteil von 2FA | in 2FA integrieren |
|
||||
| Login erfolgreich | reine Weiterleitung | Raus |
|
||||
| Admin-Weiterleitung | Rollen-Outcome | Dokumentieren |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | [[Screens/S01 Login]] | ja | ja, Hauptauthentifizierung | Bauen | Hauptscreen |
|
||||
| S02 | [[Screens/S02 Magic-Link anfordern]] | ja | ja, alternativer Login-Weg | Bauen | Nutzer entscheidet bewusst Magic-Link |
|
||||
| S03 | [[Screens/S03 Magic-Link gesendet]] | ja | ja, naechster Schritt muss klar sein | Bauen | copy-kritischer Zustand |
|
||||
| S04 | [[Screens/S04 2FA Code eingeben]] | ja | ja, Security-Schritt | Bauen | eigener Auth-Schritt |
|
||||
| V01 | [[Varianten/V01 Login falsche Daten]] | teilweise | ja, sensibler Fehlertext | Bauen | Copy nicht Dev ueberlassen |
|
||||
| V02 | [[Varianten/V02 Login mit mCaptcha]] | teilweise | ja, Feld/Struktur kommt hinzu | Bauen | Captcha-Slot muss sichtbar sein |
|
||||
| V03 | [[Varianten/V03 2FA gesperrt]] | ja | ja, Blocker | Bauen | Nutzer braucht klare Loesung |
|
||||
| D01 | Trust Device | nein | nein | Wiederverwenden | Checkbox in S04 |
|
||||
| D02 | Login erfolgreich | nein | nein | Raus | nur Weiterleitung |
|
||||
| D03 | Admin nach Login | nein | Rollen-Outcome | Nur dokumentieren | siehe `WF-P2 Workspace Auswahl`; UI-Begriff ist Workspace |
|
||||
| D04 | Konto erstellen Link | nein | Navigation zu anderem Flow | Wiederverwenden | Link in S01, Signup ist eigenes Paket |
|
||||
| D05 | E-Mail-Pre-Screen | nein | zusaetzlicher Schritt | Raus | fuer v1 nicht noetig |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| Magic-Link gesendet | ja | Nutzer muss wissen, was als Naechstes passiert |
|
||||
| Falsche Login-Daten | ja | neutraler Sicherheitstext, keine Account-Enumeration |
|
||||
| mCaptcha nach 3 Versuchen | ja | Layout aendert sich, Anti-Abuse sichtbar |
|
||||
| 2FA gesperrt | ja | starker Blocker, Loesung muss klar sein |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | [[Screens/S01 Login]] | Auth Form | Bauen | `/login` | Validiert |
|
||||
| S02 | [[Screens/S02 Magic-Link anfordern]] | Auth Form | Bauen | von S01 | Validiert |
|
||||
| S03 | [[Screens/S03 Magic-Link gesendet]] | Auth Feedback | Bauen | nach S02 | Validiert |
|
||||
| S04 | [[Screens/S04 2FA Code eingeben]] | Auth Security | Bauen | nach S01 | Validiert |
|
||||
| V01 | [[Varianten/V01 Login falsche Daten]] | Auth Error | Bauen | Variante von S01 | Validiert |
|
||||
| V02 | [[Varianten/V02 Login mit mCaptcha]] | Auth Error | Bauen | Variante von S01 | Validiert |
|
||||
| V03 | [[Varianten/V03 2FA gesperrt]] | Auth Blocker | Bauen | Variante von S04 | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
Hauptflow:
|
||||
|
||||
```text
|
||||
S01 Login -> S04 2FA Code eingeben -> Outcome
|
||||
```
|
||||
|
||||
Magic-Link Branch:
|
||||
|
||||
```text
|
||||
S01 Login -> S02 Magic-Link anfordern -> S03 Magic-Link gesendet
|
||||
```
|
||||
|
||||
Login-Varianten:
|
||||
|
||||
```text
|
||||
S01 Login
|
||||
|
|
||||
v
|
||||
V01 Login falsche Daten
|
||||
|
||||
S01 Login
|
||||
|
|
||||
v
|
||||
V02 Login mit mCaptcha
|
||||
```
|
||||
|
||||
2FA-Variante:
|
||||
|
||||
```text
|
||||
S04 2FA Code eingeben
|
||||
|
|
||||
v
|
||||
V03 2FA gesperrt
|
||||
```
|
||||
|
||||
Outcome nach erfolgreichem Login:
|
||||
|
||||
| Rolle | Ziel |
|
||||
|---|---|
|
||||
| Normale Rolle | Home/App |
|
||||
| Admin | Tenant-/Workspace-Auswahl oder Admin-Startpunkt |
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
- [[Screens/S01 Login]]
|
||||
- [[Screens/S02 Magic-Link anfordern]]
|
||||
- [[Screens/S03 Magic-Link gesendet]]
|
||||
- [[Screens/S04 2FA Code eingeben]]
|
||||
- [[Varianten/V01 Login falsche Daten]]
|
||||
- [[Varianten/V02 Login mit mCaptcha]]
|
||||
- [[Varianten/V03 2FA gesperrt]]
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Jeder Screen ist mit Umsetzung markiert.
|
||||
- [x] Jedes sichtbare Feld hat eine Datenquelle.
|
||||
- [x] Jeder Button hat eine Aktion.
|
||||
- [x] Banner/Inline-Meldungen sind dokumentiert.
|
||||
- [x] Toasts/Action-Feedback sind dokumentiert.
|
||||
- [x] Relevante Zustaende sind beschrieben.
|
||||
- [x] Rollen-Outcome ist dokumentiert.
|
||||
- [x] Offene Fragen sind sichtbar.
|
||||
- [x] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
id: M01
|
||||
screen: Admin kontaktieren
|
||||
typ: Auth Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von V02
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/dd67e352-227f-4ff9-b20e-8396ede1ffe5/edit"
|
||||
---
|
||||
|
||||
# M01 — Admin kontaktieren
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer kann aus dem 2FA-Blocker heraus eine kurze Nachricht an den Workspace-Admin senden.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Kleines Modal im Auth-/Recovery-Kontext.
|
||||
|
||||
## Daten
|
||||
|
||||
- Account-E-Mail aus Reset-Kontext
|
||||
- Nachricht an Admin
|
||||
- optional technische Kontextdaten: Reset angefordert, 2FA nicht verfuegbar
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Nachricht senden
|
||||
- Modal schliessen / abbrechen
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kurz erklaeren, dass der Admin nach Identitaetspruefung helfen kann.
|
||||
- Kein Support-Pfad in v1.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nachricht wurde an den Admin gesendet.
|
||||
- Nachricht konnte nicht gesendet werden. Bitte erneut versuchen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Standard | Textarea leer oder vorbefuellt | Bauen |
|
||||
| Senden | Button loading | Wiederverwenden |
|
||||
| Fehler | Nachricht konnte nicht gesendet werden | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- gueltiger Reset-Kontext
|
||||
- Account hat aktive 2FA
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/dd67e352-227f-4ff9-b20e-8396ede1ffe5/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Der Button `Admin kontaktieren` in V02 oeffnet dieses Modal. Es gibt keinen separaten Support-CTA.
|
||||
+67
@@ -0,0 +1,67 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
id: M02
|
||||
screen: Wiederherstellungscode eingeben
|
||||
typ: Auth Modal
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: von V02
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/a5f09736-66ba-4ceb-9cc3-e8bae98c33bc/edit"
|
||||
---
|
||||
|
||||
# M02 — Wiederherstellungscode eingeben
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer kann einen zuvor gespeicherten Wiederherstellungscode nutzen, um die verlorene 2FA sicher zurueckzusetzen.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Kleines Security-Modal im Auth-/Recovery-Kontext.
|
||||
|
||||
## Daten
|
||||
|
||||
- Wiederherstellungscode
|
||||
- Reset-Token / Reset-Kontext
|
||||
- Account-ID aus Reset-Kontext
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Code pruefen und 2FA zuruecksetzen
|
||||
- abbrechen
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Wiederherstellungscodes funktionieren nur, wenn sie vorher gespeichert wurden.
|
||||
- Jeder Code ist nur einmal nutzbar.
|
||||
- Nach erfolgreicher Nutzung muss 2FA neu eingerichtet werden.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- 2FA wurde zurueckgesetzt.
|
||||
- Wiederherstellungscode ist ungueltig oder wurde bereits verwendet.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Standard | Code-Eingabe leer | Bauen |
|
||||
| Laden | Code wird geprueft | Wiederverwenden |
|
||||
| Fehler | Code falsch/abgelaufen/bereits verwendet | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- gueltiger Reset-Kontext
|
||||
- Account hat aktive 2FA
|
||||
- Wiederherstellungscode ist gueltig und noch nicht verwendet
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/a5f09736-66ba-4ceb-9cc3-e8bae98c33bc/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Nach erfolgreicher Pruefung wird die alte 2FA zurueckgesetzt und der Nutzer kann in `WF-P2 Set Password` fortfahren. Danach sollte ein neues 2FA-Setup verpflichtend angestossen werden.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
id: S01
|
||||
screen: Passwort Reset anfordern
|
||||
typ: Auth Form
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /forgot-password
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/3ced4ee5-d29a-4897-b12e-1ccdc3e2452a/edit"
|
||||
---
|
||||
|
||||
# S01 — Passwort Reset anfordern
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer fordert einen Link an, um sein Passwort zurueckzusetzen.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / Auth-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail-Adresse
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Reset-Link senden
|
||||
- Abbrechen als kleiner Link -> Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Nicht schreiben: "E-Mail nicht gefunden".
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; nach Absenden geht es zu S02.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | E-Mail-Feld leer | Bauen |
|
||||
| Laden | Link wird angefordert | Wiederverwenden |
|
||||
| E-Mail fehlt/ungueltig | Standardformularfehler | Nur dokumentieren |
|
||||
| Zu viele Anfragen | Rate-Limit | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- oeffentlicher Auth-Einstieg
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Der Screen darf keine Account-Existenz verraten.
|
||||
|
||||
`Abbrechen` ist kein gleichgewichtiger Button, sondern ein kleiner Textlink unter oder neben der Primaeraktion.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
id: S02
|
||||
screen: Reset-Link gesendet
|
||||
typ: Auth Feedback
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /forgot-password sent
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/56bcee87-b6ba-4f2a-abdb-fd9323f9b72b/edit"
|
||||
---
|
||||
|
||||
# S02 — Reset-Link gesendet
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass er sein Postfach pruefen soll.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Status-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail-Adresse, wenn eingegeben
|
||||
- Hinweis auf Postfach und Spam-Ordner
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Link erneut senden
|
||||
- Abbrechen als kleiner Link -> Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Neutraler Text: Wenn ein Konto zu dieser E-Mail existiert, senden wir einen Link.
|
||||
- Keine sichtbare Unterscheidung zwischen bekannter und unbekannter E-Mail.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; der Status ist der Screen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Gesendet | Postfach pruefen | Bauen |
|
||||
| Erneut senden | Button loading | Wiederverwenden |
|
||||
| Rate-Limit | keine harte Fehlermeldung, neutral bleiben | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- S01 wurde abgesendet.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen ist bewusst copy-kritisch. Er schuetzt gegen Account Enumeration.
|
||||
|
||||
`Abbrechen` ist ein kleiner sekundarer Textlink, nicht die Primaeraktion.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
id: S03
|
||||
screen: 2FA bestaetigen
|
||||
typ: Auth Security
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /reset 2fa
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/8792bb49-0460-42b3-89ad-62ec8bea70ba/edit"
|
||||
---
|
||||
|
||||
# S03 — 2FA bestaetigen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer bestaetigt 2FA, bevor er in `WF-P2 Set Password` wechseln darf.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / Auth-Security-Step.
|
||||
|
||||
## Daten
|
||||
|
||||
- 6-stelliger Authenticator-Code
|
||||
- optional Hinweis auf Recovery-Code, falls spaeter erlaubt
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Code bestaetigen
|
||||
- 2FA nicht verfuegbar
|
||||
- neuen Reset-Link anfordern
|
||||
- Abbrechen als kleiner Link -> Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Sicherheitstext: Fuer diesen Account ist 2FA aktiv.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Success-Toast; nach erfolgreicher 2FA geht es zu `WF-P2 Set Password`.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Code eingeben | 2FA-Codefeld sichtbar | Bauen |
|
||||
| Laden | Code wird geprueft | Wiederverwenden |
|
||||
| Code falsch | Inline-Fehler | Nur dokumentieren |
|
||||
| 2FA nicht verfuegbar | siehe V02 | Bauen |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Reset-Link ist gueltig.
|
||||
- Account hat aktive 2FA.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Der Reset-Flow darf aktive 2FA nicht umgehen.
|
||||
|
||||
`Abbrechen` ist ein kleiner sekundarer Textlink.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
id: V01
|
||||
screen: Reset-Link ungueltig
|
||||
typ: Auth Blocker
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /reset invalid
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/5b085f60-cf07-4426-af52-d91ba8716380/edit"
|
||||
---
|
||||
|
||||
# V01 — Reset-Link ungueltig
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass der Reset-Link nicht mehr verwendet werden kann.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Blocker-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- Link ist ungueltig oder abgelaufen
|
||||
- kurzer Hinweis auf neue Link-Anforderung
|
||||
|
||||
## Aktionen
|
||||
|
||||
- neuen Link anfordern
|
||||
- Abbrechen als kleiner Link -> Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Blockertext ohne technische Token-Details.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Blocker ist der Screen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Ungueltig | Link fehlt, Token falsch oder abgelaufen | Bauen |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Reset-Link kann nicht validiert werden.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Technisch ist der Token aktuell ca. 1 Stunde gueltig. Die UI muss keine exakte Dauer nennen, wenn Produkt/Dev das nicht final freigeben.
|
||||
|
||||
`Abbrechen` ist ein kleiner sekundarer Textlink.
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
id: V02
|
||||
screen: 2FA nicht verfuegbar
|
||||
typ: Auth Blocker
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /reset 2fa unavailable
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/5057dbae-f5e2-4b6e-a938-6c10785890de/edit"
|
||||
---
|
||||
|
||||
# V02 — 2FA nicht verfuegbar
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass der Passwort-Reset nicht ohne zweiten Faktor fortgesetzt werden kann und waehlt einen sicheren Recovery-Pfad.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Blocker-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- Hinweis, dass 2FA fuer den Account aktiv ist
|
||||
- Hinweis auf Admin-Kontakt
|
||||
- Hinweis auf Wiederherstellungscode, falls vorhanden
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Admin kontaktieren
|
||||
- 2FA mit Wiederherstellungscode zuruecksetzen
|
||||
- Abbrechen als kleiner Link -> Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Text: Aus Sicherheitsgruenden kann 2FA hier nicht uebersprungen werden.
|
||||
- Keine technische Anleitung zum Umgehen von 2FA.
|
||||
- Wiederherstellungscode ist ein legitimer Recovery-Pfad, kein Bypass.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Blocker bleibt im Screen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| 2FA verloren | Authenticator nicht verfuegbar | Bauen |
|
||||
| Admin kontaktieren | kleines Modal mit Textarea | M01 |
|
||||
| Wiederherstellungscode verwenden | Code eingeben und 2FA zuruecksetzen | M02 |
|
||||
| Kein Admin bekannt | spaeter klaeren | Spaeter |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Account hat aktive 2FA.
|
||||
- Nutzer kann 2FA nicht bestaetigen.
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/5057dbae-f5e2-4b6e-a938-6c10785890de/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen ist wichtig, damit der Developer nicht improvisiert. Der Nutzer bekommt zwei sichere Pfade: Admin kontaktieren oder einen zuvor gespeicherten Wiederherstellungscode verwenden.
|
||||
|
||||
`Abbrechen` ist ein kleiner sekundarer Textlink.
|
||||
@@ -0,0 +1,28 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-blocker","type":"group","x":980,"y":560,"width":1840,"height":620,"label":"Blocker und Recovery"},
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":2440,"height":420,"label":"Hauptflow"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":820,"height":380,"label":"Regeln"},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/S01 Passwort Reset anfordern.md","x":0,"y":0,"width":420,"height":200},
|
||||
{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/S02 Reset-Link gesendet.md","x":640,"y":0,"width":420,"height":200},
|
||||
{"id":"s03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/S03 2FA bestaetigen.md","x":1280,"y":0,"width":420,"height":200},
|
||||
{"id":"outcome-set-password","type":"text","text":"# Outcome\n\nWeiter zu `WF-P2 Set Password`.\n\nDort werden neues Passwort, 2FA-Angebot/Pflicht, Recovery-Hinweis und Abschluss gebaut.","x":1920,"y":0,"width":360,"height":220},
|
||||
{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Varianten/V01 Reset-Link ungueltig.md","x":1080,"y":680,"width":420,"height":200},
|
||||
{"id":"v02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Varianten/V02 2FA nicht verfuegbar.md","x":1700,"y":680,"width":420,"height":200},
|
||||
{"id":"note-security","type":"text","text":"# Security-Regel\n\nUnbekannte E-Mail zeigt denselben Gesendet-Screen wie bekannte E-Mail.\n\nKein Screen `E-Mail nicht gefunden`.","x":0,"y":680,"width":360,"height":200},
|
||||
{"id":"note-2fa","type":"text","text":"# 2FA-Regel\n\nWenn 2FA aktiv ist, muss sie vor Set Password bestaetigt werden.\n\nWenn 2FA nicht verfuegbar ist: Admin kontaktieren oder gespeicherten Wiederherstellungscode verwenden.","x":440,"y":680,"width":360,"height":240},
|
||||
{"id":"m02-recovery","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/M02 Wiederherstellungscode eingeben.md","x":2360,"y":600,"width":420,"height":200},
|
||||
{"id":"m01-admin","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Passwort Reset/Screens/M01 Admin kontaktieren.md","x":2360,"y":920,"width":420,"height":200}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-s02","fromNode":"s01","fromSide":"right","toNode":"s02","toSide":"left","label":"senden"},
|
||||
{"id":"edge-s02-s03","fromNode":"s02","fromSide":"right","toNode":"s03","toSide":"left","label":"Link + 2FA"},
|
||||
{"id":"edge-s03-outcome","fromNode":"s03","fromSide":"right","toNode":"outcome-set-password","toSide":"left","label":"ok"},
|
||||
{"id":"edge-s02-outcome","fromNode":"s02","fromSide":"bottom","toNode":"outcome-set-password","toSide":"bottom","label":"ohne 2FA"},
|
||||
{"id":"edge-s02-v01","fromNode":"s02","fromSide":"bottom","toNode":"v01","toSide":"top","label":"ungueltig"},
|
||||
{"id":"edge-s03-v02","fromNode":"s03","fromSide":"bottom","toNode":"v02","toSide":"top","label":"kein 2FA"},
|
||||
{"id":"edge-v02-m01","fromNode":"v02","fromSide":"right","toNode":"m01-admin","toSide":"left","label":"Admin kontaktieren"},
|
||||
{"id":"edge-v02-m02","fromNode":"v02","fromSide":"right","toNode":"m02-recovery","toSide":"left","label":"Recovery-Code"},
|
||||
{"id":"edge-m02-outcome","fromNode":"m02-recovery","fromSide":"top","toNode":"outcome-set-password","toSide":"bottom","label":"Code ok"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,225 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Passwort Reset
|
||||
typ: Zubringerflow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/5782f3c4-4321-4bb9-b048-990e296897a4/edit"
|
||||
canvas: "02 Wireframes/P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas"
|
||||
---
|
||||
|
||||
# WF-P2 Passwort Reset
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/5782f3c4-4321-4bb9-b048-990e296897a4/edit
|
||||
Canvas: [[WF-P2 Passwort Reset.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
`Passwort Reset` ist ein Zubringerflow zum zentralen `WF-P2 Set Password`.
|
||||
|
||||
Der Nutzer fordert per E-Mail einen Reset-Link an. Nach dem Oeffnen des Links wird, falls fuer den Account 2FA aktiv ist, erst 2FA bestaetigt. Danach fuehrt der Flow in `WF-P2 Set Password`.
|
||||
|
||||
Wenn 2FA nicht mehr verfuegbar ist, bekommt der Nutzer einen klaren Blocker-Screen mit zwei sicheren Pfaden: Admin kontaktieren oder einen zuvor gespeicherten Wiederherstellungscode verwenden.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 / Auth |
|
||||
| Was soll der Nutzer am Ende schaffen? | Passwort-Reset sicher starten und danach in Set Password wechseln |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | Zubringerflow |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, Route `/forgot-password`, Route `/reset`, Passwort-Reset-Mail, Password Policy |
|
||||
| Was ist sicher im Scope? | E-Mail anfordern, Reset-Link gesendet, 2FA-Bestaetigung, Link ungueltig/abgelaufen, 2FA nicht verfuegbar, Admin-Kontakt, Wiederherstellungscode als Recovery-Pfad |
|
||||
| Was ist sicher nicht im Scope? | Neues Passwort setzen, 2FA neu einrichten im Detail, separater externer Kontaktpfad |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | Nutzer sieht bei verlorener 2FA den Admin-Kontakt und kann optional einen gespeicherten Wiederherstellungscode nutzen |
|
||||
| Welche Annahmen sind noch unsicher? | Detailverhalten nach erfolgreichem Recovery-Code: ob 2FA direkt neu eingerichtet werden muss oder nach Set Password erzwungen wird |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 / Auth |
|
||||
| Nutzerrolle | Nutzer ohne aktuelle Session |
|
||||
| Startpunkt | Login -> Passwort vergessen |
|
||||
| Ziel | sicherer Uebergang in `WF-P2 Set Password` |
|
||||
| Haupt-Archetyp | A4 Form + Auth-Status |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Security-Regel | keine User Enumeration: unbekannte E-Mail zeigt denselben Gesendet-Screen |
|
||||
| Out of scope | Passwortformular, 2FA-Setup, Admin-Reset aus Admin UI |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Wie viel Sicherheit braucht der Passwort-Reset, bevor der Nutzer ein neues Passwort setzen darf?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | E-Mail eingeben -> Link gesendet -> Set Password | sehr kurz | zu schwach, wenn 2FA aktiv ist | raus |
|
||||
| B | E-Mail eingeben -> Link gesendet -> 2FA pruefen, falls aktiv -> Set Password | sicherer B2B-Standard | ein zusaetzlicher Schritt bei aktiver 2FA | genommen |
|
||||
| C | Immer Admin/Support oder Recovery-Code vor Set Password | maximal vorsichtig | zu viel Reibung fuer Standard-Reset | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Option B | genommen | Reset bleibt schlank, aber 2FA wird respektiert |
|
||||
| Keine E-Mail-nicht-gefunden-Meldung | genommen | neutraler Gesendet-Screen verhindert Account Enumeration |
|
||||
| 2FA vor Set Password, wenn aktiv | genommen | Reset darf 2FA nicht umgehen |
|
||||
| 2FA nicht verfuegbar als eigener Screen | genommen | Nutzer braucht klare Loesung: Admin kontaktieren oder Wiederherstellungscode verwenden |
|
||||
| Separater externer Kontaktpfad | raus | V1 nutzt nur Admin-Kontakt als Kontaktpfad |
|
||||
| Wiederherstellungscode als Alternative | genommen | Code ist legitimer Recovery-Pfad, wenn er vorher gespeichert wurde und einmalig verwendet wird |
|
||||
| Neues Passwort nicht hier bauen | genommen | liegt im zentralen `WF-P2 Set Password` |
|
||||
| Abbrechen als kleiner Link | genommen | Reset-Flow kann jederzeit ueber kleinen Textlink zum Login verlassen werden |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer klickt im Login auf Passwort vergessen.
|
||||
2. Nutzer gibt E-Mail ein.
|
||||
3. Nutzer sieht neutralen Screen: Reset-Link gesendet.
|
||||
4. Nutzer oeffnet Link aus der E-Mail.
|
||||
5. Wenn 2FA aktiv ist, bestaetigt der Nutzer 2FA.
|
||||
6. Danach geht es zu `WF-P2 Set Password`.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- Reset-Link ist ungueltig oder abgelaufen.
|
||||
- 2FA ist aktiv, aber Nutzer hat keinen Zugriff mehr auf Authenticator.
|
||||
- Nutzer kontaktiert Admin mit kurzer Nachricht.
|
||||
- Nutzer nutzt einen gespeicherten Wiederherstellungscode, um 2FA zurueckzusetzen.
|
||||
- E-Mail ist unbekannt: trotzdem S02 anzeigen.
|
||||
- Zu viele Anfragen: Rate-Limit wird dokumentiert, kein eigener Screen fuer v1.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- E-Mail fehlt/ungueltig
|
||||
- Reset-Link ungueltig/abgelaufen
|
||||
- 2FA-Code falsch
|
||||
- 2FA nicht verfuegbar
|
||||
- Wiederherstellungscode ungueltig oder bereits verwendet
|
||||
- Rate-Limit
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Passwort Reset anfordern | Hauptstart | Bauen |
|
||||
| Reset-Link gesendet | copy-kritischer Status, Anti-Enumeration | Bauen |
|
||||
| 2FA bestaetigen | Sicherheitspruefung vor Set Password | Bauen |
|
||||
| Reset-Link ungueltig/abgelaufen | eigener Blocker mit naechster Aktion | Bauen |
|
||||
| 2FA nicht verfuegbar / Admin kontaktieren | Nutzer ist sonst festgefahren | Bauen |
|
||||
| Admin kontaktieren Modal | Nutzer soll dem Admin direkt eine kurze Nachricht senden koennen | Bauen |
|
||||
| Wiederherstellungscode eingeben | sicherer Self-Service-Pfad, wenn Code vorhanden ist | Bauen |
|
||||
| E-Mail fehlt/ungueltig | Formularzustand | Nur dokumentieren |
|
||||
| E-Mail nicht gefunden | darf nicht sichtbar sein | Wiederverwenden S02 |
|
||||
| Zu viele Anfragen | Rate-Limit-Zustand | Nur dokumentieren |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | [[Screens/S01 Passwort Reset anfordern]] | ja | ja, Start des Flows | Bauen | eigener Auth-Einstieg |
|
||||
| S02 | [[Screens/S02 Reset-Link gesendet]] | ja | ja, copy-kritischer Status | Bauen | Anti-Enumeration muss klar gestaltet sein |
|
||||
| S03 | [[Screens/S03 2FA bestaetigen]] | ja | ja, Sicherheitspruefung | Bauen | Reset darf 2FA nicht umgehen |
|
||||
| V01 | [[Varianten/V01 Reset-Link ungueltig]] | ja | ja, Blocker | Bauen | Nutzer braucht neuen Link |
|
||||
| V02 | [[Varianten/V02 2FA nicht verfuegbar]] | ja | ja, Blocker | Bauen | Nutzer muss Admin kontaktieren oder Recovery-Code nutzen koennen |
|
||||
| M01 | [[Screens/M01 Admin kontaktieren]] | ja | ja, Kontaktpfad | Bauen | kleines Modal mit Textarea an Admin |
|
||||
| M02 | [[Screens/M02 Wiederherstellungscode eingeben]] | ja | ja, Security Recovery | Bauen | Code pruefen und 2FA sicher zuruecksetzen |
|
||||
| D01 | E-Mail fehlt/ungueltig | nein | nein | Nur dokumentieren | Standardformular |
|
||||
| D02 | E-Mail nicht gefunden | nein | Sicherheit | Wiederverwenden | immer S02 anzeigen |
|
||||
| D03 | Zu viele Anfragen | nein | technischer Schutz | Nur dokumentieren | Meldung im S01/S02-Kontext |
|
||||
| D04 | 2FA-Code falsch | nein | nein | Nur dokumentieren | Inline-Fehler in S03 |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| Reset-Link gesendet | ja | Nutzer muss wissen, dass auch unbekannte E-Mails gleich behandelt werden, ohne es direkt so zu sagen |
|
||||
| Reset-Link ungueltig | ja | naechste Aktion muss klar sein |
|
||||
| 2FA nicht verfuegbar | ja | starker Blocker, Admin-Kontakt oder Wiederherstellungscode notwendig |
|
||||
| Admin-Nachricht | ja | Nutzer braucht klare Erwartung, was an Admin gesendet wird |
|
||||
| Wiederherstellungscode | ja | Muss klar als vorher gespeicherter, einmalig nutzbarer Code erklaert werden |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | [[Screens/S01 Passwort Reset anfordern]] | Auth Form | Bauen | `/forgot-password` | Validiert |
|
||||
| S02 | [[Screens/S02 Reset-Link gesendet]] | Auth Feedback | Bauen | nach S01 | Validiert |
|
||||
| S03 | [[Screens/S03 2FA bestaetigen]] | Auth Security | Bauen | nach Reset-Link, falls 2FA aktiv | Validiert |
|
||||
| V01 | [[Varianten/V01 Reset-Link ungueltig]] | Auth Blocker | Bauen | Link-Fehler | Validiert |
|
||||
| V02 | [[Varianten/V02 2FA nicht verfuegbar]] | Auth Blocker | Bauen | Variante von S03 | In Subframe |
|
||||
| M01 | [[Screens/M01 Admin kontaktieren]] | Auth Modal | Bauen | von V02 | In Subframe |
|
||||
| M02 | [[Screens/M02 Wiederherstellungscode eingeben]] | Auth Modal | Bauen | von V02 | In Subframe |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
Hauptflow:
|
||||
|
||||
```text
|
||||
S01 Passwort Reset anfordern -> S02 Reset-Link gesendet -> E-Mail-Link -> S03 2FA bestaetigen -> WF-P2 Set Password
|
||||
```
|
||||
|
||||
Ohne aktive 2FA:
|
||||
|
||||
```text
|
||||
S02 Reset-Link gesendet -> E-Mail-Link -> WF-P2 Set Password
|
||||
```
|
||||
|
||||
Blocker:
|
||||
|
||||
```text
|
||||
E-Mail-Link -> V01 Reset-Link ungueltig
|
||||
S03 2FA bestaetigen -> V02 2FA nicht verfuegbar
|
||||
V02 2FA nicht verfuegbar -> M01 Admin kontaktieren
|
||||
V02 2FA nicht verfuegbar -> M02 Wiederherstellungscode eingeben -> WF-P2 Set Password
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
- [[Screens/S01 Passwort Reset anfordern]]
|
||||
- [[Screens/S02 Reset-Link gesendet]]
|
||||
- [[Screens/S03 2FA bestaetigen]]
|
||||
- [[Varianten/V01 Reset-Link ungueltig]]
|
||||
- [[Varianten/V02 2FA nicht verfuegbar]]
|
||||
- [[Screens/M01 Admin kontaktieren]]
|
||||
- [[Screens/M02 Wiederherstellungscode eingeben]]
|
||||
|
||||
Alle Screens nutzen `Abbrechen` als kleinen sekundaren Link, wenn der Nutzer den Reset-Flow verlassen soll.
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Jeder Screen ist mit Umsetzung markiert.
|
||||
- [x] Jedes sichtbare Feld hat eine Datenquelle.
|
||||
- [x] Jeder Button hat eine Aktion.
|
||||
- [x] Banner/Inline-Meldungen sind dokumentiert.
|
||||
- [x] Relevante Zustaende sind beschrieben.
|
||||
- [x] Zubringer-/Core-Regel ist dokumentiert.
|
||||
- [x] Zurueck-/Abbrechen-Aktion ist dokumentiert.
|
||||
- [x] Offene Fragen sind sichtbar.
|
||||
- [x] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Profil und Sicherheit
|
||||
id: S01
|
||||
screen: Profil Settings
|
||||
typ: Settings
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /settings/profile
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/a99149bf-0e1c-4ba9-ac90-9ac316197e28/edit"
|
||||
---
|
||||
|
||||
# S01 — Profil Settings
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer pflegt seine Profilinformationen und startet bei Bedarf die getrennten Sicherheitsflows fuer Passwort und 2FA.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A6 Settings / Profilformular.
|
||||
|
||||
Subframe-Basis: `Default Page Layout with inner Sidebar` + `Settings Page` mit Subcomponents (`SectionHeader`, `NeutralCard`, `SettingRow`, `Divider`).
|
||||
|
||||
Aktuelle visuelle Richtung: Account-Settings-Layout mit `Basic info` links, `Account security` rechts und `Login info` als breite Karte darunter. In `Basic info` stehen Profilfelder links und Profilbild rechts.
|
||||
|
||||
## Daten
|
||||
|
||||
- Avatar
|
||||
- Name
|
||||
- Telefonnummer
|
||||
- Abteilung
|
||||
- Rolle, read-only
|
||||
- Account-E-Mail, read-only in Login info
|
||||
- 2FA-Status
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Profil speichern
|
||||
- Avatar aendern
|
||||
- Passwort aendern -> `WF-P2 Change Password`
|
||||
- 2FA verwalten -> `WF-P2 2FA Verwalten`
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Rolle ist read-only und wird durch Admin zugewiesen.
|
||||
- Keine Theme- oder Bio-Felder in diesem Screen.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Profil gespeichert: Toast.
|
||||
- Avatar-Upload fehlgeschlagen: Inline/Banner mit Retry.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Normal | Profilfelder sichtbar | Bauen |
|
||||
| Speichern | Button loading | Wiederverwenden |
|
||||
| Profil gespeichert | Erfolgstoast | Nur dokumentieren |
|
||||
| Avatar-Upload fehlgeschlagen | Inline/Banner | Nur dokumentieren |
|
||||
| Flow nicht erreichbar | Passwort-/2FA-Flow kann nicht gestartet werden | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nutzer ist eingeloggt.
|
||||
- Rolle wird nur angezeigt und kann nicht selbst geaendert werden.
|
||||
|
||||
## Subframe
|
||||
|
||||
https://app.subframe.com/f023064a5ca0/design/a99149bf-0e1c-4ba9-ac90-9ac316197e28/edit
|
||||
|
||||
## Notizen
|
||||
|
||||
Theme und Bio sind bewusst nicht Teil dieses Profil-Screens. Security/Sessions bleibt spaeter.
|
||||
|
||||
Die Sicherheitsaktionen sind Trigger zu eigenen Flows, keine eingebetteten Unterseiten:
|
||||
|
||||
- Passwort aendern -> `WF-P2 Change Password`
|
||||
- 2FA verwalten -> `WF-P2 2FA Verwalten`
|
||||
@@ -0,0 +1,16 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":1900,"height":420,"label":"Profil Settings"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":1700,"height":360,"label":"Trigger und Spaeter"},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/Screens/S01 Profil Settings.md","x":0,"y":0,"width":420,"height":200},
|
||||
{"id":"change-password","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Change Password/WF-P2 Change Password.md","x":640,"y":0,"width":420,"height":200},
|
||||
{"id":"manage-2fa","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.md","x":1280,"y":0,"width":420,"height":200},
|
||||
{"id":"note-fields","type":"text","text":"# Profilfelder\n\nEditierbar: Avatar, Name, Telefonnummer, Abteilung.\n\nRead-only: Rolle, wird durch Admin zugewiesen.\n\nRaus: Theme, Bio.","x":0,"y":680,"width":420,"height":220},
|
||||
{"id":"note-security","type":"text","text":"# Security\n\nProfil besitzt keine Passwort- oder 2FA-Screens.\n\nPasswort aendern und 2FA verwalten starten eigene validierte Flows.","x":540,"y":680,"width":420,"height":220},
|
||||
{"id":"note-later","type":"text","text":"# Spaeter\n\nSecurity/Sessions, Trust Devices und Ueberall abmelden bleiben fuer v1 raus.","x":1080,"y":680,"width":420,"height":180}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-change","fromNode":"s01","fromSide":"right","toNode":"change-password","toSide":"left","label":"Passwort aendern"},
|
||||
{"id":"edge-s01-2fa","fromNode":"s01","fromSide":"right","toNode":"manage-2fa","toSide":"left","label":"2FA verwalten"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,199 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Profil und Sicherheit
|
||||
typ: Settings Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/b08776c0-8ef2-4c12-b77c-ae729313f1bc/edit"
|
||||
canvas: WF-P2 Profil und Sicherheit.canvas
|
||||
---
|
||||
|
||||
# WF-P2 Profil und Sicherheit
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/b08776c0-8ef2-4c12-b77c-ae729313f1bc/edit
|
||||
Canvas: [[WF-P2 Profil und Sicherheit.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
Dieses Paket buendelt die Self-Service-Settings aus D-P2: Profil und Trigger zu Sicherheitsflows.
|
||||
|
||||
Profil lebt vollstaendig im Settings-Bereich. Der Einstieg kommt entweder ueber das Profilbild oben rechts in der App-Shell oder ueber die Settings-Navigation. Passwort aendern und 2FA verwalten werden hier nur getriggert, sind aber eigene Flows: `WF-P2 Change Password` und `WF-P2 2FA Verwalten`.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / Profile / Sessions |
|
||||
| Was soll der Nutzer am Ende schaffen? | Profil pflegen und Sicherheitsflows starten |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | Settings-Paket mit Profilscreen und Triggern zu separaten Sicherheitsflows |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP §1 Auth-Screens |
|
||||
| Was ist sicher im Scope? | Settings -> Profil, Einstieg ueber Avatar-Menue/App-Shell, Name, Avatar, Telefon, Abteilung, Rolle read-only, Trigger zu Passwort aendern, Trigger zu 2FA verwalten |
|
||||
| Was ist sicher nicht im Scope? | Sprache wechseln, Admin-RBAC, Konto loeschen, eigentlicher Passwort-aendern-Flow, eigentlicher 2FA-Verwalten-Flow, Security/Sessions-Seite |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | kaum; Admin kann dieselben Self-Service-Sicherheitsaktionen nutzen |
|
||||
| Welche Annahmen sind noch unsicher? | keine fuer Profil; offene 2FA-Fragen liegen in `WF-P2 2FA Verwalten` |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 Auth |
|
||||
| Nutzerrolle | eingeloggter Nutzer |
|
||||
| Admin-Variante | keine eigene UI, ausser Admin-spezifische Navigation |
|
||||
| Normale Rolle | hoechste Rolle unter Admin |
|
||||
| Startpunkt | Profilbild oben rechts in der App-Shell oder Settings-Navigation |
|
||||
| Ziel | Profil pflegen und Sicherheitsflows starten |
|
||||
| Haupt-Archetyp | A6 Settings + A2 Listen |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | Account-Loeschung, Rollen/Gruppen/Mitarbeiter; Security/Sessions-Seite fuer v1 raus; Passwort-aendern-Flow liegt in `WF-P2 Change Password`; 2FA-Verwalten liegt in `WF-P2 2FA Verwalten` |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Wie soll der Nutzer Profil, Passwort und 2FA erreichen?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | Profil als Settings-Unterseite; Passwort und 2FA als Trigger zu eigenen Flows | sauber getrennt, wiederverwendbar, Profil bleibt schlank | mehr Flow-Pakete | genommen |
|
||||
| B | Profil und Security getrennt: `/settings/profile` und `/settings/security` | klare Trennung fuer Sessions/Geraete | aktuell zu breit | raus fuer v1 |
|
||||
| C | Alles in einem grossen globalen Profil-Menue ausserhalb Settings | schneller Einstieg | bricht Settings-Struktur | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Profil lebt in Settings | genommen | Unter Settings gibt es eine Zwischen-/Seitennavigation; Profil ist dort ein Bereich |
|
||||
| Einstieg ueber Profilbild oben rechts | genommen | Avatar-Menue fuehrt zu Profil Settings |
|
||||
| Einstieg ueber Settings-Navigation | genommen | Profil ist auch regulär ueber Settings erreichbar |
|
||||
| Profil-Felder | genommen | Name, Avatar, Telefonnummer, Abteilung editierbar, Rolle read-only |
|
||||
| Theme im Profil | raus | nicht Teil dieses Profil-Screens |
|
||||
| Beschreibung/Bio | raus | nicht Teil dieses Profil-Screens |
|
||||
| Rolle read-only | genommen | Rolle wird durch Admin zugewiesen und im Profil nur angezeigt |
|
||||
| Passwort aendern ist eigener Flow | genommen | Klick startet `WF-P2 Change Password`, nicht direkt `WF-P2 Set Password` |
|
||||
| 2FA verwalten ist eigener Flow | genommen | Klick startet `WF-P2 2FA Verwalten`; UI kann modal sein |
|
||||
| Security/Sessions eigene Seite | raus fuer v1 | erstmal schlank halten |
|
||||
| Sprache bleibt fest DE | genommen | D-P2 explizit: kein Wechsler v1 |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer oeffnet ueber Avatar-Menue oder Settings die Profil Settings.
|
||||
2. Nutzer pflegt Profilfelder wie Name, Avatar, Telefonnummer und Abteilung.
|
||||
3. Nutzer sieht seine Rolle read-only, kann sie aber nicht selbst aendern.
|
||||
4. Nutzer klickt Passwort aendern und startet `WF-P2 Change Password`.
|
||||
5. Nutzer klickt 2FA verwalten und startet `WF-P2 2FA Verwalten`.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- 2FA verwalten: fuehrt zum eigenen Flow `WF-P2 2FA Verwalten`.
|
||||
- Passwort aendern: fuehrt zum eigenen Flow `WF-P2 Change Password`.
|
||||
- Sessions/Geraete-Verwaltung: fuer v1 raus/spaeter.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- Avatar-Upload fehlgeschlagen
|
||||
- Change-Password-Flow nicht erreichbar
|
||||
- 2FA-Verwalten-Flow nicht erreichbar
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| Profil gespeichert | Toast | nein | nein | Erfolg reicht |
|
||||
| Avatar-Upload fehlgeschlagen | Inline/Banner | nein | nein | Retry |
|
||||
| Passwort aendern | Link/Action zu eigenem Flow | ja | nein | startet `WF-P2 Change Password` |
|
||||
| 2FA verwalten | Link/Action zu eigenem Flow | ja | nein | startet `WF-P2 2FA Verwalten` |
|
||||
| Session einzeln abmelden | - | - | nein | raus fuer v1 |
|
||||
| Ueberall abmelden | - | - | nein | raus fuer v1 |
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Profil Settings | D-P2 Hauptscreen | Bauen |
|
||||
| Security / Sessions | fuer v1 zu breit | Raus/Spaeter |
|
||||
| Passwort aendern | Trigger aus Profil | eigener Flow `WF-P2 Change Password` |
|
||||
| 2FA verwalten | Trigger aus Profil | eigener Flow `WF-P2 2FA Verwalten` |
|
||||
| Ueberall abmelden Confirm | Security/Sessions-Thema | Raus/Spaeter |
|
||||
| Trust Devices leer | Security/Sessions-Thema | Raus/Spaeter |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Profil Settings | ja | ja, D-P2 Route/Settings-Bereich | Bauen | Stammdaten, Avatar, Telefon, Abteilung, Rolle read-only, Passwort- und 2FA-Einstiege |
|
||||
| S02 | Security / Sessions | nein | nein fuer v1 | Spaeter | erstmal schlank halten |
|
||||
| D01 | Passwort aendern | ja | ja, Security | Nur dokumentieren | startet eigenes Paket `WF-P2 Change Password` |
|
||||
| D02 | 2FA verwalten | ja | ja, Security | Nur dokumentieren | startet eigenes Paket `WF-P2 2FA Verwalten` |
|
||||
| M03 | Ueberall abmelden Confirm | nein | nein fuer v1 | Spaeter | gehoert zu Security/Sessions |
|
||||
| E01 | Trust Devices leer | nein | nein fuer v1 | Spaeter | gehoert zu Security/Sessions |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| Keine im Profil | nein | 2FA-copy-kritische Zustaende liegen in `WF-P2 2FA Verwalten` |
|
||||
|
||||
### Blockierende Error States
|
||||
|
||||
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
||||
|---|---|---|---|---|
|
||||
| Change-Password-Flow nicht erreichbar | Banner | erneut versuchen | abbrechen | keine Rohfehler |
|
||||
| 2FA-Verwalten-Flow nicht erreichbar | Banner | erneut versuchen | abbrechen | keine Rohfehler |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Profil Settings | Settings | Bauen | `/settings/profile` | Validiert |
|
||||
| S02 | Security / Sessions | Settings/List | Spaeter | `/settings/security` | Spaeter |
|
||||
| D01 | Passwort aendern | Trigger | Nur dokumentieren | von S01 | Validiert |
|
||||
| D02 | 2FA verwalten | Trigger | Nur dokumentieren | von S01 | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
```text
|
||||
App-Shell Avatar-Menue -> S01 Profil Settings
|
||||
Settings Navigation -> S01 Profil Settings
|
||||
S01 Profil Settings -> WF-P2 Change Password
|
||||
S01 Profil Settings -> WF-P2 2FA Verwalten
|
||||
S02 Security / Sessions -> spaeter
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
| ID | Datei |
|
||||
|---|---|
|
||||
| S01 | [[Screens/S01 Profil Settings.md]] |
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Paket ist angelegt.
|
||||
- [x] Hauptscreens aus D-P2 sind erfasst.
|
||||
- [x] Wiederverwendung von Auth-Core ist markiert.
|
||||
- [x] David hat die Kandidaten validiert.
|
||||
- [x] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
id: S01
|
||||
screen: Neues Passwort setzen
|
||||
typ: Auth Form
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: auth-core set-password
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/a745a832-9d89-449d-8756-2147611e41ce/edit"
|
||||
---
|
||||
|
||||
# S01 — Neues Passwort setzen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer setzt ein neues Passwort im zentralen Set-Password-Core-Flow.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / Auth-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- neues Passwort
|
||||
- Passwort bestaetigen
|
||||
- Passwort-Regeln / Staerke
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Passwort setzen
|
||||
- Passwort anzeigen/verbergen
|
||||
- zurueck zum vorherigen Auth-Schritt, wenn der Zubringerflow es erlaubt
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Hinweis, warum ein neues Passwort gesetzt wird, kommt optional vom Zubringerflow.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Success-Toast; nach erfolgreichem Passwort geht es zu 2FA freiwillig oder 2FA Pflicht.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | Passwortfelder leer | Bauen |
|
||||
| Laden | Button loading | Wiederverwenden |
|
||||
| Fehler | Passwort zu schwach / stimmt nicht ueberein | Nur dokumentieren |
|
||||
| Keine Berechtigung | Link/Token ungueltig gehoert in Zubringerflow | Raus |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- gueltiger Zubringer-Kontext vorhanden
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen ist zentral wiederverwendbar. Kontexttexte duerfen vom Zubringerflow kommen.
|
||||
|
||||
Der Zurueck-Button ist eine sekundare Navigation, z. B. wenn Passwort Reset versehentlich geoeffnet wurde.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
id: S02
|
||||
screen: 2FA freiwillig anbieten
|
||||
typ: Auth Decision
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: auth-core set-password 2fa optional
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/379cb0ba-e4e2-4028-b44f-503226cb2e85/edit"
|
||||
---
|
||||
|
||||
# S02 — 2FA freiwillig anbieten
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass 2FA empfohlen ist, aber in diesem Einstieg uebersprungen werden darf.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Decision-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- 2FA-Empfehlung
|
||||
- kurzer Sicherheitsnutzen
|
||||
|
||||
## Aktionen
|
||||
|
||||
- 2FA einrichten
|
||||
- jetzt ueberspringen
|
||||
- zurueck, wenn der Zubringerflow es erlaubt
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Empfehlung ohne Druck: 2FA schuetzt den Account zusaetzlich.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Auswahl fuehrt weiter.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Angebot | 2FA ist empfohlen, aber optional | Bauen |
|
||||
| Uebersprungen | Abschluss mit Hinweis in S06 | Wiederverwenden |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Zubringerflow erlaubt freiwillige 2FA.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen darf nicht wie Pflicht wirken.
|
||||
|
||||
Der Zurueck-Button darf die Primaerentscheidung nicht ueberstrahlen.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
id: S03
|
||||
screen: 2FA erforderlich
|
||||
typ: Auth Decision
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: auth-core set-password 2fa required
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/c3ae9f82-bc80-455c-9c09-0d6791f29d22/edit"
|
||||
---
|
||||
|
||||
# S03 — 2FA erforderlich
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass 2FA fuer diesen Einstieg verpflichtend ist und nicht uebersprungen werden kann.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Decision-Card / Security-Gate.
|
||||
|
||||
## Daten
|
||||
|
||||
- Pflichtgrund optional vom Zubringerflow
|
||||
- Hinweis auf Authenticator-App
|
||||
|
||||
## Aktionen
|
||||
|
||||
- 2FA einrichten
|
||||
- zurueck/abbrechen je Zubringerflow, aber kein 2FA-Skip
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Pflichttext: Fuer diesen Account oder diesen Vorgang ist 2FA erforderlich.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; CTA fuehrt zu S04.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Pflicht | kein Ueberspringen moeglich | Bauen |
|
||||
| Abbruch | zurueck/abbrechen je Zubringerflow | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Zubringerflow setzt 2FA auf Pflicht.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen ist bewusst getrennt von S02.
|
||||
|
||||
Wenn 2FA Pflicht ist, darf Zurueck nicht wie "2FA ueberspringen" wirken.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
id: S04
|
||||
screen: 2FA einrichten
|
||||
typ: Auth Security
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: auth-core set-password 2fa setup
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/54d265e1-a26b-4a3f-a581-4e6da249a060/edit"
|
||||
---
|
||||
|
||||
# S04 — 2FA einrichten
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer richtet 2FA mit Authenticator-App ein und bestaetigt den Code.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / Auth-Setup-Step.
|
||||
|
||||
## Daten
|
||||
|
||||
- QR-Code
|
||||
- Secret / manueller Code optional
|
||||
- 6-stelliger TOTP-Code
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Code bestaetigen
|
||||
- Setup abbrechen, wenn freiwillig und erlaubt
|
||||
- zurueck, wenn der Zubringerflow es erlaubt
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kurz erklaeren, dass eine Authenticator-App benoetigt wird.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Success-Toast; nach erfolgreichem Setup geht es zu S05.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Setup | QR + Codefeld | Bauen |
|
||||
| Laden | Code wird geprueft | Wiederverwenden |
|
||||
| Fehler | Code falsch | Nur dokumentieren |
|
||||
| Gesperrt | siehe V03 | Bauen |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- 2FA wurde gewaehlt oder ist Pflicht.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Wenn 2FA freiwillig war, muss klar sein, ob Abbrechen noch erlaubt ist.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
id: S05
|
||||
screen: Recovery Hinweis
|
||||
typ: Auth Security
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: auth-core set-password recovery
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/e59c847b-0f58-482f-b0fb-ea88493af999/edit"
|
||||
---
|
||||
|
||||
# S05 — Recovery Hinweis
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, wie er den Zugang wiederherstellen kann, falls 2FA spaeter nicht verfuegbar ist.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Feedback-Card / Security-Notice.
|
||||
|
||||
## Daten
|
||||
|
||||
- Recovery-Code oder Recovery-Hinweis
|
||||
- optional Download/Kopieren-Aktion
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Code kopieren
|
||||
- Code herunterladen
|
||||
- "Ich habe den Code gespeichert" bestaetigen
|
||||
- weiter
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Sicherheitshinweis: Recovery-Code sicher speichern.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- "Code kopiert" optional als Inline/Toast.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Hinweis | Recovery sichtbar | Bauen |
|
||||
| Bestaetigung fehlt | Weiter ggf. disabled | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- 2FA wurde eingerichtet.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Offen: Muss der Code aktiv bestaetigt werden oder reicht ein Hinweis?
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
id: S06
|
||||
screen: Abschluss
|
||||
typ: Auth Feedback
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: auth-core set-password done
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/4bd741f3-92a2-495b-4ddb-8db2-670042df98b8/edit"
|
||||
---
|
||||
|
||||
# S06 — Abschluss
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer sieht, dass Passwort und ggf. 2FA erfolgreich abgeschlossen wurden, und wird zum naechsten Ziel gefuehrt.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Feedback-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- Passwort gesetzt
|
||||
- 2FA eingerichtet / uebersprungen / nicht erforderlich
|
||||
- naechstes Ziel aus Zubringerflow
|
||||
|
||||
## Aktionen
|
||||
|
||||
- weiter
|
||||
- zum Login
|
||||
- zur App / Profil-Auswahl, je Kontext
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Bei uebersprungener 2FA: Hinweis, dass 2FA spaeter in Security Settings aktiviert werden kann.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein separater Toast noetig.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Mit 2FA | Passwort + 2FA abgeschlossen | Bauen |
|
||||
| Ohne 2FA | Passwort gesetzt, 2FA uebersprungen/optional | Wiederverwenden |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Passwort wurde erfolgreich gesetzt.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Der konkrete Weiterleitungsbutton kommt vom Zubringerflow.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
id: V03
|
||||
screen: 2FA Setup gesperrt
|
||||
typ: Auth Blocker
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: auth-core set-password 2fa setup locked
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/bd5706b1-92f3-4f7b-84a7-97e045d70162/edit"
|
||||
---
|
||||
|
||||
# V03 — 2FA Setup gesperrt
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass die 2FA-Einrichtung nach zu vielen Fehlversuchen temporaer gesperrt ist und was er tun kann.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Blocker-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- Sperrhinweis
|
||||
- optional Wartezeit
|
||||
- optional Support/Admin-Hinweis
|
||||
|
||||
## Aktionen
|
||||
|
||||
- spaeter erneut versuchen
|
||||
- Support/Admin kontaktieren, falls vorgesehen
|
||||
- zurueck, wenn erlaubt
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarer Blockertext: Zu viele fehlgeschlagene Codes.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Toast; Blocker bleibt im Screen.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Gesperrt | Setup temporaer nicht moeglich | Bauen |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- 2FA Setup wurde zu oft falsch bestaetigt.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Zubringerflow entscheidet, ob Abbruch erlaubt ist oder Admin/Support noetig wird.
|
||||
@@ -0,0 +1,29 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-160,"width":3360,"height":660,"label":"Hauptflow"},
|
||||
{"id":"group-skip","type":"group","x":580,"y":700,"width":600,"height":320,"label":"Optionaler Skip"},
|
||||
{"id":"group-blocker","type":"group","x":1640,"y":700,"width":600,"height":320,"label":"Blocker"},
|
||||
{"id":"group-regel","type":"group","x":2480,"y":700,"width":600,"height":320,"label":"Regel"},
|
||||
{"id":"note-back","type":"text","text":"# Zurueck\n\nSekundare Navigation zurueck zum vorherigen Auth-Schritt, wenn der Zubringerflow es erlaubt.\n\nBeispiel: Passwort Reset versehentlich geoeffnet.","x":0,"y":760,"width":460,"height":220},
|
||||
{"id":"note-skip","type":"text","text":"# Skip\n\nNur bei freiwilliger 2FA.\n\nFuehrt direkt zum Abschluss mit Hinweis, dass 2FA spaeter in Security Settings aktiviert werden kann.","x":660,"y":800,"width":420,"height":200},
|
||||
{"id":"v03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/Varianten/V03 2FA Setup gesperrt.md","x":1740,"y":800,"width":420,"height":200},
|
||||
{"id":"note-regel","type":"text","text":"# Core-Regel\n\nPflicht oder freiwillig kommt vom Zubringerflow.\n\nDer Core versteckt keine Sonderregeln: Reset, Einladung, Admin-Reset, Change Password und Incident dokumentieren ihre eigene Regel im jeweiligen Paket.\n\nNeukunden-Signup ist die Ausnahme: Passwort wird direkt im Signup gesetzt.","x":2580,"y":760,"width":500,"height":280},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/Screens/S01 Neues Passwort setzen.md","x":0,"y":100,"width":420,"height":200},
|
||||
{"id":"s04","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/Screens/S04 2FA einrichten.md","x":1320,"y":100,"width":420,"height":200},
|
||||
{"id":"s05","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/Screens/S05 Recovery Hinweis.md","x":1980,"y":100,"width":420,"height":200},
|
||||
{"id":"s06","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/Screens/S06 Abschluss.md","x":2640,"y":100,"width":420,"height":200},
|
||||
{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/Screens/S02 2FA freiwillig anbieten.md","x":660,"y":240,"width":420,"height":200},
|
||||
{"id":"s03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Set Password/Screens/S03 2FA erforderlich.md","x":660,"y":-40,"width":420,"height":200}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-s02","fromNode":"s01","fromSide":"right","toNode":"s02","toSide":"left","label":"freiwillig"},
|
||||
{"id":"edge-s01-s03","fromNode":"s01","fromSide":"right","toNode":"s03","toSide":"left","label":"Pflicht"},
|
||||
{"id":"edge-s02-s04","fromNode":"s02","fromSide":"right","toNode":"s04","toSide":"left","label":"einrichten"},
|
||||
{"id":"edge-s03-s04","fromNode":"s03","fromSide":"right","toNode":"s04","toSide":"left","label":"einrichten"},
|
||||
{"id":"edge-s04-s05","fromNode":"s04","fromSide":"right","toNode":"s05","toSide":"left","label":"ok"},
|
||||
{"id":"edge-s05-s06","fromNode":"s05","fromSide":"right","toNode":"s06","toSide":"left","label":"weiter"},
|
||||
{"id":"edge-s02-skip","fromNode":"s02","fromSide":"bottom","toNode":"note-skip","toSide":"top","label":"skip"},
|
||||
{"id":"edge-skip-s06","fromNode":"note-skip","fromSide":"right","toNode":"s06","toSide":"bottom","label":"Abschluss"},
|
||||
{"id":"edge-s04-v03","fromNode":"s04","fromSide":"bottom","toNode":"v03","toSide":"top","label":"gesperrt"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,235 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2 / Auth-Core
|
||||
package: WF-P2 Set Password
|
||||
typ: Auth-Core Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit"
|
||||
canvas: "02 Wireframes/P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas"
|
||||
---
|
||||
|
||||
# WF-P2 Set Password
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit
|
||||
Canvas: [[WF-P2 Set Password.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
`Set Password` ist ein zentraler Auth-Core-Flow fuer wiederverwendbare Passwort-Trigger. Er wird von mehreren Zubringerflows genutzt, z. B. Passwort Reset, Einladung, Passwort aendern, Admin-Reset und Security-Incident.
|
||||
|
||||
Ausnahme: Der Neukunden-Signup setzt das Passwort direkt im Signup-Flow, um Reibung im Self-Service-Signup zu reduzieren. Signup ist deshalb kein normaler Zubringer zu diesem Core-Flow.
|
||||
|
||||
Der Nutzer setzt ein neues Passwort und bekommt 2FA entweder freiwillig angeboten oder muss 2FA verpflichtend einrichten.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 / Auth-Core |
|
||||
| Was soll der Nutzer am Ende schaffen? | gueltiges Passwort setzen und 2FA-Status klaeren |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | zentraler Auth-Core-Flow |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, UX-Entscheidung mit Head Development |
|
||||
| Was ist sicher im Scope? | Passwort setzen, 2FA freiwillig, 2FA Pflicht, 2FA Setup, Recovery-Hinweis, Abschluss |
|
||||
| Was ist sicher nicht im Scope? | E-Mail anfordern, Reset-Link gesendet, Neukunden-Signup-Daten, Admin-Ausloeser |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | Nicht im Core selbst; Pflicht/Freiwillig kommt vom Zubringerflow |
|
||||
| Welche Annahmen sind noch unsicher? | genaue 2FA-Methode/Provider, genaue Recovery-Code-Logik |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 / Auth-Core |
|
||||
| Nutzerrolle | Nutzer, der zu einem Passwort-Setzen gezwungen oder eingeladen wurde |
|
||||
| Admin-Variante | Admin-Reset kann bestimmen, ob 2FA Pflicht oder freiwillig ist |
|
||||
| Normale Rolle | hoechste Rolle unter Admin; Core bleibt gleich |
|
||||
| Startpunkt | wird von Zubringerflow gesetzt |
|
||||
| Ziel | neues Passwort + 2FA-Entscheidung/Setup abgeschlossen |
|
||||
| Haupt-Archetyp | A4 Form + A5 Auth-Step |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | Reset-Anforderung, Signup-Formular, Admin-Trigger |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
Screen-Listen entstehen erst nach dem Brainstorming. Hier wurde entschieden, ob `Set Password` nur ein Passwort-Screen oder ein gefuehrter Sicherheits-Setup-Flow ist.
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Soll `Set Password` nur ein Passwort-Screen sein oder ein zentraler Sicherheitsflow mit Passwort + 2FA + Abschluss?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | Nur Passwort setzen | sehr einfach | 2FA wird nicht gefuehrt | raus |
|
||||
| B | Passwort setzen + 2FA anbieten | flexibel | Pflicht-2FA braucht Sonderlogik | teilweise |
|
||||
| C | Gefuehrter Security-Setup: Passwort + 2FA + Recovery + Abschluss | B2B-sicher, klar, wiederverwendbar | mehr Screens | genommen |
|
||||
| D | Eigener Set-Password-Flow pro Einstieg | maximal spezifisch | unuebersichtlich, viel Dopplung | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Option C | genommen | zentraler B2B-Security-Flow |
|
||||
| 2FA immer sichtbar machen | genommen | mindestens anbieten |
|
||||
| 2FA freiwillig und 2FA Pflicht trennen | genommen | zwei verschiedene UX-Momente |
|
||||
| Pflicht/Freiwillig kommt vom Zubringerflow | genommen | z. B. Reset, Einladung, Admin-Reset |
|
||||
| Neukunden-Signup ist Ausnahme | genommen | Passwort wird dort direkt im Signup gesetzt |
|
||||
| Recovery-Hinweis bauen | genommen | sicherheitskritisch |
|
||||
| Zurueck-Button bei versehentlichem Einstieg | genommen | sekundare Navigation zurueck zum vorherigen Auth-Schritt, z. B. Reset Password |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer kommt aus einem Zubringerflow.
|
||||
2. Nutzer setzt ein neues Passwort.
|
||||
3. Flow prueft, ob 2FA Pflicht oder freiwillig ist.
|
||||
4. Nutzer richtet 2FA ein oder ueberspringt, falls erlaubt.
|
||||
5. Nutzer sieht Recovery-/Sicherheitshinweis.
|
||||
6. Nutzer erreicht Abschluss und wird weitergeleitet.
|
||||
|
||||
Der Nutzer kann den Flow ueber eine sekundare Zurueck-/Abbrechen-Aktion verlassen, solange noch keine sicherheitskritische Aktion abgeschlossen wurde und der Zubringerflow es erlaubt.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- 2FA freiwillig: Nutzer kann einrichten oder ueberspringen.
|
||||
- 2FA Pflicht: Nutzer kann nicht ueberspringen.
|
||||
- Zurueck/Abbrechen: Nutzer kann bei versehentlichem Einstieg zum vorherigen Auth-Schritt zurueck.
|
||||
- 2FA Setup wird nach zu vielen Versuchen gesperrt.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- Passwort zu schwach
|
||||
- 2FA-Code falsch
|
||||
- 2FA Setup gesperrt
|
||||
- Recovery-Hinweis nicht bestaetigt, falls Pflicht
|
||||
|
||||
### Offene Fragen
|
||||
|
||||
- Welche 2FA-Methode ist v1 final? TOTP/Authenticator ist wahrscheinlich.
|
||||
- Muss Recovery-Code aktiv bestaetigt werden oder reicht Hinweis?
|
||||
- Welche Zubringerflows setzen 2FA auf Pflicht?
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Neues Passwort setzen | Hauptschritt | Bauen |
|
||||
| 2FA freiwillig anbieten | Nutzer darf ueberspringen | Bauen |
|
||||
| 2FA erforderlich | Pflichtzustand, kein Skip | Bauen |
|
||||
| 2FA einrichten | QR/Code/Bestaetigung | Bauen |
|
||||
| Recovery-Code / Sicherheitshinweis | wichtig nach 2FA Setup | Bauen |
|
||||
| Abschluss | klares Ende + Weiterleitung | Bauen |
|
||||
| Zurueck/Abbrechen | wichtig bei versehentlichem Reset-Einstieg | Als Aktion dokumentieren |
|
||||
| Passwort zu schwach | Formularzustand | Nur dokumentieren |
|
||||
| 2FA-Code falsch | Formularzustand | Nur dokumentieren |
|
||||
| 2FA Setup gesperrt | sicherheitskritischer Blocker | Bauen |
|
||||
| 2FA uebersprungen | Ergebniszustand | in Abschluss integrieren |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | [[Screens/S01 Neues Passwort setzen]] | ja | ja, Hauptschritt | Bauen | zentraler Einstieg in Core |
|
||||
| S02 | [[Screens/S02 2FA freiwillig anbieten]] | ja | ja, freiwillige Entscheidung | Bauen | anderer UX-Moment als Pflicht |
|
||||
| S03 | [[Screens/S03 2FA erforderlich]] | ja | ja, Pflicht ohne Skip | Bauen | klarer Sicherheitszwang |
|
||||
| S04 | [[Screens/S04 2FA einrichten]] | ja | ja, Setup mit Code | Bauen | eigener Setup-Schritt |
|
||||
| S05 | [[Screens/S05 Recovery Hinweis]] | ja | ja, sicherheitskritisch | Bauen | Recovery muss verstanden werden |
|
||||
| S06 | [[Screens/S06 Abschluss]] | ja | ja, Ende und Weiterleitung | Bauen | klares Abschlussfeedback |
|
||||
| V01 | Passwort zu schwach | nein | nein | Nur dokumentieren | A4 Formularzustand |
|
||||
| V02 | 2FA-Code falsch | nein | nein | Nur dokumentieren | Inline-Fehler in S04 |
|
||||
| V03 | [[Varianten/V03 2FA Setup gesperrt]] | ja | ja, Blocker | Bauen | Nutzer braucht Loesung |
|
||||
| D01 | 2FA uebersprungen | nein | Ergebniszustand | Wiederverwenden | anderer Text in S06 |
|
||||
| D02 | Zurueck/Abbrechen | nein | Aktion je Zubringerflow | Nur dokumentieren | kein eigener Screen |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| 2FA erforderlich | ja | Pflicht darf nicht wie Empfehlung wirken |
|
||||
| 2FA freiwillig | ja | Angebot muss klar, aber nicht noetigend sein |
|
||||
| Recovery-Hinweis | ja | sicherheitskritisch |
|
||||
| Abschluss | ja | Weiterleitung und Status muessen klar sein |
|
||||
| 2FA Setup gesperrt | ja | starker Blocker |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | [[Screens/S01 Neues Passwort setzen]] | Auth Form | Bauen | Core Start | Validiert |
|
||||
| S02 | [[Screens/S02 2FA freiwillig anbieten]] | Auth Decision | Bauen | nach S01 | Validiert |
|
||||
| S03 | [[Screens/S03 2FA erforderlich]] | Auth Decision | Bauen | nach S01 | Validiert |
|
||||
| S04 | [[Screens/S04 2FA einrichten]] | Auth Security | Bauen | nach S02/S03 | Validiert |
|
||||
| S05 | [[Screens/S05 Recovery Hinweis]] | Auth Security | Bauen | nach S04 | Validiert |
|
||||
| S06 | [[Screens/S06 Abschluss]] | Auth Feedback | Bauen | Flow-Ende | Validiert |
|
||||
| V03 | [[Varianten/V03 2FA Setup gesperrt]] | Auth Blocker | Bauen | Variante von S04 | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
Hauptflow mit 2FA freiwillig:
|
||||
|
||||
```text
|
||||
S01 Neues Passwort setzen -> S02 2FA freiwillig anbieten -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss
|
||||
```
|
||||
|
||||
Freiwillig ueberspringen:
|
||||
|
||||
```text
|
||||
S02 2FA freiwillig anbieten -> S06 Abschluss
|
||||
```
|
||||
|
||||
2FA Pflicht:
|
||||
|
||||
```text
|
||||
S01 Neues Passwort setzen -> S03 2FA erforderlich -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss
|
||||
```
|
||||
|
||||
Blocker:
|
||||
|
||||
```text
|
||||
S04 2FA einrichten -> V03 2FA Setup gesperrt
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
- [[Screens/S01 Neues Passwort setzen]]
|
||||
- [[Screens/S02 2FA freiwillig anbieten]]
|
||||
- [[Screens/S03 2FA erforderlich]]
|
||||
- [[Screens/S04 2FA einrichten]]
|
||||
- [[Screens/S05 Recovery Hinweis]]
|
||||
- [[Screens/S06 Abschluss]]
|
||||
- [[Varianten/V03 2FA Setup gesperrt]]
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Jeder Screen ist mit Umsetzung markiert.
|
||||
- [x] Jedes sichtbare Feld hat eine Datenquelle.
|
||||
- [x] Jeder Button hat eine Aktion.
|
||||
- [x] Banner/Inline-Meldungen sind dokumentiert.
|
||||
- [x] Toasts/Action-Feedback sind dokumentiert.
|
||||
- [x] Relevante Zustaende sind beschrieben.
|
||||
- [x] Zubringer-/Core-Regel ist dokumentiert.
|
||||
- [x] Zurueck-/Abbrechen-Aktion ist dokumentiert.
|
||||
- [x] Offene Fragen sind sichtbar.
|
||||
- [x] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Signup
|
||||
id: S01
|
||||
screen: Signup
|
||||
typ: Auth Form
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: /signup
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/06728fec-3070-4084-ba6d-72301cf5cb09/edit"
|
||||
---
|
||||
|
||||
# S01 - Signup
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer erstellt einen neuen Account und legt den ersten Workspace-Kontext minimal an.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form / Auth-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- E-Mail
|
||||
- Passwort
|
||||
- Vorname
|
||||
- Nachname
|
||||
- Firmenname als Platzhalter fuer Workspace-/Firmenkontext
|
||||
- Captcha
|
||||
- AGB-Checkbox
|
||||
- Datenschutz-Checkbox
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Account erstellen
|
||||
- Einloggen, falls bereits Konto vorhanden
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kein permanenter Banner im Normalzustand.
|
||||
- Firmenname bleibt in v1 bewusst schlank und wird spaeter durch echte Workspace-/Firmendaten erweitert.
|
||||
- Legal-Hinweise muessen direkt bei den Checkboxen verlinkt sein.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Success-Toast; erfolgreicher Submit fuehrt zu S03.
|
||||
- Loading am Primaerbutton waehrend Submit/Captcha-Pruefung.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | leeres Signup-Formular | Bauen |
|
||||
| Laden | Submit/Captcha-Pruefung laeuft | Wiederverwenden |
|
||||
| E-Mail existiert | Inline mit Link zu Login/Passwort vergessen | Nur dokumentieren |
|
||||
| Passwort zu schwach | Inline-Policy am Passwortfeld | Nur dokumentieren |
|
||||
| Passwort in Breach-Liste | Inline/Banner am Passwortfeld | Nur dokumentieren |
|
||||
| Legal fehlt | Inline-Fehler bei Checkboxen | Nur dokumentieren |
|
||||
| Captcha fehlgeschlagen | Inline-Fehler/Captcha neu laden | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- keine aktive Rolle vor Signup
|
||||
- AGB und Datenschutz muessen bestaetigt sein
|
||||
- E-Mail-Bestaetigung ist Pflicht, bevor der Signup abgeschlossen wird
|
||||
|
||||
## Outcome
|
||||
|
||||
- Weiter zu [[S03 E-Mail bestaetigen]].
|
||||
- Passwort wird fuer Neukunden direkt in diesem Signup-Flow gesetzt.
|
||||
- `WF-P2 Set Password` wird hier nicht angesteuert.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Der Signup ist nur der v1-Test-/Basis-Schnitt. Firmen-/Workspace-Wizard, Billing, USt-ID, Branding, Team-Einladung, Templates, Integrationen und CRM-/Pipeline-Konfiguration liegen im Backlog.
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Signup
|
||||
id: S02
|
||||
screen: Signup erfolgreich / Workspace wird vorbereitet
|
||||
typ: Auth Feedback
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: nach E-Mail-Bestaetigung
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/afd1aaba-bbd5-4887-ab48-05cfc506bd11/edit"
|
||||
---
|
||||
|
||||
# S02 - Signup erfolgreich / Workspace wird vorbereitet
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer sieht nach bestaetigter E-Mail, dass Account und Workspace vorbereitet werden, bevor er in die App weitergeleitet wird.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Feedback-Card mit Ladezustand.
|
||||
|
||||
## Daten
|
||||
|
||||
- Name oder E-Mail des Nutzers optional
|
||||
- Workspace-/Firmenname optional
|
||||
- technischer Provisioning-Status optional
|
||||
|
||||
## Aktionen
|
||||
|
||||
- automatische Weiterleitung in die App
|
||||
- Erneut versuchen, falls Vorbereitung fehlschlaegt
|
||||
- Support kontaktieren, falls Wiederholung nicht hilft
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kurz und ruhig formulieren: Workspace wird vorbereitet.
|
||||
- Kein technischer Detailtext, solange alles laeuft.
|
||||
- Wenn die Vorbereitung sofort fertig ist, darf dieser Screen technisch uebersprungen werden.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Kein Success-Toast; der Screen selbst ist das Feedback.
|
||||
- Bei automatischer Weiterleitung kein zusaetzlicher Toast notwendig.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Vorbereitung laeuft | Spinner/Ladefeld, kurzer Status | Bauen |
|
||||
| Sofort fertig | Screen kann uebersprungen werden | Wiederverwenden |
|
||||
| Provisioning langsam | Status bleibt sichtbar, keine Panik-Copy | Nur dokumentieren |
|
||||
| Provisioning-Fehler | Banner mit Retry und Support-Link | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- E-Mail wurde bestaetigt
|
||||
- Account wurde angelegt
|
||||
- erster Workspace wird angelegt/finalisiert
|
||||
|
||||
## Outcome
|
||||
|
||||
- Weiter in die App bzw. zum ersten Workspace.
|
||||
- Nutzer ist initialer Admin dieses Workspaces.
|
||||
- Auto-SHK-Seed wird vorbereitet, sofern technisch noetig.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen existiert als sichtbarer Lade-/Vorbereitungspfad. Wenn technisch kein sichtbares Warten entsteht, darf die App ihn automatisch skippen.
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Signup
|
||||
id: S03
|
||||
screen: E-Mail bestaetigen
|
||||
typ: Auth Feedback
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: nach Signup
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/24000611-7b0a-4cc0-81bf-10395b652367/edit"
|
||||
---
|
||||
|
||||
# S03 - E-Mail bestaetigen
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Nutzer versteht, dass der Signup erst abgeschlossen werden kann, nachdem er seine E-Mail bestaetigt hat.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
Auth-Feedback-Card.
|
||||
|
||||
## Daten
|
||||
|
||||
- eingegebene E-Mail-Adresse
|
||||
- Hinweis auf Postfach und Spam-Ordner
|
||||
|
||||
## Aktionen
|
||||
|
||||
- E-Mail erneut senden
|
||||
- E-Mail-Adresse aendern
|
||||
- Abbrechen / zurueck zum Login
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Klarstellen: Ohne bestaetigte E-Mail ist der Signup nicht abgeschlossen.
|
||||
- Hinweis, dass der Link im Postfach geoeffnet werden muss.
|
||||
- Keine technische Erklaerung zum Provisioning auf diesem Screen.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Nach erneutem Senden: kurzer Inline-Status oder Button-Loading.
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Gesendet | Postfach pruefen | Bauen |
|
||||
| Erneut senden | Button loading / kurzer Inline-Status | Wiederverwenden |
|
||||
| Link abgelaufen | erneutes Senden anbieten | Nur dokumentieren |
|
||||
| Rate-Limit | neutraler Hinweis und warten | Nur dokumentieren |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- S01 wurde erfolgreich abgesendet
|
||||
- E-Mail-Bestaetigung ist Pflicht
|
||||
|
||||
## Outcome
|
||||
|
||||
- Nach Klick auf den E-Mail-Link weiter zu [[S02 Signup erfolgreich Workspace wird vorbereitet]].
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
Dieser Screen blockiert den Abschluss des Signups, bis die E-Mail bestaetigt wurde. Danach startet der Vorbereitungspfad fuer Workspace/Account.
|
||||
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-120,"width":2960,"height":460,"label":"Signup Hauptflow"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":2960,"height":430,"label":"Regeln und Backlog"},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Signup/Screens/S01 Signup.md","x":0,"y":0,"width":420,"height":210},
|
||||
{"id":"note-password","type":"text","text":"# Passwort-Regel\n\nNeukunden setzen das Passwort direkt in S01.\n\n`WF-P2 Set Password` bleibt fuer Einladung, Reset, Change Password, Admin-Reset und Security-Incidents reserviert.","x":0,"y":680,"width":560,"height":230},
|
||||
{"id":"note-backlog","type":"text","text":"# Backlog\n\nMehrstufiges Onboarding, echte Firmen-/Workspace-Daten, Billing, USt-ID, Branding, Team-Einladung, Templates, Integrationen und CRM-/Pipeline-Setup spaeter ausbauen.","x":2340,"y":680,"width":500,"height":230},
|
||||
{"id":"outcome-app","type":"text","text":"# App-Start\n\nWeiter in den ersten Workspace.\n\nSignup-Ersteller ist initialer Workspace-Admin.","x":2460,"y":0,"width":360,"height":210},
|
||||
{"id":"note-provisioning","type":"text","text":"# Vorbereitung\n\nS02 zeigt Spinner/Ladefeld fuer `Workspace wird vorbereitet`.\n\nWenn technisch nichts sichtbar laedt, darf S02 automatisch uebersprungen werden.","x":1540,"y":680,"width":500,"height":230},
|
||||
{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Signup/Screens/S02 Signup erfolgreich Workspace wird vorbereitet.md","x":1560,"y":0,"width":480,"height":210},
|
||||
{"id":"s03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Signup/Screens/S03 E-Mail bestaetigen.md","x":760,"y":0,"width":420,"height":210},
|
||||
{"id":"note-email","type":"text","text":"# E-Mail-Regel\n\nS03 ist Pflicht.\n\nOhne bestaetigte E-Mail ist der Signup nicht abgeschlossen.","x":840,"y":680,"width":420,"height":210}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-s03","fromNode":"s01","fromSide":"right","toNode":"s03","toSide":"left","label":"Signup absenden"},
|
||||
{"id":"edge-s03-s02","fromNode":"s03","fromSide":"right","toNode":"s02","toSide":"left","label":"E-Mail-Link bestaetigt"},
|
||||
{"id":"edge-s02-app","fromNode":"s02","fromSide":"right","toNode":"outcome-app","toSide":"left","label":"bereit"},
|
||||
{"id":"edge-s03-app-skip","fromNode":"s03","fromSide":"bottom","toNode":"outcome-app","toSide":"bottom","label":"S02 skip, wenn sofort fertig"},
|
||||
{"id":"edge-s01-password","fromNode":"s01","fromSide":"bottom","toNode":"note-password","toSide":"top","label":"Passwort direkt"},
|
||||
{"id":"edge-s03-email","fromNode":"s03","fromSide":"bottom","toNode":"note-email","toSide":"top","label":"Pflicht"},
|
||||
{"id":"edge-s02-provisioning","fromNode":"s02","fromSide":"bottom","toNode":"note-provisioning","toSide":"top","label":"Ladezustand"},
|
||||
{"id":"edge-s02-backlog","fromNode":"s02","fromSide":"bottom","toNode":"note-backlog","toSide":"top","label":"spaeter ausbauen"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,255 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Signup
|
||||
typ: Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/5bb64c72-46af-46a8-84dd-5b4ac6bcfcfe/edit"
|
||||
canvas: "02 Wireframes/P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas"
|
||||
---
|
||||
|
||||
# WF-P2 Signup
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/5bb64c72-46af-46a8-84dd-5b4ac6bcfcfe/edit
|
||||
Canvas: [[WF-P2 Signup.canvas]]
|
||||
Stand: 2026-06-24
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
Dieses Paket klaert den Self-Service-Signup fuer HiveGrid.
|
||||
|
||||
Der Signup ist fuer v1 bewusst ein minimaler Test-/Basis-Signup, kein Wizard. Er soll grundsaetzlich Account und ersten Workspace erstellen koennen, damit die App nutzbar und testbar ist.
|
||||
|
||||
Wichtig: Dieser Signup ist fachlich noch nicht der finale volle Signup. Spaeter muss er deutlich ausgebaut werden. Firmenname ist in v1 nur ein Platzhalter fuer den Workspace-/Firmenkontext; Billing, USt-ID, Branding, Team, Onboarding und weitere Firmendaten kommen spaeter.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / Identitaet & Mandantentrennung |
|
||||
| Was soll der Nutzer am Ende schaffen? | Account und Workspace anlegen und danach in den ersten sicheren Einstieg kommen |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | kleiner Signup-Flow mit Hauptformular und wichtigen Blocker-/Feedback-Zustaenden |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP §1 Auth-Screens |
|
||||
| Was ist sicher im Scope? | E-Mail, Passwort innerhalb des Signup-Flows, Vorname, Nachname, Firmenname als Platzhalter, Captcha, AGB-/Datenschutz-Checkbox, Auto-SHK-Seed |
|
||||
| Was ist sicher nicht im Scope? | USt-ID, Rechnungsdaten, Logo/Branding, Mitglieder einladen, Template-Auswahl, CRM-/Pipeline-Konfiguration, mehrstufiger Onboarding-Wizard, Tenant-Auswahl nach Login, Admin-Rollenverwaltung |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | Signup-Ersteller wird initialer Tenant-Admin; weitere Rollen kommen spaeter ueber Mitarbeiter/Admin-RBAC |
|
||||
| Welche Annahmen sind noch unsicher? | Keine fuer v1; spaeterer Ausbau ist im Backlog markiert |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 Auth |
|
||||
| Nutzerrolle | neuer Nutzer ohne Account |
|
||||
| Admin-Variante | erster Nutzer wird Tenant-Admin |
|
||||
| Normale Rolle | nicht relevant im Signup selbst |
|
||||
| Startpunkt | `/signup`, Link aus Login |
|
||||
| Ziel | Tenant/Workspace + erster User angelegt, sicherer Folgepfad klar |
|
||||
| Haupt-Archetyp | A4 Form |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | Onboarding-Checkliste, Demo-Daten, detaillierter Firmen-Wizard, Billing-/USt-Daten, Branding, Team-Setup |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Soll Signup als einzelnes Formular gebaut werden oder als mehrstufiger Wizard?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | Ein schlankes Formular mit Account, minimalem Firmen-Platzhalter und Rechtlichem | schnell, gut fuer Testzugang, wenig Reibung | spaeter fachlich unvollstaendig | genommen |
|
||||
| B | Mehrstufiger Wizard Account -> Firma -> Rechtliches -> Setup | ruhiger pro Schritt | widerspricht v1-Schnitt, hoeherer Aufwand | raus fuer v1, spaeterer Ausbau |
|
||||
| C | Einladung-only, kein Self-Service | kontrollierter Vertriebspfad | D-P2 fordert Self-Service-Signup | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Ein Formular, kein Wizard | genommen | entspricht D-P2 und SCREEN-MAP |
|
||||
| Minimaler Test-/Basis-Signup | genommen | Ziel ist erstmal grundsaetzlich Accounts/Workspaces erstellen zu koennen |
|
||||
| Firmenname nur als Platzhalter | genommen | spaeter kommen echte Workspace-/Firmen-/Billing-Daten dazu |
|
||||
| Captcha im Signup | genommen | Anti-Spam/Schutz fuer Self-Service-Signup |
|
||||
| Legal-Consent sichtbar im Formular | genommen | AGB und Datenschutz sind vor Submit notwendig |
|
||||
| Passwort im Signup verankert | genommen | Ausnahme fuer Neukunden-Signup, damit moeglichst wenig Reibung entsteht |
|
||||
| `WF-P2 Set Password` nicht fuer Signup | genommen | Core-Flow bleibt fuer Einladung, Reset, Change Password, Admin-Reset und spaetere Trigger |
|
||||
| Vorbereitungsscreen nach E-Mail-Bestaetigung | genommen | S02 zeigt, dass Workspace/Account vorbereitet wird; kann technisch uebersprungen werden, wenn alles sofort fertig ist |
|
||||
| E-Mail-Bestaetigung vor Abschluss | genommen | Signup kann ohne bestaetigte E-Mail nicht final abgeschlossen werden |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer oeffnet `/signup`.
|
||||
2. Nutzer gibt E-Mail, Passwort, Vorname, Nachname und Firmenname/Workspace-Platzhalter ein.
|
||||
3. Nutzer loest Captcha und bestaetigt AGB/Datenschutz.
|
||||
4. Nutzer sendet Signup ab.
|
||||
5. Nutzer muss die E-Mail bestaetigen, bevor der Signup abgeschlossen wird.
|
||||
6. Danach legt/finalisiert das System Workspace/Tenant und ersten Admin-User.
|
||||
7. Nutzer sieht S02 `Workspace wird vorbereitet`, falls Provisioning/Laden sichtbar ist.
|
||||
8. Wenn kein sichtbares Laden noetig ist, kann S02 technisch uebersprungen werden und direkt in die App fuehren.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- Passwort ist zu schwach oder in Breach-Liste.
|
||||
- Firmen-/Tenant-Slug ist reserviert oder bereits vergeben.
|
||||
- Legal-Checkbox fehlt.
|
||||
- Tenant-Provisioning laeuft noch.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- E-Mail bereits registriert
|
||||
- Passwort durch Policy blockiert
|
||||
- Legal-Consent fehlt
|
||||
- reservierter Tenant-Slug
|
||||
- Provisioning-Fehler beim Tenant/Seed
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| Passwort zu schwach | Inline | ja | nein | A4-Validierung, klare Policy |
|
||||
| Passwort in Breach-Liste | Inline/Banner im Formular | ja | nein | sicherheitskritisch, aber kein eigener Screen |
|
||||
| E-Mail existiert bereits | Inline + Link zu Login/Reset | ja | nein | keine Account-Enumeration ausserhalb Signup uebertreiben |
|
||||
| Legal-Consent fehlt | Inline | ja | nein | Nutzer kann direkt korrigieren |
|
||||
| Tenant-Slug reserviert/vergeben | Inline | ja | nein | Alternativvorschlag anzeigen |
|
||||
| Signup erfolgreich / Workspace wird vorbereitet | Screen mit Ladezustand oder App-Redirect | nein | ja | Screen bauen, aber bei sofort fertigem Workspace ueberspringbar |
|
||||
| Provisioning-Fehler | Banner | ja | nein | Retry/Kontakt anbieten |
|
||||
|
||||
### S01 Validierter Minimalumfang
|
||||
|
||||
| Feld / Element | Status | Notiz |
|
||||
|---|---|---|
|
||||
| E-Mail | rein | Pflichtfeld |
|
||||
| Passwort | rein | direkt im Signup-Flow verankert, inklusive Staerke-/Breach-Feedback |
|
||||
| Vorname | rein | Pflichtfeld fuer Basisprofil |
|
||||
| Nachname | rein | Pflichtfeld fuer Basisprofil |
|
||||
| Firmenname | rein als Platzhalter | erzeugt Workspace-/Tenant-Kontext, spaeter deutlich ausbauen |
|
||||
| Captcha | rein | Anti-Spam/Schutz |
|
||||
| AGB-Checkbox | rein | Pflicht |
|
||||
| Datenschutz-Checkbox | rein | Pflicht |
|
||||
| USt-ID | raus v1 | spaeter in Workspace/Billing-Settings |
|
||||
| Rechnungsdaten | raus v1 | spaeter Billing |
|
||||
| Logo/Branding | raus v1 | spaeter Branding/Workspace-Settings |
|
||||
| Mitglieder einladen | raus v1 | spaeter Admin RBAC/Checklist |
|
||||
| Template-Auswahl | raus v1 | spaeter Onboarding-Ausbau |
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Signup | Hauptformular | Bauen |
|
||||
| Signup erfolgreich / Workspace wird vorbereitet | klaert Folgepfad und Auto-SHK-Seed | Bauen |
|
||||
| E-Mail bestaetigen | Pflicht, sonst ist Signup nicht abgeschlossen | Bauen |
|
||||
| Passwort/Breach blockiert | Sicherheitsfeedback | Nur dokumentieren |
|
||||
| Tenant-Slug reserviert/vergeben | korrigierbarer Formularfehler | Nur dokumentieren |
|
||||
| Legal-Consent fehlt | korrigierbarer Formularfehler | Nur dokumentieren |
|
||||
| Provisioning-Fehler | technischer Fehler mit Retry | Nur dokumentieren |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Signup | ja | ja, Hauptformular | Validiert | minimaler Test-/Basis-Signup mit E-Mail, Passwort, Name, Firmenname-Platzhalter, Captcha und Legal |
|
||||
| S02 | Signup erfolgreich / Workspace wird vorbereitet | ja | ja, Folgepfad nach E-Mail-Bestaetigung | Validiert | eigener Lade-/Vorbereitungsscreen; bei sofort fertigem Workspace technisch ueberspringbar |
|
||||
| S03 | E-Mail bestaetigen | ja | ja, Auth-Sicherheitsentscheidung | Validiert | Pflicht, sonst ist Signup nicht abgeschlossen |
|
||||
| D01 | Passwort zu schwach/Breach | nein | nein | Nur dokumentieren | Inline-Zustand in S01 |
|
||||
| D02 | Slug/Firma reserviert | nein | nein | Nur dokumentieren | Inline-Zustand in S01 |
|
||||
| D03 | Legal-Consent fehlt | nein | nein | Nur dokumentieren | Inline-Zustand in S01 |
|
||||
| D04 | Provisioning-Fehler | nein | ja, technischer Blocker | Nur dokumentieren | Banner mit Retry reicht voraussichtlich |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| Passwort in Breach-Liste | nein | Formulierung muss klar, aber nicht technisch sein |
|
||||
| Legal-Consent | nein | muss vor Submit eindeutig sein |
|
||||
| Workspace wird vorbereitet | ja | eigener Lade-/Feedbackscreen nach E-Mail-Bestaetigung, ueberspringbar wenn sofort fertig |
|
||||
|
||||
### Blockierende Error States
|
||||
|
||||
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
||||
|---|---|---|---|---|
|
||||
| E-Mail existiert bereits | Inline | Einloggen | Passwort vergessen | Kein Sackgassen-Text |
|
||||
| Slug reserviert/vergeben | Inline | Vorschlag uebernehmen | Firmenname anpassen | Kurz, konkret |
|
||||
| Provisioning-Fehler | Banner | Erneut versuchen | Support kontaktieren | Keine Rohfehler |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
S01 ist als minimaler Test-/Basis-Signup validiert. S03 E-Mail bestaetigen ist Pflicht und validiert. S02 ist als Vorbereitungsscreen nach E-Mail-Bestaetigung validiert.
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Signup | Auth Form | Bauen | `/signup` | Validiert |
|
||||
| S02 | Signup erfolgreich / Workspace wird vorbereitet | Auth Feedback | Bauen | nach E-Mail-Bestaetigung | Validiert |
|
||||
| S03 | E-Mail bestaetigen | Auth Feedback | Bauen | nach S01 | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
```text
|
||||
S01 Signup -> S03 E-Mail bestaetigen -> E-Mail-Link -> S02 Signup erfolgreich / Workspace wird vorbereitet -> App-Start
|
||||
```
|
||||
|
||||
Hinweis: Wenn der Workspace ohne sichtbares Warten fertig ist, darf S02 technisch uebersprungen werden und direkt in die App fuehren.
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
| ID | Datei |
|
||||
|---|---|
|
||||
| S01 | [[Screens/S01 Signup]] |
|
||||
| S02 | [[Screens/S02 Signup erfolgreich Workspace wird vorbereitet]] |
|
||||
| S03 | [[Screens/S03 E-Mail bestaetigen]] |
|
||||
|
||||
---
|
||||
|
||||
## 10. Backlog / Ausbau
|
||||
|
||||
Diese Punkte muessen spaeter nochmal gross ausgebaut werden. Der v1-Signup ist nur ein schlanker Einstieg, damit Accounts/Workspaces erstellt und getestet werden koennen.
|
||||
|
||||
| Thema | Warum spaeter |
|
||||
|---|---|
|
||||
| Voller Firmen-/Workspace-Step | Rechtsform, Adresse, USt-ID, Rechnungsdaten, Logo, Branding, ggf. weitere Organisationseinstellungen |
|
||||
| Billing/Trial/Plan-Auswahl | gehoert zu P20/Billing, nicht in den Minimal-Signup |
|
||||
| Onboarding-Wizard | v2 laut Planning; v1 nutzt Auto-SHK-Seed und spaeter Checklist/Banner |
|
||||
| Template-/Branchen-Auswahl | echte Templates existieren noch nicht; SHK ist Default |
|
||||
| Mitglieder einladen | nach Signup ueber Admin RBAC / Erste-Schritte-Checklist |
|
||||
| Integrationen verbinden | spaeter In-App-Setup fuer E-Mail, Kalender, Telefonie, Formulare |
|
||||
| CRM-/Pipeline-Konfiguration | spaeter Settings/Onboarding, nicht Signup-Blocker |
|
||||
|
||||
---
|
||||
|
||||
## 11. Handoff-Check
|
||||
|
||||
- [x] Paket ist angelegt.
|
||||
- [x] Screen-Kandidaten sind gesammelt.
|
||||
- [x] Meldungs-/Error-State-Matrix ist ausgefuellt.
|
||||
- [x] Offene Fragen sind sichtbar.
|
||||
- [x] S01 Minimal-Signup ist validiert.
|
||||
- [x] Passwort ist fuer Neukunden-Signup direkt im Signup-Flow verankert.
|
||||
- [x] `WF-P2 Set Password` bleibt fuer Einladung, Reset, Change Password und andere Passwort-Trigger reserviert.
|
||||
- [x] S03 E-Mail bestaetigen ist als Pflichtschritt validiert.
|
||||
- [x] S02 Signup erfolgreich / Workspace wird vorbereitet ist validiert.
|
||||
- [x] Spaeterer Signup-/Onboarding-Ausbau ist im Backlog markiert.
|
||||
- [x] David hat die Kandidaten validiert.
|
||||
- [x] Screen-Dateien sind angelegt.
|
||||
- [x] Canvas ist angelegt.
|
||||
- [ ] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Workspace Auswahl
|
||||
id: S01
|
||||
screen: Workspace Auswahl
|
||||
typ: Auth List
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: "nach Login/2FA fuer Admins; App-Shell Workspace-Dropdown"
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/75d08c0c-571b-4836-8d30-6bc7942fd612/edit"
|
||||
---
|
||||
|
||||
# S01 — Workspace Auswahl
|
||||
|
||||
## Ziel
|
||||
|
||||
Admin oder berechtigte Rolle waehlt den aktiven Workspace aus oder startet den Mikroflow zum Anlegen eines neuen Workspace.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A2 List-View light im Auth-/Shell-Kontext.
|
||||
|
||||
## Daten
|
||||
|
||||
- aktuelle User-ID und Berechtigungen
|
||||
- Liste der letzten 5 Workspaces
|
||||
- Workspace-Name
|
||||
- Workspace-Slug/URL-Kuerzel
|
||||
- Workspace-Status, z. B. aktiv, gesperrt, frozen, suspended
|
||||
- optional letzter Zugriff / zuletzt genutzt
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Workspace auswaehlen
|
||||
- Workspace suchen
|
||||
- Neuen Workspace anlegen
|
||||
- Info-I zu Workspace oeffnen
|
||||
- Logout / zurueck, falls im Auth-Kontext noetig
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Kein permanenter Banner fuer gesperrte Workspaces.
|
||||
- Status kann an der Workspace-Zeile sichtbar sein, aber der Blocker erscheint als Toast beim Oeffnungsversuch.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Workspace gewechselt.
|
||||
- Dieser Workspace kann aktuell nicht geoeffnet werden. Bitte waehle einen anderen Workspace oder kontaktiere einen Admin.
|
||||
- Workspace konnte nicht geoeffnet werden. Bitte erneut versuchen.
|
||||
|
||||
## Meldungsentscheidung
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Umsetzung | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| Admin nach Login | Screen | nein | Bauen | Auswahl erscheint immer |
|
||||
| Berechtigte Rolle nutzt App-Shell-Dropdown | Screen/Dropdown-Einstieg | nein | Dokumentieren | nur wenn Permission vorhanden |
|
||||
| Gesperrter Workspace | Toast | ja | Nur dokumentieren | kein eigener Screen |
|
||||
| Was ist ein Workspace? | Info-I/Popover | nein | In S01 integrieren | kurzer Erklaertext |
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | nicht erwartet, weil Signup/Setup immer Workspace erzeugt | Raus |
|
||||
| Laden | Workspace-Liste wird geladen | Wiederverwenden |
|
||||
| Fehler | Workspace-Liste kann nicht geladen werden | Nur dokumentieren |
|
||||
| Keine Berechtigung | Dropdown/Wechsel nicht anzeigen | Nur dokumentieren |
|
||||
|
||||
## Blockierende Error States
|
||||
|
||||
| Zustand | Was sieht der Nutzer? | Primaeraktion | Sekundare Aktion |
|
||||
|---|---|---|---|
|
||||
| Workspace gesperrt | Toast beim Oeffnungsversuch | anderen Workspace waehlen | Admin kontaktieren |
|
||||
| Auswahl fehlgeschlagen | Banner oder Toast | erneut versuchen | Logout/zurueck |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Admin sieht die Workspace-Auswahl nach Login immer.
|
||||
- Berechtigte Rollen koennen Workspace-Wechsel ueber App-Shell-Dropdown oeffnen.
|
||||
- Normale Nutzer ohne Recht sehen keinen Workspace-Wechsel.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
- UI-Begriff ist `Workspace`.
|
||||
- Technischer Tenant-Begriff bleibt im Hintergrund.
|
||||
- Die Liste zeigt die letzten 5 Workspaces und bietet Suche.
|
||||
- `Neuen Workspace anlegen` fuehrt zu S02.
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Workspace Auswahl
|
||||
id: S02
|
||||
screen: Neuer Workspace anlegen
|
||||
typ: Auth Form
|
||||
umsetzung: Bauen
|
||||
status: In Subframe
|
||||
route: "von Workspace Auswahl oder App-Shell Workspace-Dropdown"
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/design/d1379ff9-f67f-4ccb-a07d-4b13a789cb62/edit"
|
||||
---
|
||||
|
||||
# S02 — Neuer Workspace anlegen
|
||||
|
||||
## Ziel
|
||||
|
||||
Admin legt mit minimalen Daten einen neuen Workspace an. Details wie Logo, Rechnungsdaten und Mitglieder werden spaeter in den Workspace-Einstellungen gepflegt.
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
A4 Form im Auth-/Shell-Kontext.
|
||||
|
||||
## Daten
|
||||
|
||||
- Workspace-Name
|
||||
- Workspace-Slug/URL-Kuerzel
|
||||
- optional Organisations-/Firmenname, falls abweichend
|
||||
- optional Template-Auswahl als vorbereiteter Platzhalter oder Backlog
|
||||
|
||||
Nicht im Flow:
|
||||
|
||||
- Zeitzone
|
||||
- Standort/Land
|
||||
- Logo/Avatar
|
||||
- USt-ID/Rechnungsdaten
|
||||
- Mitglieder einladen/erstellen
|
||||
- Rechtliches/AVV
|
||||
|
||||
## Aktionen
|
||||
|
||||
- Workspace erstellen
|
||||
- Slug-Vorschlag uebernehmen oder bearbeiten
|
||||
- abbrechen / zurueck zur Workspace-Auswahl
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
- Hinweis, dass Logo, Rechnungsdaten und Mitglieder spaeter in den Workspace-Einstellungen gepflegt werden koennen.
|
||||
- Template-Auswahl nur anzeigen, wenn sie als Platzhalter sinnvoll ist; sonst Backlog.
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
- Workspace wurde angelegt.
|
||||
- Workspace konnte nicht angelegt werden. Bitte erneut versuchen.
|
||||
|
||||
## Meldungsentscheidung
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Umsetzung | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| Workspace erfolgreich angelegt | Toast + Redirect | nein | Nur dokumentieren | direkt in neuen Workspace wechseln |
|
||||
| Workspace-Name fehlt | Inline | ja | Nur dokumentieren | Pflichtfeld |
|
||||
| Slug nicht verfuegbar | Inline | ja | Nur dokumentieren | Alternativvorschlag anbieten |
|
||||
| Anlage fehlgeschlagen | Banner | ja | Nur dokumentieren | Retry/Support |
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | Formular ist leer | Bauen |
|
||||
| Laden | Workspace wird angelegt | Wiederverwenden |
|
||||
| Fehler | Anlage fehlgeschlagen | Nur dokumentieren |
|
||||
| Keine Berechtigung | Screen nicht erreichbar / Action nicht sichtbar | Nur dokumentieren |
|
||||
|
||||
## Blockierende Error States
|
||||
|
||||
| Zustand | Was sieht der Nutzer? | Primaeraktion | Sekundare Aktion |
|
||||
|---|---|---|---|
|
||||
| Slug reserviert/vergeben | Inline-Fehler mit Vorschlag | Vorschlag uebernehmen | Slug bearbeiten |
|
||||
| Anlage fehlgeschlagen | Banner | erneut versuchen | abbrechen/Support |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
- Nur Admins oder Rollen mit Workspace-Anlage-Recht.
|
||||
- Normale Nutzer ohne Recht sehen den CTA nicht.
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
- Nach erfolgreicher Anlage kein eigener Erfolgsscreen.
|
||||
- Direkt in den neuen Workspace wechseln und Toast anzeigen.
|
||||
@@ -0,0 +1,20 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":1540,"height":420,"label":"Workspace Auswahl"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":1540,"height":420,"label":"Regeln und Backlog"},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Workspace Auswahl/Screens/S01 Workspace Auswahl.md","x":0,"y":0,"width":420,"height":200},
|
||||
{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Workspace Auswahl/Screens/S02 Neuer Workspace anlegen.md","x":640,"y":0,"width":420,"height":200},
|
||||
{"id":"outcome-app","type":"text","text":"# Outcome\n\nWorkspace wird gesetzt.\n\nNach neuer Anlage direkt in den neuen Workspace wechseln und Toast anzeigen.","x":1200,"y":0,"width":360,"height":210},
|
||||
{"id":"note-admin","type":"text","text":"# Admin-Regel\n\nAdmins sehen Workspace-Auswahl immer, auch bei nur einem Workspace.\n\nBerechtigte Rollen koennen den Wechsel ueber die App-Shell starten.","x":0,"y":680,"width":420,"height":230},
|
||||
{"id":"note-workspace","type":"text","text":"# Workspace-Begriff\n\nUI sagt Workspace, nicht Tenant.\n\nLetzte 5 Workspaces, Suche, Info-I und Neuer-Workspace-CTA sind im Hauptscreen.","x":540,"y":680,"width":420,"height":230},
|
||||
{"id":"note-backlog","type":"text","text":"# Backlog\n\nLogo, USt-ID, Rechnungsdaten, Mitglieder und echte Templates gehoeren spaeter in Workspace-Einstellungen.","x":1080,"y":680,"width":420,"height":210}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-s02","fromNode":"s01","fromSide":"right","toNode":"s02","toSide":"left","label":"Neuen Workspace anlegen"},
|
||||
{"id":"edge-s01-app","fromNode":"s01","fromSide":"right","toNode":"outcome-app","toSide":"left","label":"Workspace auswaehlen"},
|
||||
{"id":"edge-s02-app","fromNode":"s02","fromSide":"right","toNode":"outcome-app","toSide":"left","label":"erstellt"},
|
||||
{"id":"edge-s01-admin","fromNode":"s01","fromSide":"bottom","toNode":"note-admin","toSide":"top","label":"Gate"},
|
||||
{"id":"edge-s01-workspace","fromNode":"s01","fromSide":"bottom","toNode":"note-workspace","toSide":"top","label":"Inhalt"},
|
||||
{"id":"edge-s02-backlog","fromNode":"s02","fromSide":"bottom","toNode":"note-backlog","toSide":"top","label":"spaeter"}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,251 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-P2
|
||||
package: WF-P2 Workspace Auswahl
|
||||
typ: Flow
|
||||
status: In Subframe
|
||||
subframe: "https://app.subframe.com/f023064a5ca0/flow/08d4bebd-5db8-4ea8-ba59-270f88356f93/edit"
|
||||
canvas: "02 Wireframes/P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.canvas"
|
||||
---
|
||||
|
||||
# WF-P2 Workspace Auswahl
|
||||
|
||||
Status: In Subframe
|
||||
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/08d4bebd-5db8-4ea8-ba59-270f88356f93/edit
|
||||
Canvas: [[WF-P2 Workspace Auswahl.canvas]]
|
||||
Stand: 2026-06-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
Dieses Paket nimmt den offenen Login-Punkt auf: Was passiert nach erfolgreicher Authentifizierung, wenn ein Admin oder eine berechtigte Person einen Workspace auswaehlen oder einen neuen Workspace anlegen soll?
|
||||
|
||||
Im UI wird der Begriff `Workspace` verwendet. Technisch kann das weiter dem Tenant-Modell entsprechen. Fuer Admins erscheint die Workspace-Auswahl immer, auch wenn aktuell nur ein Workspace verfuegbar ist. Einen Zustand `ohne Workspace` gibt es nicht: Signup/Setup erzeugt immer mindestens einen Workspace.
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / Mandantentrennung |
|
||||
| Was soll der Nutzer am Ende schaffen? | richtigen Workspace auswaehlen oder einen neuen Workspace anlegen |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | kleiner Post-Login-Flow |
|
||||
| Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP §1 Auth-Screens |
|
||||
| Was ist sicher im Scope? | Workspace-Auswahl fuer Admins/berechtigte Rollen, letzte 5 Workspaces, Suche, neuen Workspace anlegen, Info-I zu Workspace, App-Shell-Dropdown "Workspace wechseln" |
|
||||
| Was ist sicher nicht im Scope? | App-Dashboard, Plattform-Admin, Zustand ohne Workspace |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | Ja: Admins und berechtigte Rollen sehen Workspace-Auswahl/Wechsel; normale Nutzer ohne Recht nicht |
|
||||
| Welche Annahmen sind noch unsicher? | ob Template-Auswahl sichtbar vorbereitet wird oder nur im Backlog bleibt |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | D-P2 Auth |
|
||||
| Nutzerrolle | eingeloggter Nutzer nach Login/2FA |
|
||||
| Admin-Variante | sieht die Workspace-Auswahl immer, inklusive letzter 5 Workspaces, Suche, Neu-anlegen-CTA und Info-I |
|
||||
| Berechtigte Rolle | kann in der App-Shell ueber Dropdown "Workspace wechseln" oeffnen |
|
||||
| Normale Rolle | sieht keinen Workspace-Wechsel, wenn kein Recht vorhanden ist |
|
||||
| Startpunkt | nach Login/2FA fuer Admins; in der App-Shell ueber Workspace-Dropdown fuer Admins/berechtigte Rollen |
|
||||
| Ziel | aktiven Workspace setzen, wechseln oder neuen Workspace anlegen |
|
||||
| Haupt-Archetyp | A2 List-View light + Auth-Shell |
|
||||
| Bespoke-Anteil | nein |
|
||||
| Out of scope | Plattform-Admin, Zustand ohne Workspace, vollstaendiger Workspace-Settings-Bereich |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Braucht Workspace-Auswahl immer einen Screen oder nur bei Mehrdeutigkeit?
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | Fuer Admins immer anzeigen; fuer berechtigte Rollen per App-Shell-Dropdown; normale Nutzer ohne Recht sehen keinen Wechsel | Admin-Kontext bleibt klar, Standardnutzer werden nicht unnoetig gebremst | Rechte-Gate muss dokumentiert werden | genommen |
|
||||
| B | Immer fuer alle Nutzer nach Login anzeigen | sehr explizit | zu viel Reibung fuer normale Single-Workspace-Nutzer | raus |
|
||||
| C | Workspace-Auswahl nur in der Topbar, nie Post-Login | App bleibt schlank | Admin-Start nach Login bleibt unklar | raus |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| Workspace als UI-Begriff | genommen | Tenant bleibt technischer Begriff; im Screen steht Workspace |
|
||||
| Admins sehen Workspace-Auswahl immer | genommen | auch wenn Admin aktuell nur einen Workspace hat |
|
||||
| Berechtigte Rollen koennen Workspace in der App-Shell wechseln | genommen | Dropdown in der Shell, wenn Recht vorhanden |
|
||||
| Normale Nutzer ohne Recht sehen keinen Workspace-Wechsel | genommen | Auswahl/Dropdown ist permission-gated |
|
||||
| Zustand ohne Workspace | raus | Signup/Setup erzeugt immer mindestens einen Workspace |
|
||||
| Letzte 5 Workspaces anzeigen | genommen | schneller Einstieg fuer Admins mit mehreren Workspaces |
|
||||
| Suchfeld anbieten | genommen | ab mehreren Workspaces relevant |
|
||||
| Neuen Workspace anlegen als Mikroflow | genommen | Admin kann von hier einen neuen Workspace starten |
|
||||
| Info-I erklaert Workspace | genommen | kurzer Tooltip/Popover: was ein Workspace ist und was dazugehort |
|
||||
| Gesperrter Workspace | genommen | kein eigener Screen; beim Oeffnungsversuch erscheint ein Toast |
|
||||
| Neuer Workspace angelegt | genommen | direkter Wechsel in neuen Workspace mit Toast; kein eigener Screen |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. Nutzer hat Login/2FA abgeschlossen.
|
||||
2. Admin sieht die Workspace-Auswahl.
|
||||
3. Die letzten 5 Workspaces werden angezeigt.
|
||||
4. Admin sucht oder waehlt einen Workspace.
|
||||
5. App startet im gewaehlten Workspace.
|
||||
|
||||
Mikroflow neuer Workspace:
|
||||
|
||||
1. Admin klickt `Neuen Workspace anlegen`.
|
||||
2. Admin gibt die minimalen Workspace-Daten ein.
|
||||
3. System legt Workspace an.
|
||||
4. Admin landet direkt im neuen Workspace und sieht einen Erfolgstoast.
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- Admin hat genau einen Workspace: Auswahl erscheint trotzdem.
|
||||
- Admin hat mehrere Workspaces: letzte 5 + Suche decken den Fall ab.
|
||||
- Admin will neuen Workspace anlegen: Mikroflow startet aus S01.
|
||||
- Berechtigte Rolle oeffnet Workspace-Wechsel aus der App-Shell.
|
||||
- Workspace ist gesperrt, frozen oder suspended: beim Oeffnungsversuch erscheint ein Toast; kein eigener Screen.
|
||||
- Nutzer hat sehr viele Workspaces: Suche und zuletzt genutzt werden wichtig.
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- alle Workspaces gesperrt
|
||||
- Permission entzogen nach Login
|
||||
- Workspace-Auswahl-Fehler
|
||||
- Workspace-Anlage fehlgeschlagen
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| Admin nach Login | Screen | nein | ja | Auswahl erscheint immer fuer Admin |
|
||||
| Mehrere Workspaces | Screen | nein | ja | letzte 5 + Suche |
|
||||
| Ein Workspace, Admin | Screen | nein | ja | trotzdem Auswahl anzeigen |
|
||||
| Workspace wechseln aus App-Shell | Dropdown/Screen | nein | ja | nur fuer Admins/berechtigte Rollen |
|
||||
| Ein Workspace, normale Rolle ohne Recht | Redirect/kein Dropdown | nein | nein | nur dokumentieren |
|
||||
| Neuen Workspace anlegen | Mikroflow | ja | ja | sehr simples Formular, Details spaeter in Workspace-Einstellungen |
|
||||
| Workspace gesperrt/frozen | Toast | ja | nein | erscheint beim Versuch, den Workspace zu oeffnen |
|
||||
| Auswahl fehlgeschlagen | Banner | ja | nein | Retry reicht |
|
||||
| Workspace-Anlage fehlgeschlagen | Banner | ja | nein | Retry/Support |
|
||||
| Was ist ein Workspace? | Info-Popover | nein | nein | Info-I im Screen |
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| Workspace Auswahl | Hauptscreen fuer Admins und Mehr-Workspace-Nutzer | Bauen |
|
||||
| Workspace wechseln aus App-Shell | Einstieg fuer Admins/berechtigte Rollen innerhalb der App | In S01 dokumentieren |
|
||||
| Neuen Workspace anlegen | eigener kurzer Anlage-Moment | Bauen |
|
||||
| Neuer Workspace angelegt | Erfolg + Wechsel in neuen Workspace | Nur dokumentieren |
|
||||
| Workspace gesperrt/suspended | erklaert blockierten Zugriff | Nur dokumentieren |
|
||||
| Workspace-Info | Info-I / Popover im Hauptscreen | In S01 integrieren |
|
||||
| Ohne Workspace | kein moeglicher Zustand | Raus |
|
||||
| Single-Workspace Redirect fuer normale Rolle ohne Recht | kein eigener Arbeitsmoment | Nur dokumentieren |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | Workspace Auswahl | ja | ja, Post-Login-Entscheidung fuer Admins | Bauen | Admins sehen Auswahl immer; letzte 5, Suche, Neu-CTA, Info-I |
|
||||
| S02 | Neuer Workspace anlegen | ja | ja, eigener Mikroflow | Bauen | Admin braucht einen klaren Anlage-Einstieg |
|
||||
| S03 | Neuer Workspace angelegt | nein | nein, Toast/Redirect reicht | Nur dokumentieren | direkt in neuen Workspace wechseln und Toast anzeigen |
|
||||
| V01 | Workspace gesperrt/suspended | nein | nein, Toast reicht | Nur dokumentieren | beim Oeffnungsversuch Toast anzeigen |
|
||||
| D01 | Ohne Workspace | nein | nein | Raus | Signup/Setup erzeugt immer einen Workspace |
|
||||
| D02 | Genau ein Workspace, normale Rolle ohne Recht | nein | nein | Nur dokumentieren | direkte Weiterleitung / kein Dropdown |
|
||||
| D03 | Workspace-Info | nein | ja, Erklaerung | In S01 integrieren | Info-I/Tooltip/Popover |
|
||||
| D04 | App-Shell Workspace-Dropdown | nein | ja, Navigation/Gate | Nur dokumentieren | Einstieg fuer Admins/berechtigte Rollen |
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| Workspace gesperrt | nein | Toast reicht; muss Status erklaeren ohne Rohsystemsprache |
|
||||
| Workspace-Info | nein | Info-I reicht; Inhalt muss trotzdem formuliert werden |
|
||||
| Neuer Workspace angelegt | nein | direkter Wechsel + Toast reicht |
|
||||
|
||||
### Blockierende Error States
|
||||
|
||||
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
||||
|---|---|---|---|---|
|
||||
| Workspace gesperrt | Toast | anderen Workspace waehlen | Admin kontaktieren | konkreter Status, keine Interna |
|
||||
| Workspace-Anlage fehlgeschlagen | Banner | erneut versuchen | abbrechen/Support | keine Rohfehler |
|
||||
|
||||
### Neuer Workspace: Daten-Outline
|
||||
|
||||
Der Flow soll bewusst simpel bleiben. Details werden spaeter in Workspace-Einstellungen gepflegt.
|
||||
|
||||
| Feld | Pflicht? | Notiz |
|
||||
|---|---|---|
|
||||
| Workspace-Name | ja | sichtbarer Name in Auswahl/App-Shell |
|
||||
| Workspace-Slug/URL-Kuerzel | ja, mit Vorschlag | aus Name generieren, editierbar, Reserved Words blocken |
|
||||
| Organisations-/Firmenname | optional | nur falls abweichend; sonst spaeter in Workspace-Einstellungen |
|
||||
| Template-Auswahl | optional/Platzhalter | vorbereitet, obwohl noch keine Templates existieren; kann auch Backlog bleiben |
|
||||
| Logo/Avatar | spaeter | in Workspace-Einstellungen |
|
||||
| USt-ID/Rechnungsdaten | spaeter | in Workspace-Einstellungen/Billing |
|
||||
| Mitglieder einladen/erstellen | spaeter | in Workspace-Einstellungen bzw. Admin-User-Flow |
|
||||
| Rechtliches/AVV | spaeter/Reuse Signup | nicht erneut im Workspace-Anlageflow |
|
||||
| Standort/Land | raus | alles Deutschland; nicht im Anlageflow |
|
||||
| Zeitzone | raus | alles Deutschland; nicht im Anlageflow |
|
||||
|
||||
V1-Minimum fuer den Screen:
|
||||
|
||||
1. Workspace-Name.
|
||||
2. Slug/URL-Kuerzel mit Vorschlag.
|
||||
3. Optional Organisations-/Firmenname, falls abweichend.
|
||||
4. Optional Template-Auswahl als vorbereiteter Platzhalter oder Backlog.
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
Noch nicht validiert.
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | [[Screens/S01 Workspace Auswahl]] | Auth List | Bauen | nach Login/2FA fuer Admins | Validiert |
|
||||
| S02 | [[Screens/S02 Neuer Workspace anlegen]] | Auth Form | Bauen | von S01 oder App-Shell-Dropdown | Validiert |
|
||||
| D05 | Neuer Workspace angelegt | Toast/Redirect | Nur dokumentieren | nach S02 | Validiert |
|
||||
| V01 | Workspace gesperrt/suspended | Toast | Nur dokumentieren | beim Oeffnungsversuch | Validiert |
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
```text
|
||||
Login/2FA Admin -> S01 Workspace Auswahl -> App
|
||||
Login/2FA normale Rolle mit mehreren Workspaces -> S01 Workspace Auswahl -> App
|
||||
Login/2FA normale Rolle mit einem Workspace -> App
|
||||
S01 Workspace Auswahl -> S02 Neuer Workspace anlegen -> App im neuen Workspace + Toast
|
||||
App-Shell Workspace-Dropdown -> S01 Workspace Auswahl
|
||||
S01 Workspace Auswahl -> Toast Workspace gesperrt/suspended
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
- [[Screens/S01 Workspace Auswahl]]
|
||||
- [[Screens/S02 Neuer Workspace anlegen]]
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [x] Offener Login-Punkt ist als eigenes Paket erfasst.
|
||||
- [x] Brainstorm-Entscheidung Admin/Workspace ist dokumentiert.
|
||||
- [x] Screen-Kandidaten sind gesammelt.
|
||||
- [x] Blockierende Zustaende sind definiert.
|
||||
- [x] UI-Label Workspace ist geklaert.
|
||||
- [x] Ohne-Workspace-Zustand ist rausgenommen.
|
||||
- [x] Neuer-Workspace-Mikroflow ist als Kandidat aufgenommen.
|
||||
- [x] David hat die Kandidaten validiert.
|
||||
- [ ] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,239 @@
|
||||
---
|
||||
kind: tracker
|
||||
project: HiveGrid Screen Project
|
||||
area: Wireframes
|
||||
status: active
|
||||
---
|
||||
|
||||
# Screen Paket Tracker
|
||||
|
||||
Zentrale Uebersicht ueber alle Wireframe-Flows, Screens, Canvas-Dateien und Subframe-Links.
|
||||
|
||||
Diese Datei ist der erste Ort, um zu sehen:
|
||||
|
||||
- welche Flow-Pakete existieren
|
||||
- welcher Status ein Paket hat
|
||||
- welche Screens zu einem Paket gehoeren
|
||||
- wo die Markdown-Dateien liegen
|
||||
- wo Canvas und Subframe verlinkt sind
|
||||
- welche Entscheidungen noch offen sind
|
||||
|
||||
---
|
||||
|
||||
## 1. Flow-Paket-Uebersicht
|
||||
|
||||
| Flow-Paket | Ticket | Bereich | Status | Paket-MD | Canvas | Subframe | Naechster Schritt | Notiz |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| WF-P2 Login und 2FA | D-P2 | Auth | In Subframe | [MD](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.md>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/a457cbaa-9cca-412a-98b2-3bef128338ac/edit>) | Review | Neue Seiten erstellt; keine bestehenden Screens geloescht/bearbeitet |
|
||||
| WF-P2 Set Password | D-P2 / Auth-Core | Auth | In Subframe | [MD](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.md>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit>) | Review | Neue Seiten erstellt; keine bestehenden Screens geloescht/bearbeitet |
|
||||
| WF-P2 Passwort Reset | D-P2 | Auth | In Subframe | [MD](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.md>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/5782f3c4-4321-4bb9-b048-990e296897a4/edit>) | Review | Neue Seiten erstellt; keine bestehenden Screens geloescht/bearbeitet |
|
||||
| WF-P2 Signup | D-P2 | Auth | In Subframe | [MD](<P2 Auth/WF-P2 Signup/WF-P2 Signup.md>) | [Canvas](<P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/5bb64c72-46af-46a8-84dd-5b4ac6bcfcfe/edit>) | Review | Neue Seiten erstellt; Passwort im Signup verankert |
|
||||
| WF-P2 Workspace Auswahl | D-P2 | Auth | In Subframe | [MD](<P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.md>) | [Canvas](<P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/08d4bebd-5db8-4ea8-ba59-270f88356f93/edit>) | Review | Neue Seiten erstellt; Workspace-Auswahl fuer Admins + neuen Workspace anlegen |
|
||||
| WF-P2 Profil und Sicherheit | D-P2 | Auth/Settings | In Subframe | [MD](<P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.md>) | [Canvas](<P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/b08776c0-8ef2-4c12-b77c-ae729313f1bc/edit>) | Review | Neue Seite erstellt; Profil in Settings, Trigger zu Passwort/2FA |
|
||||
| WF-P2 Change Password | D-P2 / Auth-Core | Auth | In Subframe | [MD](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.md>) | [Canvas](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/04767909-3c2f-4236-92a8-b08eaa3f51b7/edit>) | Review | Neue Seiten erstellt; Reauth-Zubringer zu `WF-P2 Set Password` |
|
||||
| WF-P2 2FA Verwalten | D-P2 / Auth-Core | Auth | In Subframe | [MD](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.md>) | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/4de27a18-0e2f-43de-b39b-01a94b0c93b8/edit>) | Review | Neue Seiten erstellt; eigenstaendiger 2FA-Verwalten-Flow |
|
||||
| WF-P2 Admin RBAC | D-P2 | Auth/Admin | In Subframe | [MD](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/42c54a17-9c08-4db3-9306-1449f5b874e4/edit>) | Review | Neue Seiten erstellt; Permission-Bundles als Arbeitsgeruest; Gruppen/Reassign raus |
|
||||
| WF-P2 Konto loeschen | D-P2 | Auth/Settings | In Subframe | [MD](<P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.md>) | [Canvas](<P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas>) | [Subframe](<https://app.subframe.com/f023064a5ca0/flow/6fec2ec6-eab5-4e25-9c9a-90da47a5047a/edit>) | Review | Neue Seiten erstellt; schlanke Loeschungsanfrage unter Settings -> Workspaces |
|
||||
|
||||
---
|
||||
|
||||
## 2. Screen-Uebersicht
|
||||
|
||||
| ID | Screen/Zustand | Paket | Typ | Umsetzung | Status | Route/Ort | MD | Subframe | Canvas |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| S01 | Login | WF-P2 Login und 2FA | Auth Form | Bauen | In Subframe | `/login` | [MD](<P2 Auth/WF-P2 Login und 2FA/Screens/S01 Login.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/389ee115-d9ac-45df-9139-b6a443bcf215/edit>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) |
|
||||
| S02 | Magic-Link anfordern | WF-P2 Login und 2FA | Auth Form | Bauen | In Subframe | von Login | [MD](<P2 Auth/WF-P2 Login und 2FA/Screens/S02 Magic-Link anfordern.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/f22caacd-e7db-4909-8223-e703ad4630d2/edit>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) |
|
||||
| S03 | Magic-Link gesendet | WF-P2 Login und 2FA | Auth Feedback | Bauen | In Subframe | nach Magic-Link-Anforderung | [MD](<P2 Auth/WF-P2 Login und 2FA/Screens/S03 Magic-Link gesendet.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/bd2e7c70-721b-4c88-92d0-7ea59aa8fc57/edit>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) |
|
||||
| S04 | 2FA Code eingeben | WF-P2 Login und 2FA | Auth Security | Bauen | In Subframe | nach Login | [MD](<P2 Auth/WF-P2 Login und 2FA/Screens/S04 2FA Code eingeben.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/9a61f957-0c2e-49d3-9c30-47d9a09a262c/edit>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) |
|
||||
| V01 | Login falsche Daten | WF-P2 Login und 2FA | Auth Error | Bauen | In Subframe | Variante von S01 | [MD](<P2 Auth/WF-P2 Login und 2FA/Varianten/V01 Login falsche Daten.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/2ebdb245-6b2e-4565-8301-d82e1e39a393/edit>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) |
|
||||
| V02 | Login mit mCaptcha | WF-P2 Login und 2FA | Auth Error | Bauen | In Subframe | Variante von S01 | [MD](<P2 Auth/WF-P2 Login und 2FA/Varianten/V02 Login mit mCaptcha.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/a945cd6f-9f0f-473b-ac6f-fdb9b0e2bfaa/edit>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) |
|
||||
| V03 | 2FA gesperrt | WF-P2 Login und 2FA | Auth Blocker | Bauen | In Subframe | Variante von S04 | [MD](<P2 Auth/WF-P2 Login und 2FA/Varianten/V03 2FA gesperrt.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/2db31f2a-eb97-4c99-aa9f-8f77aa6eb4b6/edit>) | [Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>) |
|
||||
| S01 | Neues Passwort setzen | WF-P2 Set Password | Auth Form | Bauen | In Subframe | Auth-Core Start | [MD](<P2 Auth/WF-P2 Set Password/Screens/S01 Neues Passwort setzen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/a745a832-9d89-449d-8756-2147611e41ce/edit>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) |
|
||||
| S02 | 2FA freiwillig anbieten | WF-P2 Set Password | Auth Decision | Bauen | In Subframe | nach S01, wenn 2FA freiwillig | [MD](<P2 Auth/WF-P2 Set Password/Screens/S02 2FA freiwillig anbieten.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/379cb0ba-e4e2-4028-b44f-503226cb2e85/edit>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) |
|
||||
| S03 | 2FA erforderlich | WF-P2 Set Password | Auth Decision | Bauen | In Subframe | nach S01, wenn 2FA Pflicht | [MD](<P2 Auth/WF-P2 Set Password/Screens/S03 2FA erforderlich.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/c3ae9f82-bc80-455c-9c09-0d6791f29d22/edit>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) |
|
||||
| S04 | 2FA einrichten | WF-P2 Set Password | Auth Security | Bauen | In Subframe | nach S02/S03 | [MD](<P2 Auth/WF-P2 Set Password/Screens/S04 2FA einrichten.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/54d265e1-a26b-4a3f-a581-4e6da249a060/edit>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) |
|
||||
| S05 | Recovery Hinweis | WF-P2 Set Password | Auth Security | Bauen | In Subframe | nach S04 | [MD](<P2 Auth/WF-P2 Set Password/Screens/S05 Recovery Hinweis.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/e59c847b-0f58-482f-b0fb-ea88493af999/edit>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) |
|
||||
| S06 | Abschluss | WF-P2 Set Password | Auth Feedback | Bauen | In Subframe | Flow-Ende | [MD](<P2 Auth/WF-P2 Set Password/Screens/S06 Abschluss.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/4bd741f3-92a2-495b-4ddb-8db2-670042df98b8/edit>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) |
|
||||
| V03 | 2FA Setup gesperrt | WF-P2 Set Password | Auth Blocker | Bauen | In Subframe | Variante von S04 | [MD](<P2 Auth/WF-P2 Set Password/Varianten/V03 2FA Setup gesperrt.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/bd5706b1-92f3-4f7b-84a7-97e045d70162/edit>) | [Canvas](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas>) |
|
||||
| S01 | Passwort Reset anfordern | WF-P2 Passwort Reset | Auth Form | Bauen | In Subframe | `/forgot-password` | [MD](<P2 Auth/WF-P2 Passwort Reset/Screens/S01 Passwort Reset anfordern.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/3ced4ee5-d29a-4897-b12e-1ccdc3e2452a/edit>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) |
|
||||
| S02 | Reset-Link gesendet | WF-P2 Passwort Reset | Auth Feedback | Bauen | In Subframe | nach S01 | [MD](<P2 Auth/WF-P2 Passwort Reset/Screens/S02 Reset-Link gesendet.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/56bcee87-b6ba-4f2a-abdb-fd9323f9b72b/edit>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) |
|
||||
| S03 | 2FA bestaetigen | WF-P2 Passwort Reset | Auth Security | Bauen | In Subframe | nach Reset-Link, falls 2FA aktiv | [MD](<P2 Auth/WF-P2 Passwort Reset/Screens/S03 2FA bestaetigen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/8792bb49-0460-42b3-89ad-62ec8bea70ba/edit>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) |
|
||||
| V01 | Reset-Link ungueltig | WF-P2 Passwort Reset | Auth Blocker | Bauen | In Subframe | Link-Fehler | [MD](<P2 Auth/WF-P2 Passwort Reset/Varianten/V01 Reset-Link ungueltig.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/5b085f60-cf07-4426-af52-d91ba8716380/edit>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) |
|
||||
| V02 | 2FA nicht verfuegbar | WF-P2 Passwort Reset | Auth Blocker | Bauen | In Subframe | Variante von S03 | [MD](<P2 Auth/WF-P2 Passwort Reset/Varianten/V02 2FA nicht verfuegbar.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/5057dbae-f5e2-4b6e-a938-6c10785890de/edit>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) |
|
||||
| M01 | Admin kontaktieren | WF-P2 Passwort Reset | Auth Modal | Bauen | In Subframe | von V02 | [MD](<P2 Auth/WF-P2 Passwort Reset/Screens/M01 Admin kontaktieren.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/dd67e352-227f-4ff9-b20e-8396ede1ffe5/edit>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) |
|
||||
| M02 | Wiederherstellungscode eingeben | WF-P2 Passwort Reset | Auth Modal | Bauen | In Subframe | von V02 | [MD](<P2 Auth/WF-P2 Passwort Reset/Screens/M02 Wiederherstellungscode eingeben.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/a5f09736-66ba-4ceb-9cc3-e8bae98c33bc/edit>) | [Canvas](<P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas>) |
|
||||
| S01 | Signup | WF-P2 Signup | Auth Form | Bauen | In Subframe | `/signup` | [MD](<P2 Auth/WF-P2 Signup/Screens/S01 Signup.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/06728fec-3070-4084-ba6d-72301cf5cb09/edit>) | [Canvas](<P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas>) |
|
||||
| S02 | Signup erfolgreich / Workspace wird vorbereitet | WF-P2 Signup | Auth Feedback | Bauen | In Subframe | nach E-Mail-Bestaetigung | [MD](<P2 Auth/WF-P2 Signup/Screens/S02 Signup erfolgreich Workspace wird vorbereitet.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/afd1aaba-bbd5-4887-ab48-05cfc506bd11/edit>) | [Canvas](<P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas>) |
|
||||
| S03 | E-Mail bestaetigen | WF-P2 Signup | Auth Feedback | Bauen | In Subframe | nach Signup | [MD](<P2 Auth/WF-P2 Signup/Screens/S03 E-Mail bestaetigen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/24000611-7b0a-4cc0-81bf-10395b652367/edit>) | [Canvas](<P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas>) |
|
||||
| S01 | Workspace Auswahl | WF-P2 Workspace Auswahl | Auth List | Bauen | In Subframe | nach Login/2FA fuer Admins | [MD](<P2 Auth/WF-P2 Workspace Auswahl/Screens/S01 Workspace Auswahl.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/75d08c0c-571b-4836-8d30-6bc7942fd612/edit>) | [Canvas](<P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.canvas>) |
|
||||
| S02 | Neuer Workspace anlegen | WF-P2 Workspace Auswahl | Auth Form | Bauen | In Subframe | von Workspace Auswahl / App-Shell | [MD](<P2 Auth/WF-P2 Workspace Auswahl/Screens/S02 Neuer Workspace anlegen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/d1379ff9-f67f-4ccb-a07d-4b13a789cb62/edit>) | [Canvas](<P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.canvas>) |
|
||||
| D05 | Neuer Workspace angelegt | WF-P2 Workspace Auswahl | Toast/Redirect | Nur dokumentieren | Validiert | nach S02 | [MD](<P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.md>) | - | - |
|
||||
| V01 | Workspace gesperrt/suspended | WF-P2 Workspace Auswahl | Toast | Nur dokumentieren | Validiert | beim Oeffnungsversuch | [MD](<P2 Auth/WF-P2 Workspace Auswahl/WF-P2 Workspace Auswahl.md>) | - | - |
|
||||
| S01 | Profil Settings | WF-P2 Profil und Sicherheit | Settings | Bauen | In Subframe | `/settings/profile` | [MD](<P2 Auth/WF-P2 Profil und Sicherheit/Screens/S01 Profil Settings.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/a99149bf-0e1c-4ba9-ac90-9ac316197e28/edit>) | [Canvas](<P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.canvas>) |
|
||||
| S02 | Security / Sessions | WF-P2 Profil und Sicherheit | Settings/List | Spaeter | Spaeter | `/settings/security` | [MD](<P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.md>) | - | - |
|
||||
| D01 | Passwort aendern | WF-P2 Profil und Sicherheit | Trigger | Nur dokumentieren | Validiert | von Profil Settings | [MD](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.md>) | - | [Canvas](<P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.canvas>) |
|
||||
| D02 | 2FA verwalten | WF-P2 Profil und Sicherheit | Trigger | Nur dokumentieren | Validiert | von Profil Settings | [MD](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.md>) | - | [Canvas](<P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.canvas>) |
|
||||
| M01 | Identitaet bestaetigen | WF-P2 Change Password | Auth Modal | Bauen | In Subframe | von Profil Settings | [MD](<P2 Auth/WF-P2 Change Password/Screens/M01 Identitaet bestaetigen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/4274da58-939d-414a-b505-b5889911a517/edit>) | [Canvas](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas>) |
|
||||
| D03 | 2FA-Code eingeben | WF-P2 Change Password | Inline-Zustand | Nur dokumentieren | Validiert | in M01, falls 2FA aktiv/Policy | [MD](<P2 Auth/WF-P2 Change Password/Screens/M01 Identitaet bestaetigen.md>) | - | [Canvas](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas>) |
|
||||
| D01 | Neues Passwort setzen | WF-P2 Change Password | Auth-Core Verweis | Wiederverwenden | Validiert | nach Reauth | [MD](<P2 Auth/WF-P2 Set Password/WF-P2 Set Password.md>) | - | [Canvas](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas>) |
|
||||
| D02 | Passwort geaendert | WF-P2 Change Password | Auth-Core Verweis | Wiederverwenden | Validiert | Abschluss im Core | [MD](<P2 Auth/WF-P2 Set Password/Screens/S06 Abschluss.md>) | - | [Canvas](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas>) |
|
||||
| V01 | Zu viele Fehlversuche | WF-P2 Change Password | Auth Blocker | Bauen | In Subframe | nach falscher Reauth | [MD](<P2 Auth/WF-P2 Change Password/Varianten/V01 Zu viele Fehlversuche.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/abb6c78d-416f-4552-ba3a-b80e3f54c998/edit>) | [Canvas](<P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas>) |
|
||||
| M01 | 2FA verwalten | WF-P2 2FA Verwalten | Modal | Bauen | In Subframe | von Profil Settings | [MD](<P2 Auth/WF-P2 2FA Verwalten/Screens/M01 2FA verwalten.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/606baf15-a4cc-468c-b196-c51441f8c6ed/edit>) | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) |
|
||||
| M02 | Device/Token hinzufuegen | WF-P2 2FA Verwalten | Modal | Bauen | In Subframe | von M01 | [MD](<P2 Auth/WF-P2 2FA Verwalten/Screens/M02 Device Token hinzufuegen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/ec8c6a18-c0dd-498e-a79d-177b2a634d28/edit>) | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) |
|
||||
| M03 | 2FA deaktivieren | WF-P2 2FA Verwalten | Modal | Bauen | In Subframe | von M01 | [MD](<P2 Auth/WF-P2 2FA Verwalten/Screens/M03 2FA deaktivieren.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/cfaa0e6a-6656-4363-bba7-7409b9c26bc9/edit>) | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) |
|
||||
| D01 | Device entfernen | WF-P2 2FA Verwalten | Row Action | Nur dokumentieren | Validiert | in M01 | [MD](<P2 Auth/WF-P2 2FA Verwalten/Screens/M01 2FA verwalten.md>) | - | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) |
|
||||
| D02 | 2FA-Code falsch/abgelaufen | WF-P2 2FA Verwalten | Inline-Zustand | Nur dokumentieren | Validiert | in M02/M03 | [MD](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.md>) | - | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) |
|
||||
| D03 | Letztes Device entfernen | WF-P2 2FA Verwalten | Inline/Confirm | Nur dokumentieren | Validiert | in M01 | [MD](<P2 Auth/WF-P2 2FA Verwalten/Screens/M01 2FA verwalten.md>) | - | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) |
|
||||
| D04 | MFA-Aenderung Benachrichtigung | WF-P2 2FA Verwalten | E-Mail/Toast | Nur dokumentieren | Validiert | nach Setup/Remove/Disable | [MD](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.md>) | - | [Canvas](<P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas>) |
|
||||
| S01 | Mitarbeiterliste | WF-P2 Admin RBAC | Admin List | Bauen | In Subframe | `Settings -> Mitarbeiter`, Tab `Mitarbeiter` | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/S01 Mitarbeiterliste.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/a9571d72-15e0-4897-968b-1f700ee4bfbc/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| M01 | Mitarbeiter einladen | WF-P2 Admin RBAC | Modal | Bauen | In Subframe | von S01 | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/0338fed6-2624-4e92-9d42-0b959fafe8c2/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| D01 | Rollen-Dropdown in Mitarbeiterliste | WF-P2 Admin RBAC | Inline-Zustand | Nur dokumentieren | In Subframe | in S01 | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/D01 Rollen-Dropdown in Mitarbeiterliste.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/80f691a7-e8a9-4502-be74-69795066e105/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| M03 | Mitarbeiter deaktivieren | WF-P2 Admin RBAC | Confirm Modal | Bauen | In Subframe | von S01 | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/11e3f3dc-451b-4abb-aedf-3aad63704c51/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| S02 | Rollen und Berechtigungen | WF-P2 Admin RBAC | Settings Subpage | Bauen | In Subframe | `Settings -> Mitarbeiter`, Tab `Rollen und Berechtigungen` | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/S02 Rollen und Berechtigungen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/87c24709-4f22-4181-8543-e21ff169c4d5/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| M02 | Rolle erstellen/bearbeiten | WF-P2 Admin RBAC | Grosses Modal | Bauen | In Subframe | von S02 | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle erstellen bearbeiten.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/3d51deee-0d41-456f-a507-ccfc284e6e0a/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| D03 | Rolle in Nutzung blockiert | WF-P2 Admin RBAC | Admin Blocker | Nur dokumentieren | In Subframe | von S02/M02 | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/99f96d31-4cb5-4d7c-a252-3f8bef9f1b59/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| V01 | Letzter Admin blockiert | WF-P2 Admin RBAC | Admin Blocker | Nur dokumentieren | In Subframe | von S01/M03/Rollenwechsel | [MD](<P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/3e05bfb3-3842-4008-964e-f4c68dea0d9e/edit>) | [Canvas](<P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas>) |
|
||||
| S01 | Settings -> Workspaces / Loeschbereich | WF-P2 Konto loeschen | Settings | Bauen | In Subframe | `/settings/workspaces` | [MD](<P2 Auth/WF-P2 Konto loeschen/Screens/S01 Settings Workspaces Loeschbereich.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/7f54d6e5-df2f-4163-bb36-1310062b2429/edit>) | [Canvas](<P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas>) |
|
||||
| M01 | Loeschung anfragen | WF-P2 Konto loeschen | Modal | Bauen | In Subframe | von S01 | [MD](<P2 Auth/WF-P2 Konto loeschen/Screens/M01 Loeschung anfragen.md>) | [Subframe](<https://app.subframe.com/f023064a5ca0/design/e8454b77-b5bc-4c80-b035-bde4318793e7/edit>) | [Canvas](<P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas>) |
|
||||
| D01 | Anfrage gesendet | WF-P2 Konto loeschen | Toast/Status | Nur dokumentieren | Validiert | nach M01 | [MD](<P2 Auth/WF-P2 Konto loeschen/Screens/S01 Settings Workspaces Loeschbereich.md>) | - | [Canvas](<P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas>) |
|
||||
| D02 | Keine Berechtigung | WF-P2 Konto loeschen | Permission State | Nur dokumentieren | Validiert | in S01 | [MD](<P2 Auth/WF-P2 Konto loeschen/Screens/S01 Settings Workspaces Loeschbereich.md>) | - | [Canvas](<P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas>) |
|
||||
|
||||
---
|
||||
|
||||
## 3. Offene Entscheidungen
|
||||
|
||||
| Paket | Thema | Status | Entscheidung / Frage | Notiz |
|
||||
|---|---|---|---|---|
|
||||
| WF-P2 Set Password | Zentraler Auth-Core-Flow | Genommen | Set Password wird zentraler Flow fuer wiederverwendbare Passwort-Trigger. | Wird von Reset, Einladung, Passwort aendern, Admin-Reset und Security-Incident angesteuert; Neukunden-Signup ist eine Ausnahme und setzt Passwort direkt im Signup |
|
||||
| WF-P2 Set Password | 2FA im Set-Password-Flow | Genommen | 2FA wird immer angeboten. | Ob Pflicht oder freiwillig haengt vom Zubringerflow/Admin-Reset ab |
|
||||
| WF-P2 Set Password | Zurueck-Button | Genommen | Zurueck/Abbrechen bleibt sekundare Navigation. | Kein eigener Screen; konkretes Ziel kommt vom Zubringerflow |
|
||||
| WF-P2 Set Password | Recovery-Code | Offen | Muss der Recovery-Code aktiv bestaetigt werden oder reicht ein Hinweis? | In S05 dokumentiert; spaeter mit Security/Dev klaeren |
|
||||
| WF-P2 Set Password | 2FA-Methode | Offen | Welche 2FA-Methode ist v1 final? | TOTP/Authenticator ist wahrscheinlich |
|
||||
| WF-P2 Passwort Reset | Anti-Enumeration | Genommen | Keine Meldung `E-Mail nicht gefunden`. | Unbekannte E-Mail nutzt denselben S02 Gesendet-Screen |
|
||||
| WF-P2 Passwort Reset | 2FA vor Set Password | Genommen | Wenn 2FA aktiv ist, muss sie vor dem neuen Passwort bestaetigt werden. | Reset darf aktive 2FA nicht umgehen |
|
||||
| WF-P2 Passwort Reset | 2FA nicht verfuegbar | Genommen | Nutzer kann Admin kontaktieren oder einen gespeicherten Wiederherstellungscode verwenden. | V02 plus M01/M02 |
|
||||
| WF-P2 Passwort Reset | Recovery-Code als Alternative | Genommen | Wiederherstellungscode ist ein legitimer Recovery-Pfad, wenn er vorher gespeichert wurde und einmalig verwendet wird. | M02 prueft Code, setzt 2FA zurueck und fuehrt weiter zu `WF-P2 Set Password` |
|
||||
| WF-P2 Login und 2FA | 2FA-Haeufigkeit | Offen | Kommt 2FA bei jedem Login oder nur wenn fuer Account aktiv? | Fuer Wireframe reicht "bei Bedarf"; Dev/Produkt spaeter klaeren |
|
||||
| WF-P2 Login und 2FA | Admin-Ziel | In Planung | Admin-/Mehrworkspace-Ziel wird ueber `WF-P2 Workspace Auswahl` geklaert. | UI-Begriff ist Workspace |
|
||||
| WF-P2 Signup | Signup-Komplexitaet | Genommen | S01 ist ein minimaler Basis-Signup zum Erstellen/Testen von Accounts und Workspaces. | E-Mail, Passwort im Signup, Vorname, Nachname, Firmenname-Platzhalter, Captcha, AGB/Datenschutz; grosser Ausbau spaeter |
|
||||
| WF-P2 Signup | Passwort-Flow | Genommen | Passwort wird fuer Neukunden direkt im Signup gesetzt. | `WF-P2 Set Password` bleibt fuer Einladung, Reset, Change Password und andere Trigger reserviert |
|
||||
| WF-P2 Signup | E-Mail-Bestaetigung | Genommen | Signup kann ohne bestaetigte E-Mail nicht abgeschlossen werden. | S03 ist Pflichtschritt nach S01 |
|
||||
| WF-P2 Signup | Provisioning-Folgepfad | Genommen | S02 zeigt `Workspace wird vorbereitet` mit Ladezustand. | Kann technisch uebersprungen werden, wenn Workspace sofort fertig ist |
|
||||
| WF-P2 Workspace Auswahl | Label | Genommen | Im UI heisst es Workspace. | Tenant bleibt technischer Begriff im Hintergrund |
|
||||
| WF-P2 Workspace Auswahl | Ohne-Workspace-Zustand | Raus | Einen Zustand ohne Workspace gibt es nicht. | Signup/Setup erzeugt immer mindestens einen Workspace |
|
||||
| WF-P2 Workspace Auswahl | Neuer Workspace | Genommen | Neuer Workspace anlegen wird als simpler Mikroflow gebaut. | Minimum: Name, Slug/URL-Kuerzel, optional Organisationsname; Template optional/Backlog; Logo, USt-ID, Rechnungsdaten und Mitglieder spaeter in Einstellungen |
|
||||
| WF-P2 Workspace Auswahl | Anlage-Abschluss | Genommen | Nach Anlage direkt in neuen Workspace wechseln und Toast zeigen. | Kein eigener Erfolgsscreen |
|
||||
| WF-P2 Workspace Auswahl | Gesperrter Workspace | Genommen | Kein eigener Screen; Toast beim Oeffnungsversuch. | Nutzer waehlt anderen Workspace oder kontaktiert Admin |
|
||||
| WF-P2 Profil und Sicherheit | Profil-Ort | Genommen | Profil Settings lebt unter Settings und ist ueber Avatar-Menue/App-Shell erreichbar. | Settings hat eigene Zwischen-/Seitennavigation |
|
||||
| WF-P2 Profil und Sicherheit | Passwort-Trigger | Genommen | Passwort aendern startet eigenes Paket `WF-P2 Change Password`. | Profil ist nur Einstieg, nicht Besitzer des Flows |
|
||||
| WF-P2 Profil und Sicherheit | 2FA-Trigger | Genommen | 2FA verwalten startet eigenes Paket `WF-P2 2FA Verwalten`. | Profil ist nur Einstieg, nicht Besitzer des Flows |
|
||||
| WF-P2 Profil und Sicherheit | Profil-Felder | Genommen | Avatar, Name, Telefonnummer und Abteilung editierbar; Rolle read-only. | Theme und Bio raus |
|
||||
| WF-P2 Profil und Sicherheit | Security/Sessions | Spaeter | Keine eigene Security/Sessions-Seite in v1. | Erstmal schlank halten |
|
||||
| WF-P2 Change Password | Eigenstaendiger Flow | Genommen | Passwort aendern wird als separater wiederverwendbarer Reauth-Zubringer geplant. | Neues Passwort setzen und Abschluss liegen in `WF-P2 Set Password` |
|
||||
| WF-P2 Change Password | Reauth statt E-Mail-Link | Genommen | Eingeloggter Nutzer bestaetigt aktuelles Passwort und ggf. 2FA innerhalb der App-Shell. | Kein E-Mail-Link im eingeloggten Change-Password-Flow |
|
||||
| WF-P2 2FA Verwalten | Eigenstaendiger Flow | Genommen | 2FA verwalten wird als separater wiederverwendbarer Flow geplant. | UI kann modal sein; fachlich eigener Flow |
|
||||
| WF-P2 2FA Verwalten | Schlanker 2FA-Flow | Genommen | 2FA-Code-Eingaben sind Inline-Zustaende; nur Verwaltung, Device/Token hinzufuegen und Deaktivieren sind eigene Modals. | Device entfernen nur Row-Action + Confirm |
|
||||
| WF-P2 Admin RBAC | Gruppen | Raus | Gruppen sind nicht Teil des RBAC-Pakets. | Falls spaeter noetig, eigener Settings-Bereich |
|
||||
| WF-P2 Admin RBAC | Rollenmodell | Genommen | Es gibt vorgebaute Rollen und Admins koennen eigene Rollen anlegen und benennen. | Wichtig fuer Rollen-Editor |
|
||||
| WF-P2 Admin RBAC | Seed-Rollen | Genommen | Geschaeftsfuehrer, Projektleiter, Verwaltung, Vertriebler, Kundensupporter, Monteur als bearbeitbare Startrollen. | fuer v1 ausreichend; Namen koennen spaeter angepasst werden |
|
||||
| WF-P2 Admin RBAC | Settings-Aufteilung | Genommen | `Settings -> Mitarbeiter` wird Oberpunkt; Tabs: `Mitarbeiter`, `Rollen und Berechtigungen`. | Sichtbarer Wireframe-Einstieg; technische Route spaeter abstimmen |
|
||||
| WF-P2 Admin RBAC | Rollenzuweisung | Genommen | In der Mitarbeiterliste gibt es pro Mitarbeiter ein Rollen-Dropdown; Bearbeiten fuehrt zu `Rollen und Berechtigungen`. | Kein eigenes Rollen-Modal aus S01 |
|
||||
| WF-P2 Admin RBAC | Berechtigungen | Genommen | Kein separater Berechtigungen-Tab; Rechtebereiche leben im Tab `Rollen und Berechtigungen` beim Bearbeiten einer Rolle. | Macht das Paket kompakter |
|
||||
| WF-P2 Admin RBAC | Permission-Bundles | Genommen | Bundles bleiben Arbeitsgeruest; im Rollen-Modal wird eine Permission-Zeile mit Ueberschrift, Beschreibung und Zugriffsauswahl vorgebaut. | Finaler Rechtekatalog liegt bei Development |
|
||||
| WF-P2 Admin RBAC | Systemrolle | Genommen | In der UI gibt es nur eine sichtbare Systemrolle: `Admin`. | Andere technische Rollen nicht als normale Screen-Rolle fuehren |
|
||||
| WF-P2 Admin RBAC | Suche/Filter | Genommen | Mitarbeiter-Screen bekommt Suche plus Filter nach Rolle, Abteilung, Status und 2FA; Rollen-Screen bekommt Suche plus Filter nach Typ, Bundle und Nutzung. | Im Paket dokumentiert |
|
||||
| WF-P2 Admin RBAC | Deaktivierung | Genommen | V1 hat nur ein kleines Confirm-Modal; danach Status `Deaktiviert`. | Reassign offener Verantwortlichkeiten ist Backlog |
|
||||
| WF-P2 Admin RBAC | Rollen-Loeschen | Genommen | Rollen koennen nur geloescht werden, wenn keine Mitarbeiter zugewiesen sind; sonst kleines Blocker-Modal. | Ersatzrolle/Bulk-Reassign ist Backlog |
|
||||
| WF-P2 Admin RBAC | Deaktivieren mit Reassign | Backlog | Offene Aufgaben/Projekte/Verantwortlichkeiten werden spaeter uebertragen. | Nicht Teil der aktuellen Screen-Liste |
|
||||
| WF-P2 Admin RBAC | V2-Backlog | Dokumentiert | Reassign, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Rollen-Review, Templates, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz. | Details im Paket-Backlog |
|
||||
| WF-P2 Konto loeschen | Loeschungsanfrage statt direkter Loeschung | Genommen | V1 stellt nur eine Anfrage, keine sofortige technische Loeschung. | Einstieg unter Settings -> Workspaces |
|
||||
| WF-P2 Konto loeschen | Settings -> Workspaces | Genommen | Minimaler Workspaces-Bereich enthaelt Loeschungsanfrage. | Spaeter kann dort mehr Workspace-Verwaltung hinzukommen |
|
||||
| WF-P2 Konto loeschen | Voller Loesch-/Export-Wizard | Backlog | Erklaerung und Datenexport-Hinweis werden in v1 im Modal integriert. | Kein mehrstufiger Wizard jetzt |
|
||||
|
||||
---
|
||||
|
||||
## 4. Backlog / V2 Sammlung
|
||||
|
||||
Diese Liste sammelt Punkte, die in einzelnen Paketen als `Backlog`, `Spaeter` oder bewusst aus v1 herausgeschnitten markiert wurden. Sie ist die zentrale Merkliste fuer eine spaetere v2-/Nachzieh-Runde.
|
||||
|
||||
| Paket | Thema | Status | Notiz |
|
||||
|---|---|---|---|
|
||||
| WF-P2 Set Password | Recovery-Code bestaetigen | Backlog/Klaeren | Entscheiden, ob Nutzer den Recovery-Code aktiv bestaetigen muss oder ob ein Hinweis reicht |
|
||||
| WF-P2 Set Password | 2FA-Methode finalisieren | Backlog/Klaeren | TOTP/Authenticator wahrscheinlich, finaler Provider/Methodenmix spaeter klaeren |
|
||||
| WF-P2 Passwort Reset | Recovery-Code Folgepflicht | Backlog/Klaeren | Nach erfolgreichem Recovery-Code technisch festlegen, ob 2FA direkt vor Set Password oder direkt danach verpflichtend neu eingerichtet wird |
|
||||
| WF-P2 Passwort Reset | Kein Admin bekannt | Backlog/Klaeren | Fallback fuer Nutzer ohne bekannten Admin |
|
||||
| WF-P2 Login und 2FA | 2FA-Haeufigkeit | Backlog/Klaeren | Bei jedem Login, pro Device, pro Risiko oder nur wenn Account/Policy aktiv? |
|
||||
| WF-P2 Login und 2FA | 2FA-Recovery aus Sperrzustand | Backlog | Wiederherstellungs-/Recovery-Pfad aus `2FA gesperrt` spaeter detaillieren |
|
||||
| WF-P2 Signup | Mehrstufiges Onboarding | Backlog | Firmen-/Legal-/Setup-Wizard, USt-ID, Billing, Branding, Team, Template-Auswahl, Integrationen, Onboarding-Checkliste und Demo-Daten nicht Teil des aktuellen Signup-Schnitts |
|
||||
| WF-P2 Workspace Auswahl | Template-Auswahl | Backlog/Optional | Platzhalter moeglich, aber echte Templates existieren noch nicht |
|
||||
| WF-P2 Workspace Auswahl | Workspace-Details | Backlog | Logo, USt-ID, Rechnungsdaten, Mitglieder einladen/erstellen und Rechtliches spaeter in Workspace-Einstellungen |
|
||||
| WF-P2 Profil und Sicherheit | Security / Sessions | Backlog | Eigene Seite fuer aktive Sessions, Trust Devices und Session-Verwaltung |
|
||||
| WF-P2 Profil und Sicherheit | Ueberall abmelden / Session einzeln abmelden | Backlog | Gehoert zur spaeteren Security/Sessions-Seite |
|
||||
| WF-P2 2FA Verwalten | Trust Devices / aktive Sessions | Backlog | Nicht Teil des 2FA-Verwalten-Modals, sondern spaeter Security/Sessions |
|
||||
| WF-P2 Konto loeschen | Echter Loeschprozess | Backlog | Workspace-/Account-Loeschprozess mit operativer Bearbeitung spaeter ausarbeiten |
|
||||
| WF-P2 Konto loeschen | Voller DSGVO-/Export-Wizard | Backlog | Datenexport-Step, Reauth, Confirm Phrase, Countdown und Legal/Billing-Details spaeter |
|
||||
| WF-P2 Konto loeschen | Workspace-Settings ausbauen | Backlog | Minimaler Workspaces-Bereich enthaelt v1 nur Loeschungsanfrage |
|
||||
| WF-P2 Admin RBAC | V2-Backlog | Dokumentiert | Reassign, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Rollen-Review, Templates, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz |
|
||||
|
||||
---
|
||||
|
||||
## 5. Naechste Validierungsschritte
|
||||
|
||||
Diese Pakete sind angelegt, aber noch nicht validiert. Naechster Schritt ist jeweils: Flow einzeln brainstormen -> David entscheidet -> Screen-Kandidaten pruefen -> danach erst Canvas/Subframe bauen.
|
||||
|
||||
| Kandidat | Ticket | Bereich | Status | Notiz |
|
||||
|---|---|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## 6. Status-Logik
|
||||
|
||||
| Status | Bedeutung |
|
||||
|---|---|
|
||||
| Idee | noch nicht geprueft |
|
||||
| Intent Check | es wird geklaert, was ueberhaupt gewollt ist |
|
||||
| Brainstorming | Varianten werden diskutiert |
|
||||
| Entscheidung offen | David muss Richtung entscheiden |
|
||||
| Screen Validation | einzelne Screen-Kandidaten werden geprueft |
|
||||
| Validiert | finale Screen-Liste steht |
|
||||
| In Subframe | validierte Screens werden gebaut |
|
||||
| Review | gebaut, aber noch nicht final geprueft |
|
||||
| Fertig | bereit fuer Handoff |
|
||||
|
||||
Regel: Kein Paket geht zu `In Subframe`, bevor es `Validiert` ist.
|
||||
|
||||
---
|
||||
|
||||
## 7. Umsetzung
|
||||
|
||||
| Umsetzung | Bedeutung |
|
||||
|---|---|
|
||||
| Bauen | eigener Screen/Frame in Subframe |
|
||||
| Wiederverwenden | vorhandenes Pattern/Archetyp reicht |
|
||||
| Nur dokumentieren | kein Frame, aber im Markdown beschreiben |
|
||||
| Spaeter | bewusst noch nicht jetzt |
|
||||
| Raus | nicht im Scope |
|
||||
|
||||
---
|
||||
|
||||
## 8. Optional: Dataview fuer Pakete
|
||||
|
||||
Nur verwenden, wenn das Obsidian-Dataview-Plugin installiert ist.
|
||||
|
||||
```dataview
|
||||
TABLE ticket, typ, status, subframe
|
||||
FROM "02 Wireframes"
|
||||
WHERE kind = "wireframe-package"
|
||||
SORT ticket ASC
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Optional: Dataview fuer Screens
|
||||
|
||||
```dataview
|
||||
TABLE package, id, screen, typ, umsetzung, status, route, subframe
|
||||
FROM "02 Wireframes"
|
||||
WHERE kind = "screen" OR kind = "state"
|
||||
SORT package ASC, id ASC
|
||||
```
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
kind: screen
|
||||
project: HiveGrid Screen Project
|
||||
ticket: ""
|
||||
package: ""
|
||||
id: S01
|
||||
screen: ""
|
||||
typ: ""
|
||||
umsetzung: Bauen
|
||||
status: Idee
|
||||
route: ""
|
||||
subframe: ""
|
||||
---
|
||||
|
||||
# S01 — [Screen Name]
|
||||
|
||||
## Ziel
|
||||
|
||||
-
|
||||
|
||||
## Pattern / Archetyp
|
||||
|
||||
-
|
||||
|
||||
## Daten
|
||||
|
||||
-
|
||||
|
||||
## Aktionen
|
||||
|
||||
-
|
||||
|
||||
## Banner / Hinweise
|
||||
|
||||
-
|
||||
|
||||
## Toasts / Action-Feedback
|
||||
|
||||
-
|
||||
|
||||
## Meldungsentscheidung
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Umsetzung | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| - | Inline / Banner / Toast / Modal / Screen | ja / nein | Bauen / Nur dokumentieren / Wiederverwenden | - |
|
||||
|
||||
## Zustaende
|
||||
|
||||
| Zustand | Beschreibung | Umsetzung |
|
||||
|---|---|---|
|
||||
| Leer | - | Nur dokumentieren |
|
||||
| Laden | - | Wiederverwenden |
|
||||
| Fehler | - | Nur dokumentieren |
|
||||
| Keine Berechtigung | - | Nur dokumentieren |
|
||||
|
||||
## Blockierende Error States
|
||||
|
||||
Nur ausfuellen, wenn der Nutzer nicht einfach im aktuellen Feld weitermachen kann.
|
||||
|
||||
| Zustand | Was sieht der Nutzer? | Primaeraktion | Sekundare Aktion |
|
||||
|---|---|---|---|
|
||||
| - | - | - | - |
|
||||
|
||||
## Permissions / Gates
|
||||
|
||||
-
|
||||
|
||||
## Subframe
|
||||
|
||||
-
|
||||
|
||||
## Notizen
|
||||
|
||||
-
|
||||
@@ -0,0 +1,199 @@
|
||||
---
|
||||
kind: wireframe-package
|
||||
project: HiveGrid Screen Project
|
||||
ticket: ""
|
||||
package: ""
|
||||
typ: Flow
|
||||
status: Idee
|
||||
subframe: ""
|
||||
canvas: ""
|
||||
---
|
||||
|
||||
# WF-[Ticket] [Paketname]
|
||||
|
||||
Status: Idee
|
||||
Subframe-Link: -
|
||||
Canvas: -
|
||||
Stand: YYYY-MM-DD
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung
|
||||
|
||||
Was klaert dieses Wireframe-Paket?
|
||||
|
||||
---
|
||||
|
||||
## 2. Intent Check
|
||||
|
||||
Erst klaeren, was ueberhaupt gewollt ist.
|
||||
|
||||
| Frage | Antwort |
|
||||
|---|---|
|
||||
| Welches Ticket/Modul ist betroffen? | - |
|
||||
| Was soll der Nutzer am Ende schaffen? | - |
|
||||
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | - |
|
||||
| Welche Planning-Quellen wurden geprueft? | - |
|
||||
| Was ist sicher im Scope? | - |
|
||||
| Was ist sicher nicht im Scope? | - |
|
||||
| Gibt es Admin/Normalrolle-Unterschiede? | - |
|
||||
| Welche Annahmen sind noch unsicher? | - |
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
| Punkt | Inhalt |
|
||||
|---|---|
|
||||
| Ticket/Modul | - |
|
||||
| Nutzerrolle | - |
|
||||
| Admin-Variante | - |
|
||||
| Normale Rolle | hoechste Rolle unter Admin |
|
||||
| Startpunkt | - |
|
||||
| Ziel | - |
|
||||
| Haupt-Archetyp | - |
|
||||
| Bespoke-Anteil | - |
|
||||
| Out of scope | - |
|
||||
|
||||
---
|
||||
|
||||
## 4. Brainstorming
|
||||
|
||||
Screen-Listen entstehen erst nach dem Brainstorming. Hier noch keine finale Screen-Liste festlegen.
|
||||
|
||||
### Flow-Frage
|
||||
|
||||
Worum geht es in diesem Flow?
|
||||
|
||||
-
|
||||
|
||||
### UX-Varianten
|
||||
|
||||
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
||||
|---|---|---|---|---|
|
||||
| A | - | - | - | - |
|
||||
| B | - | - | - | - |
|
||||
|
||||
### Entscheidung
|
||||
|
||||
| Entscheidung | Status | Notiz |
|
||||
|---|---|---|
|
||||
| - | genommen / spaeter / raus / unklar | - |
|
||||
|
||||
### Happy Path
|
||||
|
||||
1. -
|
||||
2. -
|
||||
3. -
|
||||
|
||||
### Varianten / Branches
|
||||
|
||||
- -
|
||||
|
||||
### Roadblocks
|
||||
|
||||
- -
|
||||
|
||||
### Meldungs-/Error-State-Brainstorming
|
||||
|
||||
Welche Fehler, Warnungen, Success-Zustaende und Hinweise koennen auftreten?
|
||||
|
||||
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
||||
|---|---|---|---|---|
|
||||
| - | Inline / Banner / Toast / Modal / Screen | ja / nein | ja / nein | - |
|
||||
|
||||
Regel: Wenn der Nutzer blockiert ist, Sicherheit/Zugang betroffen ist oder der Zustand eine klare naechste Handlung braucht, wird ein eigener Screen geprueft.
|
||||
|
||||
### Offene Fragen
|
||||
|
||||
- -
|
||||
|
||||
---
|
||||
|
||||
## 5. Screen-Kandidaten nach Entscheidung
|
||||
|
||||
Diese Liste ist noch nicht final. Hier wird erstmal gesammelt.
|
||||
|
||||
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
||||
|---|---|---|
|
||||
| - | - | - |
|
||||
|
||||
---
|
||||
|
||||
## 6. Screen Validation Gate
|
||||
|
||||
Jeder Kandidat wird einzeln entschieden, bevor er in den Flow kommt.
|
||||
|
||||
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | - | - | - | - | - |
|
||||
|
||||
Entscheidung: `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter`, `Raus`
|
||||
|
||||
### Copy-kritische Zustaende
|
||||
|
||||
Diese Zustaende koennen gebaut werden, auch wenn sie technisch nur Meldungen sind.
|
||||
|
||||
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
||||
|---|---|---|
|
||||
| - | - | - |
|
||||
|
||||
### Blockierende Error States
|
||||
|
||||
Diese Zustaende muessen genauer definiert werden, wenn sie den Nutzer stoppen.
|
||||
|
||||
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
||||
|---|---|---|---|---|
|
||||
| - | Screen / Banner / Modal | - | - | - |
|
||||
|
||||
---
|
||||
|
||||
## 7. Validierte Screen-Liste
|
||||
|
||||
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
||||
|---|---|---|---|---|---|
|
||||
| S01 | - | - | Bauen | - | Idee |
|
||||
|
||||
Umsetzung: `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter`, `Raus`
|
||||
|
||||
---
|
||||
|
||||
## 8. Subframe-Grid
|
||||
|
||||
Hauptflow:
|
||||
|
||||
```text
|
||||
S01 -> S02 -> S03
|
||||
```
|
||||
|
||||
Branches:
|
||||
|
||||
```text
|
||||
S02
|
||||
|
|
||||
v
|
||||
B01 -> B02
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Screen-Pakete
|
||||
|
||||
Verlinke hier auf einzelne Screen-Dateien:
|
||||
|
||||
- [[S01 Screen Name]]
|
||||
|
||||
---
|
||||
|
||||
## 10. Handoff-Check
|
||||
|
||||
- [ ] Jeder Screen ist mit Umsetzung markiert.
|
||||
- [ ] Jedes sichtbare Feld hat eine Datenquelle.
|
||||
- [ ] Jeder Button hat eine Aktion.
|
||||
- [ ] Banner/Inline-Meldungen sind dokumentiert.
|
||||
- [ ] Toasts/Action-Feedback sind dokumentiert.
|
||||
- [ ] Meldungs-/Error-State-Matrix ist ausgefuellt.
|
||||
- [ ] Blockierende Error States sind mit naechster Aktion definiert.
|
||||
- [ ] Relevante Zustaende sind beschrieben.
|
||||
- [ ] Offene Fragen sind sichtbar.
|
||||
- [ ] Subframe-Link ist eingetragen.
|
||||
@@ -0,0 +1,28 @@
|
||||
# Repo Notizen
|
||||
|
||||
Das technische Gitea-Repo liegt hier:
|
||||
|
||||
```text
|
||||
hivegrid-cloud
|
||||
```
|
||||
|
||||
Wichtige Planning-Dateien aus dem Repo:
|
||||
|
||||
- `hivegrid-cloud/.planning/SCREEN-MAP.md`
|
||||
- `hivegrid-cloud/.planning/DESIGNER-FIRST-PLAYBOOK.md`
|
||||
- `hivegrid-cloud/.planning/ticket-docs/`
|
||||
|
||||
Repo aktualisieren:
|
||||
|
||||
```bash
|
||||
cd /Users/davidbertram/Desktop/HiveGrid-Screen-Project/hivegrid-cloud
|
||||
git pull --ff-only
|
||||
```
|
||||
|
||||
Hinweis: Dieses Repo ist fuer dich auf Lesen/Pullen ausgelegt. Push ist bewusst deaktiviert.
|
||||
|
||||
Alter lokaler Backup-Ordner:
|
||||
|
||||
```text
|
||||
/Users/davidbertram/Desktop/HiveGrid-Backups/
|
||||
```
|
||||
@@ -0,0 +1,40 @@
|
||||
# HiveGrid Screen Project
|
||||
|
||||
Dieser Ordner ist der Obsidian-Vault fuer HiveGrid Screens, Wireframes, UX-Regeln und Handoffs.
|
||||
|
||||
Start hier:
|
||||
|
||||
- [[00 Start Here]]
|
||||
- [[01 Regeln/Wireframing Playbook]]
|
||||
- [[01 Regeln/Obsidian Struktur]]
|
||||
- [[02 Wireframes/Screen Paket Tracker]]
|
||||
|
||||
---
|
||||
|
||||
## Inhalt
|
||||
|
||||
| Bereich | Zweck |
|
||||
|---|---|
|
||||
| `01 Regeln` | Arbeitsregeln fuer Wireframing, Subframe und Obsidian |
|
||||
| `02 Wireframes` | Wireframe-Pakete, Screen-Dateien, States und Canvas-Flows |
|
||||
| `03 Quellen und Repo` | Hinweise zum technischen Repo und zur Aktualisierung |
|
||||
| `hivegrid-cloud` | Gitea-Checkout mit Planning-Dateien und Docs |
|
||||
|
||||
---
|
||||
|
||||
## Arbeitsregel
|
||||
|
||||
In `hivegrid-cloud/` wird nicht direkt an UX-Konzepten gearbeitet. Das Repo bleibt Quelle zum Lesen und Pullen.
|
||||
|
||||
Neue Konzepte, Screens, Wireframe-Pakete und Handoffs entstehen in `02 Wireframes/`.
|
||||
|
||||
---
|
||||
|
||||
## Backup
|
||||
|
||||
Der alte lokale Backup-Ordner wurde aus dem Vault verschoben nach:
|
||||
|
||||
```text
|
||||
/Users/davidbertram/Desktop/HiveGrid-Backups/
|
||||
```
|
||||
|
||||
Reference in new issue
Block a user