Lime CRM Desktop Client 11.3.4579

Product

Lime CRM Desktop Client

Version

11.3.4579

Date published

2026-08-12

Platform

Windows

Availability

Manual installation, Reference

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

• See which documents are locked for editing, and release a lock that is stuck. When someone opens a document for editing the client holds an edit-lock on it (see the protection note under Fixed), but there was no way to see what was locked or to clear a lock left behind by someone who never checked their document back in. Any record type that stores documents now offers ready-made filters to find them: “Locked - mine” lists the documents you currently have open for editing, and administrators additionally get “Locked - all” and “Locked - stale” - locks with no activity for more than a day - together with a “Lock details” view that shows who holds each lock and when the file was last touched, oldest first. When a lock genuinely needs clearing, its owner - or an administrator, for anyone's lock - can force it open: the command sits with the other document actions (the Document toolbar menu, the right-click Document submenu, and the document control's Advanced section) and first shows who holds the lock and how long it has been held before releasing it. Releasing another user's lock still requires administrator rights, and every forced release is written to the event log.

• Paste a full server address into the login dialog. The server field in the login and change-database dialogs now accepts a complete web address copied from a browser - protocol, host and any path together - and splits it into the server, database and protocol for you, instead of requiring the bare host name typed in by hand.

• Filter validation catches more cases where a negated condition would include the wrong records. The report that checks a filter now cross-checks each negated condition (such as “not one of” a set) by an extra, independent route: it verifies that the records the condition excludes and those it keeps exactly partition the record type, with none overlapping and none missing. When they do not, the report flags it instead of reporting a clean result and lists the offending record ids, so a fault in how a negated condition is turned into a query is caught rather than passing silently.

• Choose how search results are ordered, per record type. When you search for a record to link into a relation field, the order of the results is decided by the view behind the search. A record type without a purpose-built search view borrowed the order of an ordinary browse view, which is rarely the order you want when searching by description. The search settings dialog now carries an explicit sort setting for each record type: leave it on “Default” to keep the view's own order - the option's tooltip spells out what that order currently is - or pick “Ascending by” or “Descending by” a field of your choice, including a field reached through a related record, to override it. The choice is remembered for that record type and applied to the whole result set, not just the rows already fetched. No existing search changes order until you set this; “Default” leaves everything as it was.

• Create and edit the views and filters behind a search without leaving the dialog. The search settings dialog could only pick from views and filters that already existed; shaping what a search shows meant going off to the view or filter designer elsewhere. Each drop-down now offers “New…” to create one and a “…” button beside it to edit the one selected, opening the same designers in place. The view drop-down also always lists a “[Search]” entry, marked with a magnifier, even before such a view exists: choosing it opens the designer ready to build the purpose-built search view that governs which columns a search shows. The dialog was tidied in the same pass, with a wider search field, labelled icon buttons and the clearer title “Search settings”.

• Open your own record from the Tools menu. A new entry at the top of the Tools menu - named “Edit current” followed by your record's type - opens your own user record (your coworker card) in an inspector, so you no longer have to search for it first. If that record is already open it is brought to the front instead of being opened a second time. The entry appears disabled when your login has no such record.

• Pane dividers now show that they can be dragged. The divider between panes carried only a faint marker, so many people never realised it could be moved to resize the panes. Each divider now shows a clearer handle: a thin line along the divider with a rounded grip at its centre, drawn in the standard raised Windows style and following your theme and high-contrast settings. As the pointer moves over a divider the grip follows it and the divider highlights, so it is obvious where to take hold and that the panes can be resized. The strip of record tabs in an inspector, which doubles as a handle for resizing the pane beneath it, gained the same cue: moving the pointer over its resize area shows the vertical resize cursor and highlights the strip.

• Recently used values are now offered on option fields too. A relation field's menu has long offered a “Recent” shortcut to values you linked before; the same shortcut now appears on fields backed by a predefined option list. It lists only options that are currently valid for the field, and it is never narrowed by whatever you have typed into the field.

• Shortcuts to records related to you. The field menu can offer values reached through your own user record - for example a company or a manager recorded on it. Where it previously offered at most one such shortcut, it now lists every relation from your record that points at the field's target, grouped under a heading naming your record's type (for example “From Coworker”). A relation holding a single value appears directly, as the relation's name followed by the value; one holding several values opens a submenu. Only values that are valid for the field are shown.

