Release notes 7.13

Below you'll find a brief overview of new functionality implemented in Axiell Designer 7.13, including links to more information.

Backwards compatibility

Using new (Collections-only) Designer settings in your application and database definitions will always break compatibility with older versions of Designer and Collections and other Axiell software* using the same BaseAPI, although removing those new settings will often restore that compatibility under the condition that the SQL table structures haven't changed because of those settings: if the SQL table structures have changed too, then a SQL database backup from before that change is required as well to go back to the previous state. The Designer release notes always note the compatible version of Designer and Collections, but this applies to below list of other Axiell software too. For a full list of compatibility issues through the different versions of Designer and Collections, see the Axiell Designer compatibility topic. The Axiell software which needs to be updated to the latest version once new Designer settings have been applied (only if you have a license for that software of course) is the following: Collections, AdMove server, Workflow client, Ingest, WebAPI, SDK, AnalyzeData, Migration, ConvertInternalLinks, IndexCheck, InternalLinkCheck, LinkRefCheck, RemoveLanguageFromData, RemoveTagsFromData, DBtool and ValidateDatabase.

Designer versions which shouldn't be used

Designer versions older than 7.7.1.316 (at least down to some versions of 7.6) and specific version 7.8.0.3855 should not be used: changing the database server name in a specific .inf would empy all translations from all enumerative field definitions in that .inf. This would not affect your existing data, but enumerative fields (drop-down lists) in Collections would no longer show user-friendly values. In Designer 7.8.0.3859 this bug was fixed again.
Version 7.6.19234.1 (as recommended for Adlib for Windows users) doesn't have the bug, so it can be used safely by Adlib users.
If enumerative field definitions still have their neutral values while they have lost their translations due to this bug, all these translations should be copied back to the relevant field definitions manually, using a backup of your application or an appropriate model application if you do not have a backup of your own application. Please contact our helpdesk for further assistance.

New options and functions for Axiell Collections make further use of Adlib for Windows impossible

New settings in Axiell Designer pertain only to applications run within an Axiell Collections environment. If such new settings are applied, then the resulting application can no longer (reliably) be opened in Adlib for Windows. Since development of Adlib for Windows has ceased quite a long time ago, these new options are not supported by Adlib for Windows. Even if Adlib would ignore the relevant option, you could no longer reliably work in Adlib too, so altered applications using Collections-only functionality should never be opened in Adlib again.

Import.exe and Designer import job editor/manager deprecated for running import jobs: use importtool.exe instead

Import.exe and thus the Designer import job editor/manager (because Designer effectively calls import.exe when an import job is being run) need to be able to read the .inf of the target database for the import. This is only possible if this software recognizes all options and object properties that might have been set in the relevant .inf. If an option or property isn't recognized, running the import job returns an error 172 (system file processed with newer version of software than version with which it was called). With the late 2022 introduction of importtool.exe (using newer technology) as an alternative for import.exe and the Designer import function, development on the latter import functionality has ceased. This has the consequence that when you use import.exe or the Designer import job editor/manager to run an import job for an .inf that has new options (say those that were introduced from Designer 7.6 and up), there's a chance you'll get an error 172 because import.exe has no support for the new property. In that case you'll need to start using importtool.exe to run your import jobs from now on. However, as long as you don't get the error, you can keep running your import jobs as you always did and you can even use the latest version of Designer (recommended) for any changes to your application. Just keep in mind that you may activate a new option or property sooner or later, after which import.exe or an import with Designer will throw the mentioned error and you'll still have to move to importtool.exe.
Import jobs still have to be created in Designer (preferably use the latest version), so that doesn't change. Note that XML files cannot be imported yet and CSV files must have a first line containing the English field names pertaining to their columns, just like a CSV for Collections import requires (and the field mapping in the import job is ignored).

Contents

A case-insensitive uniqueness check for index names

XML documentation additions and updates

Extracting metadata from image files

Setting up direct printing from within Collections

Auto-populating a reversely associated field in an internally linked record with an entry-dependant default value

Making administrator functionality available to other users

2024-01-11: release notes Axiell Designer 7.13

The following bug fixes for Designer 7.13 have been implemented:

Bug report no.

Short problem description

AX-515

There was no recent build of the separate Record lock manager tool.

AX-513

