Skip to main content

​
Staff Settings

​
Sources

Docs: Ponder Primer, Primary Web App: Open a Parable in Ponder. Parable staff see the Staff Settings button, a sliders icon, beside the Parable’s description. Other readers see badges there.

​
Story

Parable staff use Staff Settings to say who published a Parable, how mature it is, how its Pieces are built, and what the Parable may do. Staff Settings has four pickers, in this order. In a Workspace it has a fifth picker, Handle, which is described below. It shows an icon and a dash, as the others do, and its tooltip names the current handle. Progress and Pieces are independent. A Prototype can use Composed Pieces, and a Parable with Custom Pieces can have no Progress. Each picker shows its icon and a caret, a small arrow that points down. A picker also shows a count when some of its values stand out. The count is the number of its values that stand out: a chosen Publisher or Progress, Platform on, Pieces other than Composed, and each Permission that differs from its default (Pools, Pipelines or Visible off, or Forking on). When none of its values stands out, a picker shows only its icon and its caret. A new Parable starts with Visible off, so in Admin its Permissions picker shows a count of 1 until staff turn Visible on. Point at a picker, or move the keyboard focus to it, to read its name and its values. For example, Permissions: Pipelines are off. or Permissions: Forking is on. The Publisher picker always names its Publisher first, as in Publisher: None. Platform is on. On a touch screen, tap the picker. Its menu opens with the picker’s name at the top.

​
Badges

A reader who is not Parable staff, or a staff member who may change nothing on the Parable, sees read-only badges beside the description. Each badge is an icon. Point at a badge, move the keyboard focus to it, or tap it to read its name. Pieces and Permissions have no badge. Readers see their effects instead. The card that opens when you point at a Parable in the sidebar shows the same badges in a footer. Each badge there shows its icon and its name. A Parable with no badge has no footer. Every reader sees the footer.

​
Demo Mode

Demo Mode makes a Parable open on its own. The Parable then looks like an app that stands alone. Staff use it to show a Parable to a customer. When Demo Mode is on:
  • A click on the Parable in the sidebar opens it in a new browser tab.
  • Any visit to the Parable’s address shows the Page alone. The app nav, the Parable’s title and description, and the bottom panel do not show. The Page fills the window.
  • A small demo badge shows at the top left of the window. It is ivory in the dark theme and dark in the light theme.
  • This holds for every reader, in Admin and in every Workspace that has the Parable. On a phone, a Workspace shows the Parable in its phone view, with its name and Ponder.
Only Parable staff change Demo Mode, in Admin. Right-click the Parable in the sidebar, or use the menu at the end of its row. Then choose Demo Mode. A check mark shows while it is on. A reader who is not Parable staff does not see this item. An archived Parable does not offer it. A tab decides this when it opens the Parable. If you turn Demo Mode on for the Parable that you have open, your tab keeps its editor and its sidebar until you open the Parable again. An address that names no Parable, such as /ponder, lands on a Parable that the app picks, and that tab keeps its sidebar even if the Parable is in Demo Mode. To change a Parable that is in Demo Mode, open the Admin sidebar in another tab and turn Demo Mode off. Then reload the tab that shows the Parable. A Parable that does not show in your sidebar opens as usual. In Admin, the sidebar lists Parables only for staff who can manage them, so other staff see the usual view.

​
Parable Directory

Every Parable in the Parable Directory needs approval from the Product team, a go-to-market launch, a marketing launch, product documentation and support with no end date. So when staff pick Parable Directory in the Publisher menu, a dialog opens before anything changes. It asks for two things:
  • Who approved it? Choose the staff member who approved it. The list holds only staff who can manage Parables. It leaves you out, because one person cannot confirm their own act.
  • To confirm, type I understand the risk. Case and the spaces at each end do not count.
Add to Parable Directory stays off until both are given. If the server refuses the change, the dialog stays open and says why. The server checks the phrase and the approver on every request, so a request from the API or from MCP needs them too. The server refuses an approver who is the person who asks. Only a Parable made in one of Parable’s own Workspaces can be in the Parable Directory. A Parable that a customer’s Workspace made cannot. Parable records each change: who made it, who approved it, what they typed, and when. Every demo Workspace runs each Parable in the Parable Directory, and takes each new Release at its Publish, so customers can see it with data (Demo Workspaces).

​
The SQL address

