Context-aware prefilling for Bureaucracy forms

[nicola-myo]

Feature request: Context-aware prefilling for Bureaucracy forms

Summary

It would be very useful if Bureaucracy forms could receive context from the page or namespace they are called from, and use that context to automatically prefill form variables (hidden or visible).

This would enable structured document creation workflows without requiring users to manually re-enter contextual data such as client codes or project identifiers.

---

Problem

Currently, Bureaucracy only supports variables that are explicitly defined as form fields or hardcoded values. There is no built-in way to:

• Access the page ID or namespace from which a form is called or included
• Prefill form fields based on that context
• Safely pass contextual information (e.g. client code) without user input

As a result, users must manually enter identifiers that are already known from the wiki structure, which is error-prone and repetitive.

---

Use case

We use a strict namespace hierarchy, for example:

acme:customers:CUS00012:01_analysis:B_meetings

From a client or project dashboard page, we want to provide links like “New document” that open a generic Bureaucracy form.

The form should automatically determine:

• Customer code (CUS00012)
• Phase (01_analysis)
• Subsection (B_meetings)

without requiring the user to type them again.

---

Proposed solution

1. Expose calling page context

Introduce one or more internal variables that expose the calling page context, for example:

• @CALLER_PAGE@ – full page ID (e.g. acme:customers:CUS00012:start)
• @CALLER_NAMESPACE@ – namespace of the calling page

These variables should be available for substitution in form fields and generated content, just like regular Bureaucracy variables.

Namespace slicing (e.g. :n:) should be supported, so specific levels can be extracted:

---

2. Alternative (or complementary) approach: URL parameter prefilling

Optionally, allow forms to read URL query parameters (e.g. ?client=CUS00012&phase=01_analysis) as default values for form variables.

This should be strictly validated and sanitized.

---

Security requirements

Any implementation must include:

• Validation and sanitization of derived values
• Enforcement that generated pages stay within allowed namespaces
• Permission checks (CREATE / EDIT) on the target namespace
• No reliance on unreliable headers such as HTTP_REFERER
• Protection against path traversal or malformed input

---

Example workflow

Calling page:

acme:customers:CUS00012:start

Link on the page:

[[forms:new_document_form]]

Inside the form:

Resulting generated page:

acme:customers:CUS00012:01_analysis:B_meetings:meeting_2025_12_13

---

Benefits

• Eliminates repetitive manual input
• Reduces user errors
• Enables scalable, context-aware document creation
• Improves usability in structured, namespace-driven workflows

---

Notes

This feature would expose information already available in DokuWiki’s page context and would not require changes to existing form behavior unless explicitly used.