Skip to content

CtrlPortals 3.26.9.37

Released: 2026-09-09 Requires M-Files: 23.6.0.0

A release about the configuration itself. Every widget now keeps its settings in one section named after its type, the stored configuration holds only what an administrator actually chose, two administrators can edit at the same time without overwriting each other, and there is a backup to go back to. Layout gets simpler too: one Width per element, and portals that widen their columns by themselves in a narrow pane. It carries everything from 3.26.9.28.

Configuration version 2.0 — one section per widget type

Section titled “Configuration version 2.0 — one section per widget type”
  • A widget’s editor now shows Name, Type, one expandable section for the chosen type, Width, Show when — nothing else. The section (Form, HTML, Markdown, List view, Plot view, Plot Configuration, Calendar, Comments, Steps, Multi View) holds every setting that belongs to that type; a Comments widget no longer carries calendar or plot members it never reads.
  • Existing configurations are upgraded automatically when the vault application starts (0.0 and 1.0 both go straight to 2.0): every setting moves under its type’s section, Use Advanced Width becomes the Width, and values equal to the old defaults are removed. A snapshot of the pre-upgrade text is stored first (see Backups).
  • Absent means default. Configuration members no longer carry a default that is written into every element; a member is simply missing until you set it, and the help text of each says what missing means. The stored JSON of an untouched widget is its Type, Name and identity.
  • Markdown Editor can name the file to show (File, with or without the .md extension, matched without regard to case). Unset, it shows the object’s first Markdown file as before; a named file that does not exist shows nothing rather than another file.
  • List View editing is off by default. The classic List View gains Allow editing, the same positive switch the Multi View’s list has; turn it on for the lists that should offer the Edit button and cell editors. View folders and other non-object rows are never editable.
  • Calendar gains First day of week (Monday by default), and an event type’s Text color is now optional: left empty, the event text is black or white, whichever reads best on the event’s background colour, the way lookup labels already choose theirs.

One Width per element, laid out from the space it actually has

Section titled “One Width per element, laid out from the space it actually has”
  • Every component, segment, column segment and form part has a single Width (1–16, its share of the row when the portal has room). Use Advanced Width with its computer / tablet / mobile values, Stackable and Doubling are gone.
  • The portal keeps your layout and only changes it when a pane is genuinely narrow — judged from the width each container really has, not the size of the screen. What counts as narrow follows the configured width: a wide share (8 and up) is a segment that needs about 400 px, a small share (4 and down) is a card that manages with 180 px and stays a card as it grows. So an 8/8 split of segments holds down to an 800 px container and then stacks; a 4-wide card holds its quarter down to 720 px, is a half down to 360 px, then takes the row; a 12+4 pair becomes two full rows below 720 px — an element left alone on its row always takes the whole row. Nested layouts size against their real column, and a widened element narrows again only once it is comfortably past the threshold, so a scrollbar appearing never flips a layout back and forth.
  • A row of three or more elements that does not fill the row (five 2-wide cards, say) spreads its leftover as equal gaps between them instead of leaving it all on the right.
  • Applies the moment a tab, an accordion or a full-screen segment becomes visible, whenever a Show when rule shows or hides an element, and after a resize settles.

Two administrators, one configuration — merged, not overwritten

