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, and after you sign out until you sign in again.

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.

See the documents that did not reach Lime CRM, and decide what happens to them. When a document is checked in after you close the editor, and the server does not accept it, the changes stay on this computer only. Until now nothing told you. The client now keeps a record of every document that could not be sent. A notification appears when it happens, and again shortly after you sign in if any such documents remain. The new “Unsent documents…” entry on the Tools menu lists them with the reason and the time of the last attempt. From that list you can open the document or its folder, save a copy, copy the path or the details, send it again, replace the version in Lime CRM, or discard the local changes. Discard always asks first. When you exit the client with such documents on this computer, the exit prompt says how many there are.

A document that opens read-only now says why. A document that is too large to be saved back is opened read-only, and this happened without any message, so it looked like a permission problem. The client now says that the document is opened read-only because of its size, and that changes cannot be saved back to Lime CRM. The document information page and the document tooltip also say that a locked copy may contain changes that are not in Lime CRM yet. The lock details on the information page are now shown to every user. The button that releases a lock is shown only to a user who is allowed to use it.

Temporary server problems are handled better. When the server or a gateway in front of it is briefly unavailable, the client retries. Clients no longer all retry at the same moment, which helps a server that is recovering from an outage. A “Retry-After” answer from the server is followed for at most two minutes, and it no longer allows unlimited retries. Server errors that the client did not recognise are now retried when they are temporary. The gateway errors 502 and 503 now show a translated message that says the server could not be reached. The gateway error 504 has its own message: the request reached the server but the answer did not arrive in time, so the operation may have completed and you should check the result before you try again.

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.

An action pad no longer shows an error when its inspector has already closed. An action pad runs its commands against the inspector that contains it. When that inspector was closed while the action pad was still loading - which can happen when a customization opens a record in a window and then closes it immediately - the pad could run a command with no inspector to act on, and show an error on a card that was no longer visible. Because the error appeared in a dialog, it could also interfere with other work in the same window. The pad now identifies its own inspector reliably, including one that has not finished opening. When that inspector is already gone, the pad does not run the command, so it cannot act on the wrong record and no error is shown. Action pads that are not tied to a single inspector are unaffected.

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.

Duplicating a record keeps the changes you have not saved. The copy made by Duplicate is built from the card as it stands on screen. Until now the client read the record again from the database at that moment, so anything written since the last save was left out of the copy without notice. If you would rather duplicate the last saved version, save the card first and then duplicate it.

A mail created from a template includes what you have just typed. When you write in a field on a card and then click an email address on the same card to choose a template, the mail is built from the card as it stands on screen. Until now the client read the record again from the database at that moment, so the mail carried the values from the last save and everything typed since was left out, with nothing shown to say so. Saving the card first is no longer necessary. This applies both to the templates offered from a field on a card and to sending without a template.