A Parable that Parable Directory publishes has the SQL address parables.directory_ and a name, where every other Parable has parables. and a name. The dialog shows both addresses: “This changes the SQL address from parables.spend to parables.directory_spend. External queries that name the old address stop working.” Nothing that exists moves. A Parable that entered the Parable Directory before this rule keeps its address until staff take it out and put it in again. The change moves the address, rewrites the Parable’s own SQL to it, and publishes the rewrite as one new Version. Then Parable sends that Version to the Workspaces that hold copies, and each copy that nobody changed takes it. The address page lists what a query outside the Parable must change. The change needs the staff Role that can manage Parables, as a rename does. The dialog says why the change cannot go ahead, and keeps Add to Parable Directory off, when:
  • Other Parables read the Parable.
  • A locked copy of the Parable has changes of its own. Such a copy takes no update by itself, and its Workspace cannot fix the SQL it wrote, so it would keep the old address. The dialog names the Workspaces. Delete each of those copies first. A copy that staff opened for changes (both Forking switches on) does not stop the change: its people pull the new Version and fix their own SQL.
  • A copy has an update under review. Its people pulled an update and did not finish. Automatic updates skip a copy while a review is open, and the review would publish the Version from before the change, which names the old address. The dialog names the Workspaces. Ask each Workspace to finish or discard its review, or delete its copy.
  • Nobody holds Primary on a copy, so Parable has nobody to act for. Give Primary to someone on the copy first.
  • A set of Changes is open on the Parable and can still publish. That means a set on the Parable’s own line, and a set on a copy whose Forking is on. The dialog names the Workspace of each set. A set of Changes left on a locked copy can never publish, so it holds nothing.
  • Another Parable of a Workspace that has the Parable already uses the new address.

​
Leaving the Parable Directory

Taking a Parable out of the Parable Directory opens a short confirm. It asks for no phrase and no approver, because leaving commits Parable to nothing. It says where the SQL address goes: “This changes the SQL address from parables.directory_spend to parables.spend.” The same rules apply: the change moves the address back, rewrites the Parable’s own SQL and publishes it, and the same things can stop it. If publishing the rewrite fails, Parable puts the address and the Publisher back as they were, and the dialog says why. If the Version is published and only the send to the copies fails, the new address stays, because the published Version names it. Deploy the Parable again to send the Version.

​
Forking

Customers keep the Parables that Parable staff deliver, and they make them their own with Preferences. A Workspace’s copy of a delivered Parable is locked: nobody in that Workspace, and no Ponder working for them, can change its Pieces. The Workspace still saves Preferences, reads and comments, runs Reports, and takes each update from Parable by itself. A copy that already holds changes of its own is the exception: it takes an update only after a person pulls it. Forking opens one Workspace’s copy to changes. It has two switches, and both are off by default: The copy’s switch works only while the Parable’s switch is on. Until then it says “Turn on Forking for this Parable in Admin first.” Turning the Parable’s switch off turns every copy’s switch off too. Turning it on again opens no copy: each copy needs a new approval. A Parable that a Workspace made has no Forking item there, because the Workspace already owns it. A Platform Parable is never forked. It reaches every Workspace, and Parable staff change it for all of them. A Platform Parable and its copies show no Forking item, and the server refuses Forking on either. The Platform switch stays off while the Parable’s Forking switch is on, and says “Turn off Forking first. A Platform Parable cannot be forked.” A switch that was on before Platform turned on still shows, so staff can turn it off. Turning either switch on opens the same dialog as Parable Directory. It says what Forking commits Parable to:
  • Assume that we support every forked Parable for as long as the customer uses it. Each one is a product that we commit to.
  • Ask if a request to Product is better. Product can change the Platform Parables that every Workspace gets, or add the change to this Parable as a Preference.
  • A forked Parable usually needs an agreement with the customer that pays for its long-term support.
It asks Who approved Forking? and for the typed phrase I understand the risk. The approver is another staff member. You cannot approve your own change. Turning a switch off needs no dialog. Parable records each change: who made it, who approved it, what they typed, which copy, and when. A forked copy does not take updates by itself. A person with Publishing or Primary on the copy Pulls each update and resolves each conflict. A locked copy still takes each new Release by itself.

​
What a forked copy may change

A forked copy is a true fork. Its people can add, change and delete any Piece, the Pieces its Release supplies included, such as a Plot that the copy does not use. The copy then reconciles each later Release:
  • A Release that changes nothing the copy changed merges clean. The copy keeps its own changes and takes the rest of the Release.
  • A Piece that the copy deleted stays deleted. A Release never brings it back by itself. A save of a deleted Pane, in the same set of Changes or a later one, brings it back with the Plots and Palette that the copy’s Release gives it.
  • When the Release changed a Piece that the copy also changed or deleted, Prepare on the Pull shows a conflict for that Piece. The person who prepares the Pull chooses the copy’s side or the Release’s side for each conflict. The Release’s side brings a deleted Piece back with the Release’s content.
  • When the Release changes or adds a Piece inside a Page, Package or Pane that the copy deleted, Prepare shows the conflict on that Page, Package or Pane. The copy’s side keeps it deleted, with everything the Release put in it. The Release’s side brings it back with the Release’s content. The same holds the other way round: when the Release deletes a container that holds a Piece the copy added, the copy’s side keeps the container.
  • Publish stays off until every conflict has a choice.