Section titled “Two administrators, one configuration — merged, not overwritten”
  • Every portal, every dashboard and the configuration’s own settings carry a hidden revision. When you save an item that somebody else saved while you had it open, the server merges the two edits: changes to different settings, different components or different list elements all land, and two people adding to, or removing from, the same list both get their way. Elements are matched by identity, not by position, so reordering on one side and editing on the other both survive; every segment, column, form part, widget and field now carries such an identity, and an element added in the editor is given one the moment it is saved. Two edits to the same element merge member by member; only the same member changed differently on both sides is a conflict. The editor reloads to show the merged result.
  • A real conflict refuses the save and says where: Could not save portal “Customer”: someone else changed it while it was open, and their change and yours touch the same place. Conflicts: Components › “Sales by month” › PlotView › Height: set to “500” by them, set to “300” by you. Reload it and apply your change again. Nothing is written by guessing.
  • The last ten revisions of each item are kept for the merge; an editor left open through more saves than that is asked to reload.
  • Before every version-changing upgrade the stored configuration text is snapshotted into the vault; the newest five snapshots are kept.
  • The application node’s menu gains Back up configuration now and one Restore backup from <date> (<reason>, <size>) per snapshot. A restore backs up the current configuration first and brings the restored text to the current configuration version as it is written, so the running application reads it at once.
  • On every save and at the end of the upgrade, members that no longer exist in the configuration model and members the editor can no longer show — the options of a widget’s previous type, the pie labels of a bar chart, the SQL source of a trace reading M-Files — are removed from the stored JSON. The rules are read off the configuration classes themselves, so a new setting is covered the day it is declared.
  • Field rows in forms are ordinary cells with a sub-grid, so their fields widen in a narrow pane like everything else.
  • The Gantt’s name column re-measures whenever the layout changes its cell, not only on a window resize.
  • The configuration overview pages (portal wireframe and facts) read the new sections.
  • Two administrators, one dashboard: after a save the editor now holds the dashboard exactly as it was written - the new revision, the identities of the elements it added, and what a merge brought in. It used to keep the copy it had loaded, so a second save from the same editor was treated as a merge against its own previous save: a segment added and saved, then renamed, was refused with set to “123” by them, set to “1234” by you. A merged save now says so in a message rather than reloading the node, and a save that changes the Title renames the node in the tree at once.
  • A dashboard or portal saved with a component that has no Type is refused before anything is written, and the message names the place by the elements’ names - At Components › “Sales” › Components › element 1 - instead of the serializer’s path from the root of the whole configuration.
  • The server log now says who saved, added, removed, backed up or restored configuration, which item, from which revision to which, and whether the save was merged with or refused because of someone else’s - so a “someone else changed it while it was open” can be followed up.
  • Faster start after installing a new build: the configuration rewrite the framework performs once per new build (19 of a 23 second start, measured) is now computed a few seconds after the application has started instead of while every client call is rejected, and its result is stored at the following start in a fraction of a second. A configuration save made in between takes precedence. A configuration whose version actually changes is still brought up to date before the application starts.
  • Multi View: while a card, event or bar is being saved after a drag (a slow check-in, a workflow script), it shows a spinner and cannot be dragged again, in any mode; a second drop used to fail with “The object is locked”.
  • Plot: a visual whose Data source type was changed (SQL to M-Files or back) failed with “Value cannot be null. Parameter name: Data Source” in a client that had loaded the configuration before the change, until the shell was reloaded. The server now runs the visual as it is configured, whatever the client’s copy says. The same error appeared when two visuals shared an identity (a widget pasted as JSON from another keeps its hidden guids) and an M-Files visual was silently run as its SQL twin; the request is now matched to the visual of its data source type and name, and the server log names the twins. Saving a portal or dashboard now gives every pasted copy identities of its own, and Validate on the application lists any copies still sharing one, naming the elements to save. An SQL data source with no Server Name now says so, by name.
  • A save refused by M-Files now says why in the toast - the workflow precondition that failed, the object that is locked - instead of “COMException, see the server log”. Every error toast shows M-Files’ sentence only (the standalone Calendar used to show the whole server call chain); Copy still copies the full text for support.
  • Plot and Plot View: the table that opens when a point is clicked no longer offers editing by default. A new Drill-down: allow editing switch turns it on, like the lists’ Allow editing.
  • Plot and Plot View: Aggregation is no longer flagged as required in the configuration editor; left empty it means Count.
  • Configuration editor: an option that is left unset now shows the value the portal will use (450, Week, Yes, …) as its placeholder instead of “(not set)”, and no option with a default is marked as required any more (the SQL data source Type, the slider options, an event type’s colour and a visual’s data source type were). Nothing is written into the configuration for it. A newly added visual shows its M-Files Configuration straight away (M-Files being the default data source) instead of only after Data source type is set by hand; likewise an SQL parameter’s Property and a theme’s Color Rules.
  • Plot View: a Scatter plot with Cumulative on now shows the running total (only Line did).
  • Layout: components one, two or three columns wide keep their width on narrower screens - eight 2-wide tiles now share a row on a laptop where they used to wrap into two rows of quarters.
  • Calendar (the widget and the Multi View’s calendar mode): with no Height set, the calendar now fits the height the page has left for it, controls and legend included, instead of overflowing the pane by the legend.
  • Segments: the full-screen corner is gone from a segment with No style and from a segment configured sixteen wide; narrower segments keep it, also when a narrow screen stacks them; Esc still leaves full screen.
  • New M-Files Web: a dashboard opened while looking at an object’s version history no longer keeps the Version history title bar above it, and the pane’s 12px gap above the dashboard is gone.
  • The classic (older) M-Files client failed to load when a dashboard in a group had Display mode = Hidden (“Unable to get property ‘length’ of undefined”, arrays.js).
  • Calendar and comments components read their height and options from their own section; an unset calendar no longer errors on a missing business-hours object.
  • The full-screen corner of a segment re-lays out the segment’s grid on entering and leaving.
  • The configuration is upgraded in place to version 2.0 at the first start of this version. Export the configuration before deploying, and upgrade every server of a multi-server vault together: an older build reading a 2.0 configuration finds the per-type sections it does not know and loses them on its next save. The pre-upgrade text is kept as a backup in the vault (Restore backup from … (upgrade 1.0 -> 2.0)).
  • One Width per element. Use Advanced Width (computer / tablet / mobile), Stackable and Doubling are removed from every element. An Advanced Width’s Computer value becomes the Width; tablet and mobile values are dropped. Review portals that relied on Stackable = false: their rows now widen in narrow panes too.
  • Defaults are no longer stored. Existing values equal to the old defaults are removed by the upgrade; behaviour is unchanged, the editor shows the field empty and its help text names the default. Members that decide which other members are shown (a trace’s Data Source Type, a list view’s Group by type, an aggregation, the axis orders) keep their default and stay stored.
  • List View gains Allow editing, off by default: a list that offered cell editing in 3.26.9.28 does so again once the option is turned on.
  • The Markdown Editor gains File; Calendar gains First day of week, and an event type’s Text color is optional (an existing white default is removed by the upgrade, so events on light backgrounds switch to black text).
  • A save refused with Could not save … Conflicts: … has written nothing; reload the item and apply the change again. A save refused with the copy you started from is no longer kept means more than ten saves happened while the item was open.
  • Backups and revision history live in Named Value Storage under CtrlDocs.Portals.ConfigurationBackups and CtrlDocs.Portals.ItemHistory.<guid> (system-administrator type; the text is unredacted).