| Feature | Summary |
| Weekly Maintenance 8.12.11 - site search self-heal, update-install serialization, an API authentication status change, security fixes, and console clarity | The weekly maintenance release for 8.12.11. Two items below need attention on installations with custom code or custom integrations, and are called out separately at the end.
Site search- A stalled search index now recovers on its own. The health check previously treated any index reporting an active population as healthy and busy, so an index whose population had stopped progressing was skipped on every sync and cleanup indefinitely, and the site returned no search results with no error. It is now treated as stalled once it has run past a generous threshold with nothing indexed against a table that has rows, and repaired - releasing automatic change tracking first, because the database engine otherwise declines the stop request and the index stays stalled.
Updates and deployment (Master)- Concurrent update installs are prevented. The pipeline uses one fixed working folder, and a finishing run removed it before stamping the version, so a second in-flight run lost its extracted package and failed reporting an incomplete update package. Installs are now serialized per installation and a second run declines cleanly.
- A reused backup is verified before it is trusted. A completion marker is written only after every file has copied, and the retry path requires it, so an interrupted backup is no longer treated as complete. Long file paths are handled throughout, including the marker itself.
- A leftover file that cannot be deleted no longer aborts an install after the file tree has already been replaced, which previously left a partially applied update.
- Removing a deployment target no longer fails with a database syntax error.
Scheduled tasks (Master)- The scheduled-tasks endpoint execution timeout is raised to 5 hours, so a pass on an installation with many sites no longer ends part-way. See the web.config note below.
- The webhook step that runs first on each pass now retries a transient database failure instead of reporting an error and skipping the pass. Only failures that fail immediately are retried; a command that already used its full time budget is not, since re-running it would hold the queue for the same result.
- The nightly cleanup task and the development build task now coordinate across the whole server rather than only within one application, closing a case where a restart between them allowed an overlap that left the cleanup hanging.
Processes and error reporting- The stale-process sweep now clears every orphan in one pass. A single failure previously ended the sweep, so a backlog cleared at roughly one per night.
- The error-reporting path itself is now tolerant of failure, so a problem while recording an error cannot interrupt whatever was reporting it.
- Failures reaching the central error-reporting service are classified correctly again, restoring the rate limiting they had lost.
- A.D.A.M. content-service failures are now reported instead of being written to a trace channel that is disabled outside development, where an outage produced an empty result that looked like a customer with no products.
- A request that is aborted mid-page - a timeout, a recycle, a visitor navigating away - is no longer reported as a Module Designer Results View failure against a correctly configured view.
Console- On
AI Governance > AI Providers, the model row now labels itself by what its button actually does. It previously read Set as Generative Default on every provider, but only the provider card's button switches the active provider; on any other provider the model row records the model and leaves the active provider alone, while still reporting success. It now reads Use as this provider's model in that case, and the dialog and confirmation say so. - On
API > API Test Center, a failed Site Info call reports the real reason instead of a NullReferenceException. Where the API returns no message, which is normal for an authentication refusal, the card says so and names where to look.
Security- The SAML callback test page validates its return path at the source rather than trusting the query string, closing an open-redirect and a script-injection route, and its identity-provider lookup is now parameterised.
- An upload path is decoded before validation and its resolved location confirmed inside the site root before any file is written, closing a path-traversal route through an encoded value.
Other- The vector orphan cleanup is batched so the recurring reconcile sweep no longer times out on a large backlog.
- A signature form no longer fails when its temporary image cannot be removed. Pressing Start Over previously produced an unhandled error and lost the visitor's signature if the file was briefly held by another process. Also applied to the change-request approval flow.
- The website activity log no longer shares one buffer across request threads, and no longer drops entries when a flush coincides with a page write.
- A site's most recent backup date is now the newest backup rather than an arbitrary one.
ACTION 1 - web.config change. This release includes a sync-invoked change to the Master site's web.config: the ` block for WebServices/ScheduledTasks.asmx has its executionTimeout raised to 18000 seconds (previously 900). The deployment updates the Master site's own web.config` only.- A virtual directory that runs as its own IIS application has a separate
web.config that this deployment does not touch. If such a sub-application serves this endpoint or inherits configuration expectations from it, apply the same change by hand in that application's own web.config, or it keeps the old limit and the task can still end early there. - A client-specific
` block for the same path will conflict. If your installation already defines its own , confirm after the sync that the effective executionTimeout` is the intended value and that your other attributes in that block survived.
ACTION 2 - API authentication failures now answer 401 instead of 403. A request carrying no credentials, or a session cookie that fails validation, is not authenticated, which is what 401 Unauthorized means; 403 means authenticated but not permitted. The API now returns 401 with a WWW-Authenticate: Bearer challenge. This also fixes a real symptom: the console's API client only refreshes and retries on a 401, so a page left open past the token lifetime received a 403 that never reached the refresh path and showed what looked like a permissions error until reloaded. Any custom integration, script, or monitoring rule that tests specifically for 403 to detect a missing or expired credential should be updated. A genuine authorization refusal, where the caller is authenticated but lacks access, still returns 403.
Separately, a web site's Modify Date now reports its own value rather than repeating the Last Update Date, so the two can legitimately differ on existing installations - review any custom code that relied on them matching. |
| Data Transform > Data Transfer — JSON source can select the table by name, not just by index | The JSON source in the Data Transfer module can now select which table to read by name instead of only by its numeric position. A new Get Table By option (JsonGetTableBy) lets you choose Index (the existing behavior, the default) or Table Name. Choosing Table Name reveals a Table Name field (JsonTableName) where you enter the table's name; matching is case-insensitive and ignores surrounding spaces.
This solves feeds whose table position shifts from page to page (common with nested third-party APIs), where the correct index number kept changing and had to be re-checked on every run. If the entered name isn't found, the transfer fails with a clear message in the Process Log that lists every table name discovered in the response — so you can copy the exact name — rather than silently reading the wrong table.
Existing transfers are unaffected: any transfer configured with a number continues to use that index with no changes and no re-validation. |
| AI Governance > AI Data Source Tuner - AI data sources and AI search now respect multi-tenant filtration | On sites using Multi-tenant Audiences filtration, the Page Assistant now applies the same tenant filtering to AI data sources and AI search results that a page already applies to its content. Previously a visitor could be offered a data source, or see a search result, that the equivalent page would have hidden from them. Sites that do not use multi-tenant filtration are unaffected and see no change in behavior or speed.
Custom tenant rules are honored as-is, including installations with their own tenant provider, so no configuration changes are required.
Note that AI Governance > AI Data Source Tuner is a console tool and is intentionally not tenant filtered, matching how every console screen behaves. It will therefore list every data source flagged Available to AI, including ones a particular visitor would not be offered. This is expected and is the correct way to review the full set.
|
| Console login - login source is now verified, and ancestor admins may be asked to sign in once | The record of which console a user signed in from is now verified by the server on every request instead of being taken at face value from the browser. This closes a gap where a signed-in website member could present themselves as a Master or Uber administrator and see content outside their own audience and role scope, including through the API and AI search results.
Front-of-site visitors are not affected and will not be signed out. The first time a site is updated, an administrator who signed in from Master or Uber and is working in a console may be asked to sign in once more; after that, sessions behave exactly as before. No settings need to be changed and there is nothing to enable. |
| Forms — Content Security Policy hardening | Form and search buttons previously deferred their submission by handing a string of JavaScript to a browser timer. Browsers treat that as dynamic code compilation, which a Content Security Policy blocks unless the 'unsafe-eval' directive is allowed. On sites enforcing a policy without that directive, form and search submissions failed silently. Buttons now defer through a direct function call instead, so no code is compiled from a string. Submission behavior is otherwise unchanged.
This affects every FormButton and FormImageButton that does not supply a custom onclientclick, which is the standard configuration. Buttons using postBackUrl, or formAction set to ExecuteSearch, submit across pages and are the most likely place to notice any difference.
The same pattern was corrected in several form controls and module views that also handed strings to browser timers: the FormEditor rich text iframe, the FormTaxonomy, FormAudience, FormPagedListBox and FormDataListBox pickers, the FormOneDrivePicker, the form builder used by the Forms Wizard, the Mail Contacts Calendars session timeout, and the timed automatic submission in Education and OCE tests. Script versions were bumped for each, so browsers fetch fresh copies on first load after this sync. |
| Data Transform > Data Transfer - Cleanup can no longer stop the application pool | Data Transfer sources and destinations release their files, connections and other resources when a transfer finishes. If that cleanup was left for the system to perform later instead of happening at the end of the transfer, it could run at a point where the information it needed was no longer available - and a failure there stopped the entire application pool, dropping any requests in progress. Because it happened outside the normal error path, it was never recorded in the Errors list; it appeared only in the server's event log.
Cleanup is now performed only at the proper point in a transfer, and a cleanup problem is reported through the transfer's status instead of being discarded or allowed to stop the pool. Several sources and destinations were also made tolerant of a transfer that fails while starting up - a delimited text or Excel source, a SharePoint source, and a staff list source - so they close cleanly rather than raising a second error on the way out.
QC Notes:
URLs: https://master.xodev26.com/ScheduledTasks.aspx?sn=ScheduledTasks |
| Master > Development > Errors - API errors that were previously only in the server's event log now reach the Errors list | The API now reports errors it had been handling quietly. Previously, when the API hit a problem it could recover from, it recorded the details only in the Windows event log on that one server - so the error never appeared in Master > Development > Errors and was invisible unless someone signed into the server and looked. Those errors now reach the central Errors list alongside everything else, with the local event log kept as the fallback for the one case it has to cover: the central store itself being unreachable.
Two safeguards ship with it. Repeated occurrences of the same error collapse into a single entry rather than filling the list, and a set of routine, high-volume messages were reclassified as warnings so they stay out of the Errors list entirely - health checks, per-request AI and Word Add-In failures, background retries that resolve themselves, and rejected sign-in tokens. The intended net effect is more genuine issues visible and less noise, not simply more entries.
Sensitive request values are now removed before an error is stored. Authorization headers, agent secrets and cookie values are replaced with [redacted], so a stored error can no longer contain a live credential. Other request details - page address, referrer, browser - are unchanged, since those are what make an error diagnosable. |
| Admin > Global Login — Word Add-In SSO returns to the plug-in after MFA; failed-SAML-login page now redirects home | - Word Add-In sign-in. After completing MFA, the Word Add-In sign-in now returns directly into the plug-in instead of landing on the site dashboard, so users no longer have to close the sign-in window by hand for the plug-in to load. The return destination is now carried through the identity-provider round trip via SAML RelayState, which survives the session loss that happens inside the Office sign-in dialog. Only the Word Add-In sign-in flow uses this; all other SAML logins are unchanged.
- Failed-SAML-login page (affects all SAML clients). The page shown after a failed SAML login now sends the user to the site home page (/) after a short delay, instead of refreshing the failure page in place. This is a side effect of hardening that page's automatic redirect against a cross-site-scripting / open-redirect issue. Successful logins are unaffected.
|
| Design > Dynamic Tab Display - tab links now open the first tab, and the remembered tab is per record | =====================================================================
CHANGES MADE
=====================================================================
Two fixes to how the Design > Dynamic Tab Display module decides which tab opens.
Tab links now work for the first tab. A tab= parameter on a page URL selects the matching tab. Previously every tab number worked except the first: tab=1 was ignored. On tab sets with Remember Clicked Tab enabled that meant the page opened on whatever tab was last visited instead of the first. Elsewhere the first tab opened regardless, so the problem was only visible where that option was in use. Links pointing at the first tab now behave like all the others.
The remembered tab is now specific to the record being viewed. When Remember Clicked Tab is set to Yes, the last tab clicked is restored on the next visit. Because one configuration record is shared by every document in a Details View, that memory previously carried from one document to the next: opening a record on its third tab and then opening a different record landed on the third tab of the new record as well. The remembered tab is now tracked per document, so each record opens on its first tab while still restoring the correct tab after a form submission on that same record.
The Active Tab property is unchanged, as is tab behavior on pages that are not Details Views.
One time reset. Existing visitors have a stored tab position in the previous format. It is discarded on the first visit after this update, so tabs open on the first tab once per user. No configuration change is required.
|
| Design > Data Sources - Raw HTML sources can now be exposed to the Page Assistant | The Raw HTML formatting option is now certified for the Page Assistant, joining Chart (Advanced). On a Data Sources record with FormattingOptions set to Raw HTML, the Available to AI switch now appears; turning it on reveals AIDescription, AIPresentation, and AIShowExpand exactly as it does for charts.
When the Page Assistant selects a flagged Raw HTML source, the record's rendered markup appears inline in the chat reply - including its own RHStyles and RHScripts - produced under the asking user's own permissions, not the author's.
Two changes affect all certified render types, not just Raw HTML:
- Rendered output now matches the conversation's text size. Previously a data source rendered in a chat reply inherited the host page's base font size, so text-based output appeared noticeably larger than the surrounding conversation. This was not visible with charts, which contain no text.
- Eligibility scanning has been hardened. A source whose templates used the
cpsys_Apos script-safe placeholder to wrap a request-context script - Querystring, cookie/session, or current-record scripts - previously passed the eligibility check and will now correctly show as Excluded. This closes a gap where such a script could run in the detached render. Any affected source will name the offending script in its exclusion reason in the AI Data Source Tuner. This applies to existing Chart (Advanced) sources as well as new Raw HTML ones.
|
| Word Viewer — multi-column Word documents now keep their column layout | Changes Made
The Word Viewer now preserves Word's multi-column page layout. A document that uses Layout > Columns in Word (a two- or three-column newspaper flow) previously rendered as a single stacked run of paragraphs, losing the side-by-side arrangement of the original. These documents are now rendered with the same fixed-layout method already used for floating shapes and anchored images, which reproduces the column flow exactly as Word lays it out. Documents that do not use multiple columns or floating shapes continue to use the standard responsive rendering and are unaffected.
Note on these documents: because fixed-layout pages keep their exact dimensions, they are not responsive. Very wide pages on small screens may require horizontal scrolling.
Important for documents already viewed: the viewer only re-renders a document when its source file changes, so a multi-column document that was viewed before this update keeps serving its cached single-column version. That document's cached file must be deleted once for the new column layout to appear.
Clearing the cached file for a problem document
The viewer saves each converted document as an HTML file under the site's Temp\AsposeWordViewer folder so it does not re-render on every view. If a specific document renders incorrectly and needs to be regenerated (for example, after the source document is corrected, or for a multi-column document viewed before this update), delete only that document's cached file.
Cache location: [site]\Temp\AsposeWordViewer\[document folders]\[filename].html- A document at
/Uploads/Policies/charter.docx is cached at ...\Temp\AsposeWordViewer\Uploads\Policies\charter.html - Resource-based documents are cached at
...\Temp\AsposeWordViewer\Resources\[resourceId].html
Steps:
1. Locate the .html file that matches the problem document under Temp\AsposeWordViewer.
2. Delete that single file.
3. Reopen the document in the viewer; it regenerates automatically on the next view.
Important: delete only the specific problem document's cached file. Do not clear the entire AsposeWordViewer folder. Every viewed document is cached there for performance, and removing all of them forces every document to re-render.
|
| Forms > Forms Wizard - added Cloudflare Turnstile as a CAPTCHA option in FormCaptcha | The FormCaptcha form control now supports Cloudflare Turnstile as a fourth CAPTCHA provider, alongside the classic image CAPTCHA and Google reCAPTCHA v2 / v3 Enterprise. Turnstile is a privacy-friendly CAPTCHA (no cookies, no user tracking) and is HIPAA-compatible, giving forms that collect sensitive information an alternative to Google reCAPTCHA.
When configuring a Captcha element in Forms > Forms Wizard, setting Use ReCaptcha to No now reveals a Use Cloudflare Turnstile option. Turning it on shows a Cloudflare Instructions help panel (step-by-step account setup with links) plus fields for the Turnstile SiteKey and Turnstile SecretKey (both required), and optional Theme, Size, and Action settings. The widget renders on the published form and is validated on submit against Cloudflare''s verification service. Existing forms using classic CAPTCHA or reCAPTCHA are unaffected. |
| Site Navigation - resolved intermittent navigation and console errors on long running sites | On rare occasions a site could report an error stating that a type "cannot be cast to" itself, most often on pages using the NavigationSectionMenu script, in the console navigation, or in a shopping cart. This happened when the server briefly held two compiled copies of a site's application code at the same time, usually after files were updated or the application restarted. The affected pages have been reworked so they no longer depend on which copy is active, and they now recover on their own instead of failing. Where a page previously stopped with an error, it now rebuilds what it needs and continues. There is no change to how any page looks or behaves under normal conditions. Clients who have seen these errors, including intermittent failures in the console audience and site wizard screens, should no longer see them.
|
| Design > Dynamic Navigation - menu stylesheet is now cached, removing a database read from every page load | The stylesheet that renders a Dynamic Navigation menu was rebuilding itself from the database on every request instead of using its cache. The cached copy was being stored correctly but could never be read back, so each page that displays a dynamic navigation menu paid for an extra database lookup before it could render. The stylesheet now reads its cache correctly and serves the stored copy. Menus look and behave exactly as before; the only change is that the extra database read is gone. Sites that use Dynamic Navigation on high traffic pages will see the largest benefit. The cache still clears automatically whenever a dynamic navigation record is edited, so style changes continue to appear immediately.
|
| Forms > Forms — signature fields now resolve their save location on the server | Signature capture fields on a form now determine where the signature image is saved entirely on the server, using the location recorded when the form was displayed. The submitted request can no longer influence the save location at all. If that recorded location is missing — most commonly because the visitor's session expired while the form was open — the signature is refused rather than saved to a fallback location.
This is a security hardening change. The practical effect for visitors is that a signature submitted after a session has expired will not be saved, where previously it may have been written to an unintended location. Forms completed within a normal session are unaffected.
A separate correction in the same area fixes cases where a validly configured save location could be rejected, depending on how the folder path was written in the site's configuration. |
| Reporting > Report Builder — clearer message when an export format is not recognised | Exporting a report with an unrecognised or mis-typed format value now returns a clear message naming the formats that are supported, rather than failing with a generic error. Format names are also matched without regard to capitalisation, so a value such as tabdelimited is accepted the same as TabDelimited. This most often surfaced when a browser extension or a copied link appended extra text to the address. |
| AI Governance > AI Providers — copy a model id, failover guidance, and a retired OpenAI model flagged | The AI Governance > AI Providers page now offers a quick way to copy a model's id to the clipboard, so it can be pasted into a module or provider configuration without retyping it. A short note has also been added explaining how provider failover behaves.
Separately, OpenAI's gpt-5-chat-latest model has been retired by OpenAI and now returns an error if selected. It is still listed, marked as retired, and shows its replacement so any site still pinned to it can be moved across rather than silently failing. New installations now default to gpt-5.5. Existing sites keep whatever model they already have configured and are not changed automatically — a site pinned to the retired model needs to be updated manually. |
| Admin > Properties - Sync Exclusions now accept wildcard patterns | The Sync Exclusions property on a web site (Master > Content > Web Sites) now accepts wildcard entries using ?, in addition to the existing exact paths and file names. This lets a site protect a whole family of custom assemblies with one entry — Ebix., Syncfusion., haymarket — instead of listing every file individually. Both entry styles accept wildcards: a bare pattern such as Ebix. matches at any depth, and a rooted pattern such as /Bin/Ebix. matches that path only.
Wildcard entries protect a file from being removed, but never from being replaced. This is deliberate. An exact entry has always meant "leave this file alone entirely," while a wildcard entry means only "do not delete anything matching this." That distinction is what makes the feature safe: a pattern can never accidentally block delivery of a platform file, which would leave a site with mismatched program files. Exact entries keep their existing behaviour unchanged.
Previously, a site whose exclusion list did not name every custom assembly lost the unlisted ones on every update — the update removes anything absent from the delivered package, and a parent-to-child sync hid the problem because the parent still had the files. An incomplete list is the common case, since it goes stale as soon as a client adds an assembly, so declaring families rather than individual files is now the recommended approach.
The same exclusions are now honoured in three places that previously did not consult them fully: the sync to a load-balanced secondary server, the My Updates deployment, and the repair operation. Repair reads them from a small generated file in the site's App_Data folder, written on each sync — so a site must complete one sync on this version before repair can honour its list.
Note that the on-screen help text for the Sync Exclusions field has not yet been updated to describe patterns. |
| Design > Media Manager - added Created, Roles, Audiences, Groups, and a file-link column to the grid | Changes Made:
The Media Manager grid (Design > Media Manager) now shows additional columns so staff can scan and organize the media library more easily:
- Created - the resource creation date, sortable, alongside the existing Modified column.
- Roles - the roles assigned to each resource, shown as names.
- Audiences - the audiences assigned to each resource, shown as names. This populates only when resource audiences are enabled for the site; otherwise it appears blank.
- Groups - the Resource Groups assigned to each resource, shown as names.
- Link - an "Open" link that opens the resource file in a new browser window.
Roles, Audiences, and Groups may list multiple values separated by commas. The new columns are display-only (Created is sortable). No configuration or database changes are required. |
| Data Transform > Data Transfer: new Microsoft Teams Meetings source | A new Microsoft Teams Meetings source type is now available in the Data Transfer module (Data Transform > Data Transfer). It imports Teams meetings into Centralpoint as one record per meeting, capturing the meeting title, date and time, duration, organizer, participants, chat, transcript, recording link, and shared files.
It offers two capture modes, selected by the new Source User Scope option:- My meetings signs in as a single user and imports the meetings that user organized.
- Cross-user modes (Pick users, All users, By department, By group) run organization-wide and import meetings organized by the selected users, using an application (org-wide) authorization plus a Microsoft Teams application access policy.
Additional source options include a Source Date Range (rolling last-N-days, or a fixed UTC window) and Download Shared Files (store shared files as links, or download them into Uploads). Each meeting is assigned a stable identifier so repeat runs update existing records instead of creating duplicates: set the destination to Incremental (Insert/Update) matched By DataId, with Delete = Previous Execution of this Transfer so cancelled meetings drop out automatically.
Because the connector reads Teams data through Microsoft Graph, the client's Microsoft 365 administrator must grant the required Graph permissions, and for cross-user modes create a Teams application access policy. Full setup steps are provided in the tenant setup guide. |
| Admin > Settings — Upload & Data Limits saves are now validated, floored, backed up, and recoverable, and apply to both the Website and the Console | The Upload & Data Limits section under Admin > Settings (Max JSON Length, Max Request Length, Execution Timeout, Max Allowed Content Length) has been hardened to make configuration changes safer, consistent across applications, and reversible.
- Improved validation. The Upload & Data Limits fields are now validated when Save is clicked, so out-of-range or malformed entries are caught up front with a clear message under the field rather than being accepted.
- The change is checked before it is applied. Before the site's configuration is updated, the pending version is verified to be structurally valid and the Upload & Data Limits values are confirmed to load correctly. If anything is invalid, the save is aborted and the current configuration is left in place, so a bad entry can't leave the site unable to start.
- Automatic backup on every save. The current configuration is backed up immediately before each save (last-known-good) so a change can be undone in one step. Backups are kept under the site's
Temp\Console_Settings folder, organized into per-application subfolders (Root for the Website, Console for the Console). If a backup can't be created, the save is aborted and nothing is changed. - Applied to the Console application too. The Upload & Data Limits are now applied to the Console application's own configuration, not just the main site, through the same validate-backup-apply path. One save now covers both applications, so there is no hidden second edit to remember. Only the top-level settings are written, so the Console's per-page overrides are preserved. This matters because some controls are shared between the main site and the Console and rely on these settings (particularly Max JSON Length), so applying them in both keeps behavior consistent. A blank field removes the setting in both configurations, so the two stay in step.
- Execution Timeout guardrail. An Execution Timeout above 3600 seconds (1 hour) now requires the administrator to tick an acknowledgment checkbox before the save proceeds, because an over-high global timeout can hold a worker thread and risk exhausting the server's thread pool. The checkbox and its message appear as soon as a high value is entered (on leaving the field), and the save is blocked until the box is ticked. The acknowledgment is required again on each save that keeps a high value.
- Minimum values (floors). Each field is now floored at its framework/IIS default (Max JSON Length 2097152 bytes, Max Request Length 4096 KB, Execution Timeout 110 seconds, Max Allowed Content Length 30000000 bytes). Below-default values have no legitimate use from this page (blanking a field already yields the default) and a too-small Max Request Length or Max Allowed Content Length could reject the Settings save itself and lock the administrator out of the Console. Setting a value below a default still requires a manual web.config edit.
- New info callout. A notice above the Save button explains that the limits apply to both the Website and the Console, that the minimum values are the framework defaults, and that every save is automatically backed up (and where to find the backups).
|