​
What a locked copy refuses

On a locked copy, the server refuses Start Changes, a Piece save, a schedule change, and Propose, Prepare, Publish, unseal and Restore of a set of Changes. A set that a Pull opened from an update still moves, so the Workspace can pull, prepare and publish an update by hand, as long as the set holds Parable’s update and nothing else. If a person edited the set by hand, it is a set of Changes like any other, and the server refuses it. Sets of Changes that were open before Forking went off stay where they are, and every change to them is refused. Customers see no badge and never read the word Forking. Their controls show “You cannot … here. Parable staff keep this Parable up to date.” The API, MCP and Ponder answer PA-AU-084 with three ways forward:
  1. Create a new Parable in this Workspace.
  2. Ask Parable to add the change to this Parable. Many changes become Preferences that you can set here.
  3. Ask Parable Pros to build it for you.

​
The Workspace Copies report

Staff read which copies are forks before they delete one. Admin, Product Admin, Workspace Copies lists every live copy of a Parable in every Workspace. Staff who can manage Parables open it. It changes nothing. The page reads 50 copies at a time and carries on until it has read them all. A copy is a fork when it owns changes, when the check could not run, or when it holds an open set of Changes that is not a Pull set that nobody edited. A Pull set that a person edited by hand holds changes of the Workspace’s own, so it makes the copy a fork. The page shows the forks first. All copies shows the others. Copies has one row for each copy:
  • The Workspace, the Parable, its handle and its SQL address.
  • The Parable’s Forking switch and the copy’s switch.
  • Owns changes: the copy’s own rows differ from the Version it took, compared as an automatic update compares them. Unknown means the check could not run.
  • Open sets: the sets of Changes open on the copy, and how many of them are Pull sets that nobody edited.
  • The state of the last Delivery, and Visible.
  • Live Preferences and Refresh schedules: what a delete of the copy loses.
Blocked handles lists each staff Parable that another live Parable keeps out of a Workspace because it holds the same handle or the same SQL address. A Deploy to that Workspace is refused until one of the two moves. Held by says whether the Workspace made the other Parable or got it as a copy. Targeted says whether the newest Deploy of the staff Parable names the Workspace.

​
Handle

A Parable has a handle and a SQL address. Code names the Parable by its handle. Queries name it by its SQL address, parables. and a name. Both stay as they were made until staff rename them. Putting the Parable in the Parable Directory or taking it out also moves the SQL address, and leaves the handle as it is. In a Workspace, staff who can manage Parables get the Handle picker. Point at its icon to read the current handle. Rename handle… moves the handle and the SQL address together. It asks twice:
  1. Rename handle takes the new handle. It checks the handle while you type and shows the SQL address that the handle gives. It warns: “This will break any external queries that reference this handle.”
  2. The second dialog is the same typed confirmation as Parable Directory. You type the new handle. It asks for no approver.
The rename then rewrites the Parable’s own SQL and imports to the new handle and address, and publishes them as one new Version. A query outside the Parable that names the old address stops working. The old handle and address become free for another Parable of the Workspace. The server refuses a rename, and the first dialog says why, when:
  • Other Workspaces hold copies of the Parable. A rename would leave those copies on the old handle and address.
  • Other Parables read the Parable: a published Version, a Personal Parable that has not published, or an open set of Changes of another Parable.
  • A set of Changes is open on the Parable.
  • The new handle differs from the old one only in letter case. The SQL address is the handle in lower case, so it would not move.
  • The Parable is a Custom Parable, an archived Parable, or a copy that Parable staff delivered. A copy takes its handle from its Parable.
  • Another Parable of the Workspace already holds the handle or the address.
  • Parable made the Parable in one of its own Workspaces, and you hold no seat on it that lets you change its identity. Staff need no seat for a Parable that a customer’s Workspace made.
Only staff change a handle. A person who is not staff can still change a Parable’s name. The handle stays where it is.

​
Deleting a Parable or a copy