Views and filters named with a leading bracket are listed last again. In the drop-downs that pick a view or a filter, a name beginning with one of ( [ { < is a common way to park an entry at the end of the list. Since the client took over deciding the order, such a name was listed first instead. These names sort after all other entries again, and keep their order among themselves. A name beginning with any other character, an asterisk for example, is unaffected and keeps its place.

The mouse pointer no longer disappears while you work in the client. The pointer could vanish and stay gone for as long as it was over one of the client's own windows, coming back only once it was moved onto another program. It happened most often just after signing in, when the login dialog is closed from the keyboard after typing the password. The client now notices a pointer that stays hidden while it is being moved over its own windows and brings it back. A pointer hidden for the ordinary reason, which is Windows hiding it while you type, is left alone and still reappears by itself as soon as you move the mouse. The check runs only after a built-in browser window has closed, and only while you move the mouse, so the client does no extra background work for it during the rest of the session.

The client no longer sends server-calculated file values back to the server. Some of the values shown for a document - who opened it last, when it was last opened, and its cost and usage figures - are calculated by the server for display rather than stored with the file. The client showed them correctly but also sent them back unchanged when saving the document's details, where the server has nowhere to put them. They are now left out of what is sent. The values are unaffected and are still shown as before.

Locking and unlocking a document no longer renames it. Locking a document and then unlocking it, without opening or changing it, could rename the stored file to a number and remove its file extension. After that, nobody could open the document. The same thing could happen at sign-in, when the client checks in documents left on this computer from an earlier session. The client now sends the document content only when the document was really changed. Unlocking an unchanged document only releases the lock. The client also never sends a file name that it has not read from Lime CRM, and a missing extension from the server no longer replaces a known one. A file that was already renamed is not repaired automatically. The next time it is changed and saved, it is saved with its known name and extension again.

Saving a record no longer releases the lock on a document you are editing. When you saved a record while one of its documents was open for editing, the server released the lock on that document, and a colleague could lock it before the client took the lock again. The client now takes the lock again immediately after the document is saved.

A document with changes that are not in Lime CRM is no longer replaced without warning. Replacing a document that you have open for editing is refused again, both on the card and in the document and image controls. This protection had not been working. Customisations are affected too: setting a document field to a different document while the current one is checked out now fails with a message that the document must be checked in first, when the local copy holds changes that are not in Lime CRM. Before, those changes were discarded without notice. A local copy without such changes is replaced as before. A customisation that needs to discard the changes can check the document in with the option to abandon changes first.

Documents left on this computer are kept safe at sign-in. At sign-in, the client tries again to check in documents left from an earlier session. A document that still could not be sent is moved to the “_failed” folder in your documents folder, so the content is kept. This move could fail when the same document had failed before, and the result was not checked. A document that is still open in another program is now left where it is. A document that the server refused permanently is not sent again at every sign-in.

An upload that the server did not confirm is no longer treated as saved. If the server answered an upload without describing the stored file, the client considered the document saved and deleted the local copy. The local copy is now kept, and the document is reported as not saved.

The maximum file size setting could stop every document from being saved. A maximum file size published in an unexpected form was read as zero bytes, which refused every check-in. The value is now read correctly. A document larger than the configured size is still sent, and the server decides whether to accept it. With two databases open, each database now uses its own limit.

Empty document folders no longer build up on this computer. Each document you open for editing gets its own folder in your documents folder, and every use of a template creates a new one. The folder was kept after check-in, and a folder that still held a file left by Office was never removed. Such folders built up over months and made signing in and out slower. The client now removes the folder when the document is checked in, and removes old folders that hold only files left by Office.

Switching tabs and opening cards no longer gets slower over time. The client keeps a file in its working folder with the formulas used in filters, for the formula favorites menu. It added an entry for every filter the client created internally, not only for saved filters, so the file grew by thousands of entries every working day. The client rewrote the whole file at regular intervals while you worked, and this could pause the client for more than a second during an ordinary tab switch. The file now holds only saved filters, and the client writes it only in the background and at sign-out. It is now kept in a new Caches folder, and the old file is removed at the next sign-in.

The database dialog no longer freezes while it connects. In the login and change-database dialogs, leaving the server field started a connection at once, often with a port that was about to change, and the dialog stopped responding for about 25 seconds. The client now waits until you have finished the server, port and protocol fields, connects in the background so the dialog stays responsive, and does not try the same unreachable address again each time you move between fields. The refresh button and Enter in the server field still connect at once.

Sorting a list by an option field no longer fails with a database error. When the options of a field had been reordered in LISA, a list sorted by that field could fail to load with the error “ORDER BY items must appear in the select list if SELECT DISTINCT is specified”. The list now loads.

Tabs can be dragged and closed reliably. Dragging a tab could change the order of tabs that were scrolled out of view, and a dragged tab could disappear while it was moved. “Restore tab order” now also stays in effect after a restart. Closing a tab could make the client stop working: when it was closed with the middle mouse button during a drag, when it was the only tab, or when there was no other tab to activate. These cases are fixed.

A card no longer jumps to the bottom when fields appear. A change that shows more fields on a card, for example choosing a main category on a helpdesk card, moved the view to the bottom of the card. The view now stays at the top.

Values from VBA in Lime Bootstrap apps no longer arrive empty. A binding in a Lime Bootstrap (LBS) app that called VBA while the page was loading could receive an empty value, and the value that arrived later was not shown. An empty result from VBA is also no longer kept for the rest of the page's life.

Messages from the standard add-ins follow the client's settings. The Office, report and other standard add-ins showed their own message boxes. These boxes did not respect the setting that turns messages off, so an unattended run could stop on a message that nobody could close. They now go through the client, which also places them over the active window.