The Planner component has been redesigned. It now also offers an optional filter for resources (Doctors in the example below).
In earlier versions, in Compact mode top links would be shown below the menu item name, and in Standard mode top links would be shown to the right of the menu item name. Now they are always shown under the menu item name.
When logging in with a small screen device, the first thing that users would see was the menu, and users had to click the X button in the top right corner to see their start page. The logic has been reversed, so that now users will by default see their start page and must click the menu button to see the menu.
This change was originally implemented in 7.30 but had to be moved to 7.31 due to compatibility problems with iOS in the initial implementation.
The admin links have been put into a toolbar that can be closed. It will default to open for normal menu items and to closed for menu items in a multipart. The "bug" button has also been moved into the admin links.
The BankID component now always uses QR codes since it is a requirement for Secure start. The only exception is the new component mode Phone identify which supports BankID in telephone calls.
Sign mode could always show text messages, but you can now also show a text message in the Identify mode, which can be used to describe the intent of the identification in the user's BankID app.
The developer context menu for links, which you open with control-right-click, has received a new command Open SQL editor with arguments. It will use Softadmin® Assistant to send an approximation of the SQL that would be executed by the target menu item to your SQL Server Management Studio.
You can now use JavaScript to control whether an input field is mandatory.
The Redirect component has received a new mode, Standard, that forwards using the columns that you're already familiar with, like ADMIN_ForwardMenuItem. The old Redirect behavior is supported by the Legacy component mode.
Since the new redirect mode is directly compatible with the Execute component's SQL, you can easily migrate any Execute-menu item that does not change the database to the redirect component, to more clearly communicate the menu item's intended purpose.
-- Legacy mode
SELECT
123 as MenuItemId,
CONCAT(
'CompanyId=',
@CompanyId,
'&BranchId=',
@BranchId
) AS Passingfields;
-- Standard mode
SELECT
'Contact.CompanyBranch_Details' AS ADMIN_ForwardMenuItem,
@CompanyId AS CompanyId,
@BranchId AS BranchId;
We have introduced a set of named colors that you can use instead of color codes in the various xxxColor-columns that components support. These colors have been chosen to be visually appealing, and to fit in with the default color theme.
SELECT
'red' as Row_Color,
LogMessage,
'sa-circle' as LogMessage_Icon,
'darkred' as LogMessage_IconColor
You can also use the function SoftadminApi.Color_FromName to translate color names to color codes.
All normal colors have a name that includes information about their brightness, for example red600
, but some colors also have a friendly alias. You can use the brightness-names when you need greater control, but the aliases are chosen to ensure legibility. For example, the color with the alias green
will be legible on a white background, and black text will be legible if you use the color lightgreen
as background.
If you previously used HTML color names, then Softadmin®'s new named colors will take over if they have the same alias as the name of an HTML color. For example, if you have a grid that uses 'red' as Row_Color
for errors then it currently uses the HTML color red
which maps to color code #ff0000
, which really is a bit too bright to use on a white background. After upgrading you will get the Softadmin color red
which maps to color code #e0163e
instead.
You can now give an alias to menu groups and use the ADMIN_ForwardMenuGroup column to forward to them.
When you raise an event you give it an argument, and that argument is then passed to the event listeners for that event. When a menu item is run as an asynchronous menu item listener, that argument is passed to the menu item's procedure in the @Argument parameter (or the #Arguments temp table for a batch listener).
The problem was that, for components that make multiple SQL calls, the event argument was passed to some of the calls but not necessarily all of them. Occasionally you would encounter a call where the argument would have been useful but was not available, and in general it made component behavior hard to predict.
From now on event arguments will be passed to all SQL calls that the menu item makes. This is a breaking change for procedures that assume that they can differentiate calls by the presence or absence of event arguments instead of looking at things like the @Action parameter.
None of this applies to Custom Component menu items, which receive event arguments in their EventArguments property instead of to their procedure.