In a Workspace, staff who can manage Parables get one more item in the menu of a pinned Parable in the navigation bar. Right-click the row, press Shift+F10, or use its button. The item sits after a last separator: Both open the typed confirmation. A composed Parable with live copies keeps the confirmation button disabled. You type the Parable’s handle. They ask for no approver. Parable records who deleted it, what they typed, and when. A deleted Parable or copy leaves the Parable Directory, search, the SQL catalog and its suggestions, the lists in Ponder and MCP, and the Report schedule. A link to it opens “not found”. Its handle and SQL address are free at once. The server refuses Delete Parable… for a Custom Parable and for a composed Parable that other Parables read, published or not, or that still has copies in other Workspaces. Delete this copy… on a copy of a Custom Parable resets the copy. The next platform release makes the copy again. Admin keeps its own Archive and Delete permanently. Delete permanently deletes the copy in every other Workspace with the Parable, with the changes and the open Patches of each copy. Before it runs, the dialog lists each Workspace that holds a copy and the open Patches on each copy, and you type the Parable’s handle. The server refuses the delete without the handle. When the Parable has copies, the delete also needs a staff Role that can manage Parables. Parable records who deleted it, what they typed, and each copy that went with it. The delete is a soft delete. The rows stay stored as the record, so an engineer can recover them, but no screen in Parable restores them. After Delete this copy…, the next Deploy of the Parable to the Workspace makes a new copy with none of the old changes. The old copy’s Live Preferences and Report history do not move to the new copy. The new copy runs the Parable’s Refresh schedules on its own, from the next occurrence after it publishes. If Parables of the Workspace read the copy by SQL address, the dialog names them, and they stop working until that Deploy. The delete still goes ahead, so a Platform Parable that others read, and the clean-up that deletes a copy and deploys a new one, are not blocked.

​
Pieces

  • Composed Pieces are structured Pieces: Pages, Panes, Plots, Packages and Perceptions. This is the default.
  • Custom Pieces are one uploaded browser React app that follows the package structure. The Piece tree shows the app’s files.
  • Code Pieces are a tree of files with no required structure. The Piece tree shows every file with the same icons as Custom. The Page runs the entry file when there is one. A reader without Ponder permission or the package view permission gets only the entry file and the files that it imports. With Custom, every file of the package reaches the reader’s browser.
A Pieces change is content. In Publishing it goes into the open Changes, and readers get it when the Changes publish. A change never drops content:
  • Composed can become Custom or Code only on an empty Parable.
  • Custom or Code can become Composed only when no app files are stored.
  • Custom can always become Code.
  • Code can become Custom only when its files pass every Custom rule.
When an option is closed, the menu says why under it.

​
Permissions

  • Pools off: every query that the Parable or one of its Plots runs fails on a Provider Pool table. The Pane shows “This Parable cannot read Provider data because its Pools permission is off.” Saving a Plot and Prepare still work, because they only plan the SQL and read no data.
  • Pipelines off: the Parable starts no Refresh or Preview, runs no scheduled Refresh, takes no new or changed schedule, and no Plot can become a Pipeline. A schedule can still be turned off or deleted: the schedule dialog shows the schedule read-only, with Delete schedule. A Pipeline can still become a plain Plot. Refresh actions do not show. A Refresh that is running can still be cancelled. Refreshes stored before stay readable. The Plot editor’s Preview still reads live data, because it stores nothing.
  • Visible, in Admin only, decides where people see the Parable, as before.
A Permission narrows what a Parable may do. It never widens what a person may read. Provider Policies and Workspace permissions still apply.

​
Security

Only Parable staff change Staff Settings, and the server checks this on every write. A Workspace role never answers a Staff Setting, so a customer’s Workspace Administrator cannot set a badge or change Pieces. In a Workspace, Publisher and Progress change only on a Parable that the Workspace originated. A delivered copy shows the values of the upstream Parable. An archived Parable shows its badges and takes no change. When Parable staff Pocketed the Parable, a staff member who could change an item without the Pocket still gets the menus. Every item is closed. Each menu and the rename dialog show the server’s own sentence once: Parable staff Pocketed the Parable, and only Parable staff can Restore it, from its row menu in Admin. A Custom Parable, such as Providers or People, is built into the platform. Its Staff Settings take no change, in Admin or in a Workspace. Its copy in a Workspace refuses Pocket, Restore, Refresh, Cancel Refresh, a seat change, a Collaboration Mode switch, Start Changes and a save. Each refusal says: “This Parable is built into the platform. It changes only with a platform release.” The copy refuses before it checks the participation, because nobody holds a participation on it.

​
Stability

Publisher, Progress and the Permissions apply at once in every Workspace that has the Parable. They do not publish, withdraw, deploy or revoke a Version. Pieces follows the Version, as other content does. A copy’s Forking switch applies at once in its Workspace only. The one exception in Publisher is Parable Directory: it moves the SQL address, so it publishes the Parable’s own SQL again and sends that Version to the copies. For those behaviors, use Personal vs. Published Versions and the publishing guides.