• The field menu no longer offers to link a record to itself. On a relation that can point at the same kind of record it lives on - a parent or a manager of the same type, for example - the menu's shortcut lists (“Me”, “Recent” and the related-to-you entries) no longer offer the record you are currently editing, so it cannot be linked to itself by accident. A self-link that is genuinely intended can still be made deliberately through Search or the full list of options.

• The alternatives menu is always reachable with a right-click. On a field whose arrow button opens the search dropdown, the menu of alternatives - recent values, the related-to-you shortcuts, open and unlink, and so on - could not be opened at all. A right-click on the field now always opens that menu, while the arrow button keeps its usual behaviour.

• Option-constrained fields no longer offer ways to set an invalid value. For a field limited to a fixed, predefined set of options, the menu no longer shows “Search…” or “New…”, since either could set a value outside the allowed set - and this now holds however the menu is opened, including the right-click menu on a field whose arrow opens a dropdown. A relation that is merely narrowed by an option query is not treated as such a fixed list: it keeps “Search…” and “New…”, and its dropdown search now applies that option query so only the permitted records are offered. When a field's allowed options resolve to an empty set, the menu shows a disabled “No matches” rather than appearing empty. Together with the valid-only filtering above, every choice the menu offers stays within the field's permitted options.

• Filter validation explains a withheld related value instead of showing a bare number. When you check a filter with the validation report, a condition pointing at a person or coworker record showed only that record's numeric id, with no name and no hint why - looking the same as a value that had failed to resolve. The report now marks such a value with the record's type and notes that the name is withheld for privacy (for example “60201 (Coworker - hidden for privacy)”), so it is no longer mistaken for a fault. The name itself is still kept out of the report.

• Connections use https first, and an unencrypted server is clearly flagged. The client now tries a secure (https) connection before ever falling back to plain, unencrypted http, and only falls back after you have explicitly consented to it - applied the same way across signing in, listing databases and switching server. When a session does run over unencrypted http, which is normally only a local development server, the login dialog makes it plain: a warning icon sits in the lower corner with a tooltip explaining the risk, and the footer is tinted in a warning colour so the whole dialog reads as unsafe. Ordinary secure connections are unaffected and show none of this.

• Line breaks in a filter's notes survive a restart. Notes written on the Other tab of a filter's properties, split over several lines, stayed correct for the rest of that session but ran together into one continuous line the next time the client was started, with the paragraphs pushed up against each other. Notes now keep their line breaks, both in what is saved and in what the properties dialog shows, so a note written as several lines still reads as several lines after signing out and back in. Notes already saved are shown correctly again as well, because the line breaks in them were never actually lost.

• The information window again names users who have no coworker card. The “Created by” and “Modified by” lines in a record's information window were left empty when the user in question has no coworker card of their own - the built-in system account, for example - so a record last changed by such an account looked as though nobody had changed it. The user's own name is shown in that case again, as it was in earlier versions, and it is also used when a coworker card exists but carries no description.

• The browser-engine setting no longer says it needs a restart. The option that selects the Microsoft WebView2 runtime for the built-in browser was labelled as requiring a restart, which is no longer the case, so the note has been removed. The time-zone conversion setting on the same page does still require a restart and continues to say so.

• The options for including a record type's filters and views on cards now take effect. The two settings “Include class filters on cards” and “Include class views on cards” were saved but never read back, so the filters and views defined on a record type were always added to the drop-downs on a card's related-records tabs whether the boxes were ticked or not. They are now read from where they are stored, so clearing a box leaves those entries out. Both labels note that the change applies the next time the client is started.

• The login dialog keeps showing which server you are signing in to during web sign-in. On the web-based (single sign-on) login, the line at the foot of the dialog naming the server and database could disappear as soon as the sign-in page loaded, leaving no confirmation of where you were about to sign in. It now stays visible throughout the sign-in.

• Abandoned document locks are cleared without waiting for the nightly server cleanup. A document left locked with nothing actually checked out - for example after a crash - kept other people out until the server's daily cleanup released it. The client now finds and releases your own such locks itself, when you start up and when you sign out, and keeps the locks you really hold alive with a periodic heartbeat. A lock you are genuinely holding on another of your own machines is left alone.

• The prompt about documents still open on exit no longer appears for no reason. A background helper that keeps document edit-locks alive was being counted as an open document, so the question asking whether to wait for documents open in other programs could appear every time you closed the client, even with nothing open. Only genuine open documents are counted now.

• A filter that counts related records reached through a parent record loads again. A view or filter using a count over a to-many relation reached through a parent - for example counting a customer's unsent orders from the order list - could fail to load with a database error after the recent query rework. The count query is built correctly again and the list loads.

