Note: this is an earlier, still incomplete version of the user guide. Updated documentation is in preparation; some screens and labels may differ from the current application.

Workspaces

Workspaces are the foundation of content organisation in Simbioza. This guide covers global settings, Workspace and page-tree creation, visibility, permissions, the publishing workflow, direct permissions, restrictions, Workspace themes, static HTML export, backup/restore and mobile behaviour.

Contents

1. Workspace, page and slug
2. Global Workspace settings
3. Creating and managing a Workspace
4. Permissions and access model
5. Tree, contents, page settings and special menus
6. Editing, preview and publishing
7. Restrictions and direct permissions
8. Role comparison
9. Embedded content and access checks
10. Workspace theme
11. Static HTML export
12. Workspace backup and restore
13. Mobile view
14. Archive, deletion, search and maintenance
15. Final verification

1. Workspace, page and slug

A Workspace is an isolated content area with its own page tree, home page, permissions, theme, private menus and backup. Typical Workspaces represent a project, department, public guide collection or internal knowledge base.

A page is a tree item. It may point to an HTML document, an external URL or another supported content type. Parent/child placement controls navigation and the scope of page restrictions.

A slug is a stable URL identifier without spaces, such as project-aurora or work-plan. A URL combines the root segment, Workspace slug and page slug, for example /workspace/project-aurora/work-plan.

• Choose short, readable and long-lived slugs.
• Changing a slug changes the URL; recheck external links, embedded content and bookmarks.
• During restore, the target slug decides whether the backup targets an existing Workspace or creates a separate copy.

2. Global Workspace settings

Only administrators see this section under Settings → Workspaces. A manager of one Workspace cannot change these application-wide defaults.

2.1. General defaults and Workspace creation

The administrator sets the starting behaviour for every new Workspace. These values do not overwrite existing Workspace/page exceptions; they are defaults that can be overridden at the appropriate level.

Workspace root path The first URL segment used by all Workspaces. In this example pages use /workspace/{workspace}/{page}. The segment must not collide with a route owned by another module. Default visibility The initial ACL level for a new Workspace: Public, All signed-in users or Restricted. Saved Workspace rights remain the final authority. Show the tree initially Controls whether hierarchical navigation opens automatically. A reader can still open or close it on the page. The page outline is initially visible Controls the initial state of the table-of-contents card. A Workspace and an individual page can override it. Workspace creation Search and add users or groups allowed to open the New Workspace form. The example uses the Workspace creators group. Administrators always retain this ability. This is not the same as Manage on an existing Workspace. Page summaries Sets the initial tree depth, article count, order and filter visibility for the public collection of published-page excerpts. A visitor may temporarily change filters; All is offered only below 100 visible articles.

There is no separate Workspace owner. The Manage permission controls maintenance of an existing Workspace, while Workspace creation only controls who can create another one.

2.2. Public and signed-in home pages

• The public home page opens for guests and must be publicly readable.
• The signed-in home page opens after login and may live in a Workspace available to all signed-in users.

2.3. Administrative lists

Each administrative screen has a separate operational purpose:

• All Workspaces lists active and archived Workspaces, slugs and state, with direct links to settings. Check it for a duplicate before creating or restoring a Workspace.
• Deleted Workspaces contains soft-deleted entries that can still be restored. Permanent removal is a separate confirmed maintenance action.
• Search index shows the number/state of indexed records and rebuild actions. Rebuild after a large import/restore or when results lag behind published content.
• Maintenance measures storage, optimises images, cleans history/deleted items and permanently removes previously deleted Workspaces. Section 14 documents each field.
• Personal Workspaces controls whether personal Workspaces are enabled and how they are provisioned for users.

2.4. Personal Workspace user permissions

Whether a personal Workspace is created after first sign-in, by the batch administration action, or with Create now, its mapped member is automatically added under Members and permissions. The member receives View, Add, Edit, Publish, Delete, and Manage; no follow-up ACL configuration is required.

This does not reintroduce a general Workspace owner. Any user with Manage can administer a regular Workspace. A personal Workspace additionally has a stable member mapping, and the system keeps that member's complete ACL in place. If the personal Workspace predates this rule, the next successful sign-in restores all six permissions without creating a duplicate.

3. Creating and managing a Workspace