There was a time-out on re-indexing an enumerative field in a Full text indexed database.

AX-505

Re-indexing a field after setting it to Indexed link created empty field nodes in all processed records for all grouped fields.

AX-503

Clicking almost any linked field in a task definition gave an Error reading linked database info. Could not find .inf file.

AX-495

The properties window for all types of screen objects was still called Adlib object properties.
It's been renamed to Screen object properties.

AX-489

After setting the Indexed link property for internal links in Locations and clearing all databases, saving a new Locations record resulted in an Invalid object name 'location_2A_nt_lrel' error.

AX-486

When re-indexing a field after setting it to Indexed link, Designer did not remove the link data from most remote database's records, only from the local database records.

AX-483

When re-indexing a field after setting it to Indexed link, Designer did not always remove the local data for the indexed link, and added empty field nodes for all grouped fields.

A case-insensitive uniqueness check for index names

Index names which are only different in casing, e.g. Ab_index and ab_index, are not allowed because SQL usually sees them as one and the same and this can lead to duplicate table names. Designer 7.13 now automatically checks if existing index names are unique this way when a database definition is loaded in the Application browser. Any errors will be reported in the main Designer Window. Also when creating a new index will this check be performed and if the name already exists you must enter a different name.

DuplicateIndexName

The Application tester already reported on duplicate names but didn't mention the relevant .inf. That has now been fixed.

New screen and database documentation formats

For creating screen documentation, the following new formats are now also available:

Legacy Only Boxes List (CSV) - a list of all boxes which contain ‘Adlib Legacy Only’ fields. Such fields are not displayed in Axiell Collections.
Table Grid Boxes List (CSV) - a list of all boxes which display fields in a table grid view, using the Edit link group on demand setting.
Obsolete Screen Elements List (CSV) - The report contains a list of all outdated screen elements with their properties (List Field, Image, MenuOption, System, TextWindow, WebBrowserControl, Button). These screen elements are not supported by Collections. Use this report to identify which screen elements can be removed from the application, or replaced by other elements with similar functionality.
HTML Screen Fields List (CSV) - The report contains a list of all HTML fields defined on screens.

For creating database documentation, the following new formats are now also available:

