| Feature | Summary |
| Master > Admin > Properties - configurable retention windows for webhook request and data trigger logs | Webhook processing has been hardened and three log-retention windows are now configurable under Master > Admin > Properties.
- The scheduled webhook processor no longer slows down or times out on sites with a large webhook request history. Its lookup now scales with the number of pending webhooks instead of the size of the entire request log.
- A new Webhook Request Retention property controls how many days webhook request and response log rows are kept (default 90). The most recent request per webhook is always retained, so the webhook Deliveries view still shows the latest delivery. Set it to 0 to remove all older rows on each clean up, or -1 to disable retention and keep full history.
- Two data-trigger retention windows that were previously fixed in code are now visible and adjustable here too: Data Trigger Retention (completed, error, cancelled, aborted rows, default 30) and Data Trigger False Condition Retention (false and invalid-condition rows, default 7). Same convention: 0 deletes all on each clean up, -1 disables.
Retention is enforced by the existing Clean Up utility, so nothing is removed until the next clean up runs. On update, a supporting database index is added automatically to speed the webhook lookup. |
| FormTaxonomy / TaxonomySearch CpScripts - Data Filter category counts now stay fast on large modules | The FormTaxonomy and TaxonomySearch CpScripts (Script Builder tools) can be given a Data Filter of cpsys_CurrentModule (or a module system name), which limits the taxonomy list to categories that actually contain content and shows a document count beside each one. That count and the empty-category hiding are now calculated with a single set-based query, instead of scanning the module's content once for every category. The behavior is identical - the same categories, the same counts, the same hidden empty categories - but it now renders quickly no matter how many categories or documents the module holds.
Previously, on large repositories (tens of thousands of documents across many categories) the Data Filter could take tens of seconds or time out while it counted each category individually. It now returns in well under a second - validated against a 3.4 million row module, where the full calculation completed in about 1.9 seconds.
This affects any page using the FormTaxonomy or TaxonomySearch CpScript with a Data Filter pointed at a module. No configuration or content changes are needed - existing pages get the improvement automatically. |
| Broadcasts > Reporting - email broadcasts now relay directly to the configured mail server (fixes sending on newer Windows Servers) | Email Broadcasts now send directly through the mail server configured in Admin > Settings (Email Server) when a real mail server is specified, instead of relying on the local Windows IIS SMTP pickup service. This restores broadcast delivery on newer Windows Server versions (2022/2025), where the legacy IIS SMTP feature is no longer available and broadcasts were failing to send with a "pickup directory" error.- Installs with a configured mail server (not blank or localhost) now relay directly, using the server's port, SSL, and any credentials set in Admin > Settings.
- Installs with the Email Server left blank or set to localhost continue to use the previous local pickup behavior.
- Sites already using the Data Broadcast module's custom SMTP option are unaffected.
|
| Word Viewer: Floating Shapes Support | The Word Viewer now correctly positions floating shapes, text boxes, and anchored images. Documents containing these elements are rendered with a fixed-layout method that preserves each element's exact position on the page; previously they could reflow out of place. Documents without 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.
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), 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. |
| Word Viewer: Wide Document Support | The Word Viewer now expands to fit documents whose content is wider than the viewing area, such as landscape pages and wide multi-column tables, avoiding horizontal scrolling where possible. No configuration or file changes are required. Fit still depends on screen size, so very wide document pages on small screens may still scroll horizontally. |
| Module Properties > Visio Structured Extraction | This feature extracts the workflow structure from a Visio diagram when a record is saved. For example, the steps, decisions, swimlanes, and connections in a .vsdx file stored in a source attribute can be saved to a designated destination attribute as formatted text or JSON. The module property is available in all GenericEnhanced modules. See the help file for configuration assistance and functional specs. |
| Development > Process Monitor - redesigned with live status, step timelines, and abort (both Master and Administrative Console) | The Process Monitor has been rebuilt as a modern, single-page view of all background processes - both currently running and completed - replacing the old auto-refreshing grid. It is now available on both the Master (Master > Development > Process Monitor) and the client site's Console (Development > Process Monitor), served from one shared component.
- A summary strip shows counts by status: Running, Stale, Succeeded, Failed, and Orphaned.
- Each row shows the process type, site, user, relative start time, and duration. Running processes update live and their elapsed time ticks up.
- Status is determined automatically: a process actively reporting progress reads Running; one that has gone quiet recently reads Stale (it may still be running); one silent past the cutoff reads Orphaned (started but never reported finishing); completed ones read Succeeded or Failed.
- Clicking a row expands a step-by-step timeline of the process, with timing between steps and any reported errors. Simple formatting within step messages now renders correctly.
- Running processes that support it can be aborted from a confirmation dialog (administrators only).
- The list auto-refreshes (slowing automatically when nothing is running) and can be filtered by status tab, searched by type/user/site, and narrowed by process type.
- A built-in How this works panel explains each status, including the difference between Stale and Orphaned.
- On the client site Console the view is scoped to that site's processes; on the Master it shows all sites.
|