1. Open Workspaces and select New Workspace. The action is available to administrators and globally authorised creators.
2. Enter a name, durable slug and description that explains the Workspace to other administrators.
3. Select the initial page-tree and outline state, or inherit the global setting.
4. Save. Then assign users/groups, theme and special menus and create the Workspace home page.

3.1. New Workspace fields

• Name is the user-facing label in lists, the hero and the page tree.
• Slug is the URL identifier. Avoid temporary names if long-lived links are expected. A later change requires link and integration checks.
• Description explains the purpose and helps administrators distinguish similarly named Workspaces.
• Page tree sets the initial hierarchical-navigation state: Inherit, Show or Hide.
• Page outline sets the initial table-of-contents state and may be overridden by a page.

Visibility and members are not saved in this first compact form. After saving, open Workspace management and configure the Members and permissions matrix. This avoids partially saved ACL data during creation.

3.2. Managing an existing Workspace

• An archived Workspace is read-only stops changes without removing content or URLs.
• Edit Workspace theme opens the Workspace-private theme; theme editing is documented separately.
• Edit Workspace menus opens the special top and left menus described in section 5.4.
• Manage Workspace backup opens full Workspace export/restore.
• The export icon in the data card creates a static HTML package; it is not a recovery backup.
• Delete Workspace first performs a soft deletion. Restore and permanent removal remain administrator operations.

4. Permissions and access model

4.1. Visibility modes

• Public: published content is readable without login; guests never receive editing rights.
• All signed-in users: every active signed-in account can read published content without an explicit ACL row.
• Restricted: access comes from Workspace user rights, group membership or a direct page permission.

Direct user rights and all group rights are combined. A page restriction can then deny a selected user part of the inherited result.

5. Tree, contents and page settings

The tree is one Workspace's hierarchical navigation. A manager can maintain it without opening the HTML editor: add an existing document, internal link or external link, change parent/order and open settings for every page. Prepared documents are used here; editing their contents is covered by a separate guide.

5.1. Workspace and page display defaults

Display settings have three levels. The global value applies when the Workspace inherits it; the Workspace value applies to its pages; an individual page has the highest priority for its outline. This allows a visible tree across a project while hiding the outline on a short landing page.

• Page tree controls the initial state of the hierarchical Workspace navigation. A reader can still use the Tree icon.
• Page outline controls the current document's heading list. A page chooses Inherit Workspace setting, Show or Hide.
• When a special left menu is active, it occupies the left position and the page tree starts hidden; the Tree icon can still reopen it.

5.2. Editing the page-tree arrangement

Select Tree, then Edit tree. Each row receives a pencil and four direction actions. Up/down changes order among siblings, left outdents one level, and right indents under the previous item. An unavailable move is disabled to prevent an invalid hierarchy.

Moves remain local to the organiser until Save arrangement is selected. Check page parents before saving because a restriction on a parent also applies to its descendants.

5.3. Adding and configuring a tree item

Add item does not always create new HTML content. The supported types are:

• Page (HTML document) links an existing document or creates a page when offered.
• Internal link targets an application named route or internal path, such as Calendars.
• External link targets a complete external URL. Its title and slug still control its tree presentation.

Parent page places the item immediately; it can later be repositioned in the organiser.

The pencil beside an item and the Manage page and permissions action in page contents open the same panel for administrators and Workspace managers.

• Title and slug define presentation and the page URL.
• Workspace homepage is opened when the Workspace URL has no page slug.
• Page labels support filtering and organisation.
• Page properties store structured text, status, number, date, user or link values for themes/modules that render them.
• Default page outline display overrides the Workspace only for this page.
• Delete subtree includes the selected item and every descendant.

5.4. Workspace special top and left menus

Special menus apply only on the selected Workspace route and its pages. Top and left menus are edited and saved independently; changing or removing one does not alter the other.

• Active enables the menu context; Remove marks the entire context for deletion when saved.
• Protected base top-menu items may be enabled/disabled and reordered, but their label and route remain locked.
• A custom item may use a named route, direct URL and query parameters. Prefer a named route for internal destinations.
• The left menu has its own translatable title and item order. In the example it acts as concise project navigation.
• With the special left menu active the page tree starts hidden, but remains available through the Tree action.

6. Editing, preview and publishing

Editing and publishing are deliberately separate. An editor saves a draft while readers continue to see the published version. A publisher previews the draft and approves it.

7. Restrictions and direct permissions

7.1. Restricting inherited rights

