Lime CRM Desktop Client 11.3.4523

Product

Lime CRM Desktop Client

Version

11.3.4523

Date published

2026-06-05

Platform

Windows

Availability

Manual installation, Reference

Cumulative release for 11.3.x covering everything since the 11.3.4502 baseline.

• Find a related record by typing its id. Typing a number that is a record's id into a relation field's search now pins that exact record at the top of the dropdown, even when the record's description does not contain those digits. The match resolves instantly from the already-loaded entries, or is fetched from the server when the record has not been loaded yet. The matched id is shown as a bold, right-aligned badge on the pinned row so it is clear why that row is there.

• Multi-value option fields can be operated from the keyboard. Fields that present a checkbox list of options (multi-select “set” fields) now support full keyboard use: Down or Space opens the dropdown; the arrow keys, Home / End and Page Up / Page Down move the highlight; and Space checks or unchecks the highlighted option. Previously these fields could only be operated with the mouse.

• Type-to-find inside multi-value option fields. With the dropdown open, start typing to jump the highlight to the first option that matches what you have typed. The current search text appears next to a magnifier glyph in the dropdown footer and clears itself after a short pause with no typing. Backspace erases the last character and Delete clears the search; pressing any arrow key ends the search and returns to plain navigation. While no search is in progress, Backspace and Delete clear all checked options.

• “Check for updates” can offer the publicly released build. Choosing “Check for updates” from the menu now also looks at the build published on the official download page and offers it when it is newer than what your current update channel would provide, up to the version your administrator allows. Automatic background checks are unchanged.

• A view that fails to load because of a field error now names the field at fault. When the database rejects the query behind a view - for example because a field's underlying SQL expression refers to an ambiguous or missing column - the message now points at the specific field and its expression. It suggests removing that relation column from the active view to load right away, and tells you whether to correct the expression in LISA yourself or to ask an administrator, depending on your rights.

• Application.Shell hardens how links and files are launched. The single point that opens links and files for the client - used by automation, the action pad, field and content links, and the phone dialer - now blocks documented protocol-abuse schemes (such as ms-msdt) and elevation verbs (runas) outright, and lets ordinary web, mail, telephony, Teams, Slack and document-management links through unchanged. For a program or document that could be unsafe, the client now makes the decision itself rather than handing the launch to Windows: it checks the file against the Windows attachment and zone rules and, when those would warn, asks for confirmation through its own prompt - shown in your language and the same whether the file is being launched, opened or saved - in place of the Windows “Open File - Security Warning”. When the client runs with no user interface, such as an unattended automation, a flagged target is blocked outright instead of launched. The underlying Windows zone check is never bypassed. Administrators can tighten or loosen the behaviour per machine, including a no-prompt hard-block mode.

• Clicking an option in a multi-value field toggled it twice. A single click on an option in a checkbox-list (multi-select “set”) field checked it and then immediately unchecked it, so the click appeared to do nothing; if the mouse moved between pressing and releasing the button, two different options toggled. A click now toggles exactly one option, on release. Mouse and keyboard handling in these fields was reworked in the same pass.

• “Save as…” on a document could silently do nothing. On machines with a restrictive Windows attachment-security policy, choosing “Save as…” for a document opened the file dialog but then saved nothing, with no error message. The shell security check - intended only to warn about risky files - was being applied before the file was written and treated a policy block as a silent cancel. The check now runs the same way it does when opening a document: a file the policy considers unsafe raises a prompt offering to save it anyway, while an ordinary document saves without interruption.

• A saved document's file name could repeat its extension. When a document record carried its name with the extension already included, saving it produced a doubled name such as report.pdf.pdf. This affected “Save as…”, the multi-document save, and documents attached to an outgoing e-mail. The extension is now appended only when the name does not already end with it.

• Copying a record could leave out a field named like a built-in column. Copying a record (Record.Copy / CopyTo) skipped any field whose name matched a system column - most often a customised status field - treating it as the built-in column and excluding it, so the copy came back missing that value. Such fields are now copied; only the genuine built-in system columns are skipped.

• Opening an inspector could occasionally hang. When an inspector's VBA read a record value that was still being lazy-loaded, the UI thread could take the record's lock and then wait for the background load, while the load worker waited for that same lock to deliver the value - a deadlock that froze the application. The pending load is now drained before the lock is taken, and its result - the loaded value or a load error - is applied or surfaced rather than left unhandled.

• The application could freeze in several more situations involving record locks. Following the inspector fix above, a wider review removed the remaining cases where two operations could each wait on a record lock the other already held and hang the application. The cases covered were: setting a field value that displaces related records, refreshing the choices of a relation field whose options depend on another field on the same record, and the batch operations used by imports and bulk edits, including saving or deleting an attached document during a batch. These paths now release the record lock before calling across to other records or documents.

• A relation field's dropdown could show outdated choices after another field it depends on was edited. When a relation field's option query references the value of another field on the same record (for example, the available companies depend on which country is selected), changing that other field and returning to the relation control kept the previously-loaded choices in view. The dropdown now reloads the choices on return whenever the underlying option set has been dropped - both when typing into the field and when clicking the arrow to open the list.

• The current selection in a relation field narrowed its own search. Reopening a relation field's dropdown on a record that already had a value (with F4 or the mouse) showed only the entries matching that value instead of the full list. The search now filters on what you type, not on the text of the current selection or the autocomplete suffix, so reopening the dropdown shows the broad list again. In addition, Shift+Enter now searches the server first and falls back to the cached results - the reverse of plain Enter - so a fresh server lookup can be forced when the cached list is not enough.

• The client could close unexpectedly when switching away with a field dropdown open. With a relation or multi-value option field's dropdown showing, switching to another application - or an action that hid the open record while the dropdown was still up - could occasionally close the client without warning. The dropdown is now dismissed safely in these situations.

• The login dialog could show the wrong form after switching server. When picking a different server or database from the Browse dialog, the form on screen could remain set to the previous server's login style - the web-based login or the classic username and password fields - so credentials could not be entered until the dialog was closed and reopened. The dialog now resets to a loading state during the switch and then settles into the form that matches the new server.

• The login dialog did not recover when network connectivity returned. Starting the client without a working network connection put the login dialog into an error state that did not clear when the connection came back; the dialog had to be closed and reopened to retry. The dialog now listens for network changes and re-checks the server automatically once an internet connection is available. The automatic re-check only runs while the dialog is showing the error state, so anything typed into a working login form is left alone.

• The active tab could be drawn wrong or stay hidden when tabs were scrolled to the right. With more tabs than fit, when the strip was scrolled so the active tab sat off the right edge, that tab could render incorrectly (for example showing only its icon) or stay out of view. The active tab now draws correctly in this case and is scrolled into view, including the tab that is already active when a record is first opened.

• Hardened rendering of content defined in CRM customisations. Content rendered from CRM customisations is now sanitised across more of the paths it can reach, closing ways that crafted data could run unintended script. Legitimate integration links and custom address schemes are unaffected.

• A checked-in document could be published against the wrong record. When a document was checked back in while it was concurrently repointed to a different document, the check-in could overwrite the wrong record. Check-in now re-confirms the document's identity, not just its file, before publishing.