• Changing the filter or view reloads a list even after a failed load. If a list's previous load had failed and latched into an error state, changing its filter or view could be refused by the reload guard, so the list never refreshed. A filter or view change now clears that latched error and the list reloads.

• A key field reached through a related record shows its proper name in a filter's condition text. The identifier of a related record - for example a related agreement's id - was shown as the record type's name in the text that describes a filter condition; it now shows the field's own name.

• Editing a document is protected against two people overwriting each other. When you open a document for editing, the client again takes an edit-lock on it: a colleague who opens the same document while you have it checked out gets it read-only, with a lock indicator showing it is held elsewhere, so a save of yours can no longer be silently overwritten by someone editing the same file at the same time. This protection had not been active for some time. If your team deliberately has several people edit the same document at once and would rather keep that, locking can be switched off - for one file type or for all of them - with the NoLock client setting: set NoLock to 1 under Application\FileExtensions\*.* to disable it for every type (for example HKCU\Software\Lundalogik\Lime\Settings\Custom\Application\FileExtensions\*.*\NoLock = 1), or under Application\FileExtensions\<extension> for a single type such as docx.

• Filters that read a value from your own record now follow changes to it. A filter condition that takes a value from your user record (for example ActiveUser.Record) kept using the value the record held when you signed in, so editing your own card - or having it changed elsewhere - did not affect which records the filter returned until the next sign-in. The cached copy is now refreshed when your record is saved in this client and whenever you force a refresh of a view, so these filters match against the current value. Conditions that use only your record's id are unaffected.

• A “not one of” condition over a relation no longer drops records with nothing related. A filter condition excluding the records picked out by another filter - “not one of” over a relation - also left out every record that has no related record at all, because a record with an empty relation carries no value to compare against the set. Such a record is plainly not in the excluded set, so it is kept again: the condition returns the exact complement of the matching one. A “not one of” condition on an ordinary field is unchanged and still leaves out records where the field is empty.

• An “is not empty” condition could be lost when a filter was optimised. A filter combining “is not empty” on a relation with another condition over a set of values could, after the internal query optimisation, silently drop the “is not empty” part, so the results wrongly included records whose link was empty. The optimisation now keeps the constraint, restoring the behaviour from 11.2.

• The shared field list scrolls and is drawn correctly. In the dialog that creates history records for several records at once - and the other places built on the same field list - the scrollbar's line and page steps did nothing and dragging the thumb snapped to the top, the mouse wheel did not scroll the list, and the field area was painted with the wrong background. The list now scrolls by scrollbar, wheel and drag, and the field area matches the surrounding dialog and theme.

• Double-clicking a maximized pane tab does something again. Double-clicking the tab area to maximize the panes worked, but double-clicking once they were already maximized did nothing. Double-click is a toggle again: the first double-click maximizes the panes and remembers the previous split, and a second restores that split (or a two-thirds split when no previous size is known).

• A network folder link stored on a record stopped opening. After the launch hardening in 11.3.4523, clicking a field that holds the path to a folder on a network share or a mapped drive no longer opened it in Windows Explorer - the open was blocked or raised an unexpected security prompt - while links to individual files on the same share kept working. Folder links open again: opening a folder is treated as navigation rather than as launching a file, so the file-security check no longer applies to it. A folder that is currently unreachable behaves as it did before, with Windows reporting that it cannot be reached. Links to programs and documents are unchanged and still pass through the same security check.

• A progress dialog could stay open after a background operation had finished. When a background operation that runs VBA finished while the VBA host was still showing a modal dialog or completing an asynchronous call, the progress window could remain open - and the application could spin at high CPU - instead of closing, even though the work itself had completed. Completion is now retried on a short timer that lets the VBA host settle first, so the progress window closes once the host is ready.

• Dragging inside a field could move a pane divider, or the divider could jump to an edge. A click-drag that began inside a field and was released or moved over a pane divider (splitter) could resize the panes as if the divider itself had been grabbed, and in some cases the divider could jump to an extreme position. A divider now responds only to a drag that started on the divider, and ignores a stray drag that merely passes over it.

• Opening a record through a filter that matches several records no longer fails. A customisation or report that opens a single record by a filter - rather than by its id - could stop with an “ambiguous results” error when the filter happened to match more than one record, even where having several is perfectly normal (for example a rental object with more than one floorplan picture). Such a filter open now returns the first matching record, the behaviour these customisations expect. Loading a record by its id is unchanged: two records sharing one id still points at a genuine data problem and is still reported.