The searchable user picker lists only users who already have a Workspace permission, directly or through a group. Green with a check means inherited and retained; red without a check means explicitly denied; white means the user did not inherit that permission. A restriction cannot grant anything and applies to the selected page and its descendants.

7.2. Direct page permissions

A direct permission adds a user, never a group, and may grant Read, Editing and Publish on one page. It does not propagate to child pages. A user without general Workspace access sees the Workspace in the list but can open only the directly permitted page.

8. Role comparison

9. Embedded content and access checks

Embedding another page, calendar or module never bypasses the source permissions. If the viewer cannot access the source, Simbioza renders a controlled placeholder instead of leaking the page or event data. Always test the final page as the intended reader, not only as an administrator.

10. Workspace theme

A Workspace can inherit the system theme or use a private Workspace theme. A user with Manage permission opens Workspace settings → Edit Workspace theme. The Theme editor itself is documented separately.

11. Static HTML export

A manager can export the published pages they are allowed to read as a standalone ZIP archive. It is useful for delivery, long-term archive and offline browsing.

• Drafts and inaccessible pages are excluded.
• Features requiring login, permissions or an API do not become an offline application.
• Extract the archive and verify index.html, navigation, images and links.

12. Workspace backup and restore

A Workspace backup is intended for migration or complete recovery. It includes supported content, history, attachments, tree, ACL, private theme, private menus and indexing data.

1. Open Manage Workspace backup.
2. For export, set a strong passphrase and store it separately; it is not retained in the backup.
3. For restore, upload the ZIP, enter the passphrase and run preflight first.
4. Review the format version, modules, page counts, ACL, theme and slug conflicts.
5. Restore into an existing Workspace or create a separate copy with a new slug.

13. Mobile view

On a narrow screen, the tree and table of contents become side buttons. Each button opens a touch-friendly card over the page and closing it returns to the document.

14. Archive, deletion, search and maintenance

14.1. Archive and soft deletion

An archived Workspace remains readable while changes are disabled. Use it for completed projects whose URLs and history must remain available. Turning archive off restores changes according to the existing ACL.

Soft deletion removes a Workspace from normal lists but preserves it for administrator restore. Before deleting, check application home pages, embedded pages, special menus and external links that may target it.

14.2. Search index

The index contains content the search module can offer while enforcing each viewer's permissions. Rebuilding does not change documents; it rereads published pages and refreshes search records. Run it after a large import/restore, mass slug changes or stale results. Review status and record counts before starting a rebuild.

14.3. Storage overview

The top of Maintenance is a pre-cleanup report. Historical versions and Deleted pages are record counts, Database estimate measures useful row data, and File system reports file storage. Separate history/deleted totals and the per-Workspace table identify which cleanup could actually reclaim space. The database estimate is not the physical SQLite/MySQL/PostgreSQL file size; physical compaction may require database-specific maintenance.

14.4. Image optimisation

Optimize existing images creates smaller web-ready copies for faster delivery. Originals remain saved and openable, so this action does not discard source quality. It is useful after a large import or many unoptimised photographs.

14.5. Cleanup history and deleted items

Cleanup is irreversible and requires a complete site backup first:

• Scope limits the operation to the entire site or one selected Workspace. Prefer the smallest required scope.
• Page history may remain untouched, remove all history except current/published versions, keep the latest 3/5/10 versions, or remove versions older than 10/30/90 days.
• Permanently remove deleted items may remain off or remove items older than 10, 30 or 90 days.
• An attachment is retained while any retained version references it.
• The operation cannot run until the administrator explicitly accepts that recovery is possible only from backup.

14.6. Permanently delete Workspaces

Only previously soft-deleted Workspaces appear here. Entering the exact slug protects against an accidental click. Confirmation removes pages, history, attachments, ACL, private theme, special menus and related module data. Recovery is possible only from a verified backup, so complete a trial restore before permanent deletion.

15. Final verification

1. Open the Workspace as an administrator and as its manager.
2. Test an editor without Publish and a publisher without Edit.
3. Test a reader, a signed-in user without ACL and a guest.
4. Verify a restriction on its page and descendants.
5. Verify a direct page permission and confirm the rest of the Workspace remains unavailable.
6. Open an embedded page and calendar as a user who lacks source rights.
7. Check inherited and overridden tree/contents display on desktop and mobile.
8. Export static HTML and open it outside the signed-in session.
9. Create a backup, restore a trial copy under a new slug and compare pages and ACL.