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:

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.

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:

For creating database documentation, the following new formats are now also 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).

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.

Notes

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).

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:

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.)

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.

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.