Numeric field list (CSV) - The report includes all fields of the Numeric data type and focuses on the Numeric field properties. It could be useful when you want customisations in numerical fields regarding the number of decimals and/or zero-padding.
Field list for migrations (CSV) - The report contains a list of all fields that can be used as a basis for an Axiell Migration mapping template. The report includes columns to (manually) assign a destination tag and field name to each field, and a column to indicate the field can be ignored during the migration process.
The Notes column contains relevant field properties for the mapping process, like the linked database, the link type (single-side, reverse, internal), and the connected linked and link reference fields. The report includes mapping suggestions for specific field types:
- Include fields should be assessed manually (especially the definition differences from the general field definition.
- Temporary fields are set to “ignore” by default.
- Context fields are set to “ignore” by default.
- Merge fields are set to “ignore” by default.
- Linked fields are set to “ignore” by default, with the advice to map the link reference field instead.
RTF Field List (obsolete field type) (CSV) - The report contains a list of all fields of the RTF data type. This data type is no longer supported and should be replaced by either HTML or Text. Use this report to find out if the application contains fields with this obsolete data type.
Field List With Index Information (CSV) - The report contains a list of all fields with their main properties, as well as index definition details (when available).

Enumerative field list (CSV) has been updated and now also includes the Enumeration source, the Enumeration sort and Enumeration source field settings.

Extracting metadata from image files

From Collections 1.18, Designer 7.13 and Ingest 1.7.3.1867, it is possible to have the Exif data and/or IPTC data screen tabs (and possibly other fields too) in Multimedia documentation records populated with metadata from the linked image file automatically (other media files currently not supported). In Collections, these read-only screens which are present in current (from version 4.2) model applications never had a purpose, but can be made functional now. An appropriate metadata field mapping (already present in the upcoming model application 5.2) must first be created for the image field (usually tag FN) in the media.inf (no need to specify such a field mapping for image fields in catalogue records linking to media.inf): on the Image properties tab, a Meta data field mapping list box has been added to allow you to do so.
In current applications, all of the fields on the mentioned screens already have field definitions in media.inf so you won't have to create these and you can directly select them as target fields in the Meta data field mapping by using the ... button in the right column.
The source "field" names must usually be formatted like schema:property as far as the property falls under a schema. The schema can be e.g. dc, exif, photoshop or different xmp en iptc varieties. Property lists for the different schemas can be found on the internet, like here for Exif, here for IPTC (see the ExifTool tags rows) or here for XMP (see third column). The exact property name available to Collections may still differ from these specifications though. Windows file properties like Format, File Size, Width in pixels, Height in pixels etc. can be used as source property names too (without schema).

MetadataFieldMapping

The metadata will only be retrieved when you save the media record (or a catalogue record linking to Multimedia documentation) after first linking a new image file. So the metadata is stored in the media record and will be permanent in that way.
Any errors during mapping will be logged in the Collections log file: an error might happen when the extracted data type of some property doesn't match the data type of the target field, for example.

ExifMetadata

Notes

There is currently no way to update all existing media records with the metadata from the associated image files.
Since the metadata is stored in the media records, you could in principle define indexes and access points for selected fields too, so that you can search on those fields quickly.
In principle it's possible too, to define a Meta data field mapping for a linked image field, if you'd like map target fields only present in the primary database for example, but the more logical and easier setup is the one described above where a Meta data field mapping only exists in media.inf. If you'd like to show some metadata properties in a catalogue record too, you can always set those up as merged-in fields for the linked image field.

Setting up direct printing from within Collections

From version 1.18, Axiell Collections allows users to print the result of an output format directly to a selectable printer (instead of the result opening as a document in Word or the browser first).

PrintButton

SelectPrinterDialog

The new Print button and the following Select printer dialog will only be present though if available printers have been set up in the Collections settings.xml file first. This option can only be implemented if you have a local installation of Collections: Collections installations hosted by Axiell cannot access your local (on-site) printers (yet).

In settings.xml, insert a <Devices> section underneath the main <Settings> node with a <Device> node per printer, like so for instance:

 <Devices>
 <Device Id="DefaultPrinter" Type="Printer">
  <Name>
         <Text lang="en">Default printer</Text>
         <Text lang="nl">Standaard printer</Text>
  </Name>
  <Settings>
   <PrinterName>\\ourserver\RICOH 5000</PrinterName>
   <PageLayout>
               <Orientation>Portrait</Orientation>
               <PageSize>A4</PageSize>
               <Size Width="210" Height="297" />
               <Margins Top="1" Bottom="1" Left="1" Right="1" />
               <DefaultFont Name="Times New Roman" Size="12" />
   </PageLayout>
     </Settings>
       </Device>
 <Device Id="Pdf" Type="Pdf">
  <Name>
         <Text lang="en">Print to PDF</Text>
  </Name>
  <Settings>
   <PrinterName>Microsoft Print to PDF</PrinterName>
  </Settings>
 </Device>
 </Devices>

The available settings are the following:

Type

The type of the printer:

Pdf = Print to a PDF file (no PageLayout settings required)
Printer = Print to a printer

Device Id

Your unique ID for the printer. (This can be stored by Collections in Saved search jobs and in other places, so once used this should be retained.)

Name

Localised UI name of the printer for displaying to the user. This is what appears in printer selection dropdowns in the Collections user interface. Specify a name in all interface languages used by your Collections users. If no name hasn't been specifed in the current interface language, then by default the English name will be displayed to the user.

PrinterName

The PrinterName is the name of the Windows printer driver. If the printer is a network printer (on a different server), you may need to specify the network share path to the printer, like \\other-server\RICOH 5000. If all printers on a server have the comment “(redirected)” behind them, it means they are redirected from your local pc during your active Remote Desktop Connection, although the printer name with the path in front of it also seems to work when no RDP connection is present.
If you leave the PrinterName empty, it should choose the default printer driver.

PageLayout

The entire PageLayout section is optional, but if you include it, PageSize will default to A4 if not specified and DefaultFont is optional too. If PageSize is specified, Size can be omitted. Instead of a standard Pagesize you can also specify Custom as PageSize and then specify Size, Margins and DefaultFont.

Orientation

Portrait or Landscape.

PageSize

Supported standard PageSizes are: Custom, A0, A1, A2, A3, A4, A5, RA0, RA1, RA2, RA3, RA4, RA5, B0, B1, B2, B3, B4, B5, Quarto, Foolscap, Executive, GovernmentLetter, Letter, Legal, Ledger, Tabloid, Post, Crown, LargePost, Demy, Medium, Royal, Elephant, DoubleDemy, QuadDemy, STMT, Folio, Statement.
The available printer page sizes don’t come from the document that you are trying to print, but from the printer driver itself. Under the hood, the report will be rendered to PDF according to the page size that the printer supports. If you have different paper trays then each will need to be configured as a separate printer.

Size

When PageSize is Custom, specify the page dimensions in mm. Ignored otherwise.

Margins

Page margins in mm.

DefaultFont

Default font to use when the report doesn’t specify a font. Used as defaults for text or HTML.

Auto-populating a reversely associated field in an internally linked record with an entry-dependant default value

When creating a new record with some internal link, e.g. a Thesaurus record with a narrower, related or non-preferred term where you'd like to fill in some standardardized comment in a notes field to further clarify the relation between the two terms (something like "based on" or "is variant of" or "copied from" etc.) then you'd maybe wish that the opposite (or some other matching) comment would automatically be added to the internally linked record (like "result of" maybe or "has variant" or "copied to".
A new properties tab called Internal link association properties for internal link definitions now allows you to specify such default comment pairs for one or two fields in the current database definition. (The internal link type determines whether you can select one or two fields.)

autopopulatefields

In the Association field property you enter the field name in which a value from the Association column in the list on this properties tab must be entered, while in the Reverse association field (if not greyed out) a value from the Reverse association field must be entered. If the Reverse association field property cannot be filled in, then it is implied that the Association field will also be used as the Reverse association field.

You can specify as many value pairs as you like. Both values can be the same too.

Some example use cases for related works that you could use:

based on <> result of
has part <> is part of
sequel of <> presequel of
released with <> released with
is variant of <> has variant

For related name for example:

changed from <> changed to
has alias <> is alias for
has member <> is member of
hived off from <> has hived off
merged with <> merged with

Or for copy history:

copied from <> copied to

However, you are free in choosing the values and fields for your particular internal link.

Then when the user creates a new record in the current database table and adds an internal link of the current type and enters one of the values from the Association/Reverse assocation list in the associated field then on saving of the record the matching value from the other column will be entered in its associated field in the other record (as long as that field was still empty).
Also when a record with an internal link already exists but the association fields in the current record and in the internally linked record are still empty before you enter a value from the list in the current record, will the matching value automatically be entered in the other record too.

Making administrator functionality available to other users

Certain functionality is normally only available to user with the $ADMIN role. To allow other (non-administrator) users to get access to some of these specific functions too, Axiell Designer now allows you to add these functions as so-called application features to a .pbk and specify access rights for roles like you would for methods for example.

1. Simply right-click your application structure file (.pbk) in the Application browser and select New > Add application feature in the pop-up menu.
 
applicationfeatures01
2. A new Application features list header and underneath it a new application feature node will be added underneath the Users node in the .pbk. You can add multiple of these nodes, also by right-clicking the Application features list header and selecting New > Add application feature in the pop-up menu
 
applicationfeatures02
 
 
3. Select the desired application feature node and edit it in the properties tab in the right window pane. Select one of the four currently available application features which you'd like to make available to certain non-admin roles too. Create a new application feature node for each feature type you'd like to do this for.
 
applicationfeatures03
 
applicationfeatures04
4. Then list one or more roles in the Access rights list and assign the desired access rights. (Do not include $ADMIN.) When accessible (only roles with Full access and $ADMIN users), Record history reporting and View/recover deleted records (aka Journal maintenance) are available through the Maintenance menu in the main vertical menu on the left of the screen, while View active sessions is available under the Account menu in the same toolbar. For the Axiell Move option to become available (roles need Read access at the least) in the main menu, this functionality also must have been set up for the application.

Note that users with sufficient access rights to an application feature can still be prevented access to that feature if their roles have not been assigned explicit access rights to a possible other application object related to the feature. This currently only applies to the Move functionality: if the Missions and Mission items data sources have (only) been assigned None access rights for $REST, for example, then users with any other role with sufficient access rights (Read in this case) to the Move application feauture still won't see the Move option in the main menu.