Release notes 7.11
Contents
Below you'll find a brief overview of new functionality implemented in Axiell Designer 7.11, 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
New optional record history reporting functionality
XML documentation additions and updates
Displaying thumbnails in table grids
New ISINHERITED ADAPL function to identify if a field value is inherited or stored in the record
2023-07-24: release notes Axiell Designer 7.11
The following bug fixes for Designer 7.11 and new functionality for Axiell Collections version 1.17 have been implemented:
Bug report no. |
Short problem description |
AX-485 |
It was impossible to import applications into the model application, using Convert Translations > Import. |
AX-482 |
Export of texts to the translations database stopped unexpectedly without reporting errors. |
AX-481 |
Export of texts to the translations database did not take into account the dataset. |
AX-440 |
The Object Searcher did not find a Meta data source or destination field in a linked field's Meta data properties. |
AX-439 |
The Object Searcher did not find a Meta data field reference in a linked field's Meta data properties. |
New optional record history reporting functionality
As an optional paid-for option, a new Record history reports function is available for Collections 1.17 and up. It will offer a new dialog/result window allowing the user to search any selection of data sources and by modification date range, for changes in records, displaying the old and new value per field. The user can filter and sort the resulting set of changes on data source, record number, field tag, edit date, time, user name, occurrence, data language and new or old value. Then the user can export the resulting overview to a CSV file which can of course be opened in Microsoft Excel for futher processing and checking. Once set up, users with the $ADMIN role will see a new Record history reports option underneath the Maintenance menu in Collections. Please see the Collections 1.17 release notes for more information about the user-interface side of this functionality.
Set up requires two or three steps:
| • | Saved changes in fields (when an empty field has been filled, an filled-in field has gotten a different value or when a filled-in field has been emptied) will only be logged in the database from the moment the Journal field changes option for a database definition has been set to Record history (Collections). Only data sources which are associated with a database definition for which the Journal field changes option has been set, will be listed in the Record history reports window. So make sure this option has been set for all databases for which you'd like to log field modifications. |
| • | An import of data, especially a large one, creates a huge amount of logging data. Retrieving such great amounts of log entries takes a heavy toll on the server and might even take too long and time out. To prevent this from happening the user can limit the number of retrieved entries but you can also improve the performance of fetching the history substantially by having Designer create extra indexes for the journal tables. Do this by right-clicking the \data folder in the Designer Application browser and then select Create missing tables in the pop-up menu. This will add two index tables per journal table in the SQL Server database, called IX_journal_priref and IX_journal_modification. Recommended for really large journal tables. Use Designer build 7.11.0.6055 or higher to be sure these indexes are always created: release build 7.11.0.6047 doesn't always create these extra indexes for all .infs. |
| • | A change in the Collection settings.xml file is required as well to enable this functionality. |
An IIS application pool recycle is required after making these settings.
Media Viewer support for third-party IIIF image servers added to allow for extra image processing functionality
Since some image file formats cannot natively be displayed in browsers, like TIFF images for example, and Axiell's proprietary IIIF (pronounced as triple I F) image server has its limitations, support for third-party IIIF images servers with possibly more functionality has now been added to Collections. One such (open-source) third-party image server, Cantaloupe, for example, is capable of on-demand creation and conversion of derivatives of different image formats to IIIF-compliant image formats that can be displayed in the Axiell Collections Media Viewer.
In the Collections settings.xml, the following extra settings are required:
- whitelist the third-party IIIF image server address in the <Security><Csp> section as <WhitelistImages>http://localhost:8184</WhitelistImages>
- make the proper settings in the <ImageServerConfiguration> section, like:
<Viewer>IIIF</Viewer>
<ImageServerUrl>http://localhost:8184/iiif/2/</ImageServerUrl>
XML documentation additions and updates
Added Conditional Display Fields List (obsolete definition) (CSV) - A list of all fields with an outdated read-only or suppress condition in their screen definition. These outdated definitions should be converted into a current definition to work in Collections (click here - caption ‘The Copy button’ - for more information).
Updated Mandatory Fields List (CSV) to include ‘mandatory in group’ fields.
Added Screen Fields List - Dutch (CSV), Screen Fields List - French (CSV), Screen Fields List - German (CSV) and Field List - Dutch (CSV), Field List - French (CSV), Field List - German (CSV).
Updated Application and Image Field List (CSV), Autonumber Field List (CSV), Enumerative Field List (CSV), Field Access Rights List (CSV), Field List (CSV), Field RecordType Access Rights List (CSV), Linked Field List (CSV), Linked Fields with Relation Texts List (CSV), Multilingual Field List (CSV) and URI Field List (CSV) to include dataset-level defined "include" fields.
Screen Fields List (CSV), Screen Fields List - Dutch (CSV), Screen Fields List - French (CSV) and Screen Fields List - German (CSV) were updated to include HTML fields.
Fields List (CSV).xsl was renamed to Screen Fields List (CSV).xsl
Obsolete Screen Elements List (CSV) was added. This generates 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 application definitions with similar functionality.
RTF Field List (obsolete field type) (CSV) was added. This generates 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 using this obsolete data type.
HTML Screen Fields List (CSV) was added. This generates a list of all HTML fields defined on screens.
Displaying thumbnails in table grids
Collections 1.17 allows you to add a thumbnail column to table grids on record detail screens, making it easier for the user to recognize the linked record by its image.
It does require some work in Axiell Designer: the box around the field group on the relevant screen must have the Edit link group on demand option marked to display the field group in a table grid to begin with. Then a new image field must be created in the local database in the same field group as the relevant linked field: this can be a flat field, but otherwise with the same properties as the image field in the linked database from which it will be merged in, and the field must be included as Destination field in the Linked field mapping of the relevant linked field while the Source field is the original image field in the linked database. And the new field must be placed as a screen field in the screen field group box too. You could implement this for a linked object field in exhibitions or loans for example.
New ISINHERITED ADAPL function to identify if a field value is inherited or stored in the record
Syntax
stat = ISINHERITED (tag, occurrence)
Arguments
stat, occurrence: integer
tag: database variable
Meaning
This function can be used to determine whether the value in a specific occurrence of the specified field tag is inherited from a parent record (and therefore not stored in the currently processed record: stat = 1) or if the field value is normally stored in the current record (stat = 0). For normal, not-inherited fields, the result of this function will always be 0.
This function requires at least Collections 1.16.1.10297, for adapl compilation Axiell Designer 7.10.1.5380 or adapl.exe 7.6.23068.1 and RunAdapl 1.11.1.1884 for running the adapl stand-alone. The function is not supported in Adlib for Windows.
Example (for a storage or after-field adapl)
integer stat
stat = isinherited (TI, 1);
if (stat = 0) {
errorm 'Title is not inherited'
} else {
errorm 'Title is inherited from a parent record'
}
Result
An error message will display either text depending on whether the value in the Title field is inherited or not. The value in this example can only be inherited if the Title field has been set up as an inherited field, if the current record is a child record and in some higher record a title has been filled in, and if the title value nor any of the fields in the same field group in the current record has been edited manually.
Help view contents optionally retrievable from, and maintainable in, a special database instead of .adh files
The contextual help (which appears when you hover the mouse cursor over fields in the Record details view and such) in the Help view in Collections is normally taken from the applic#.adh files in the \texts folder of your Axiell system folder. These are Richt Text Format text files (one per interface language) which are unfortunately a bit cumbersome to maintain and update. Therefore an alternative system has been designed in which all the help texts are stored in an Axiell database, just like your catalogue records, which can be set up from Collections 1.17. A separate Contextual Help 1.0 application accompanies this database to allow you or us to manage these help texts in a easier way via an equally separate Collections installation. This Help application and database are completely separate from your regular Axiell Collections application and SQL database, but if you have installed the Contextual Help application correctly you can refer to its database in the .pbk file of the your regular Collection application, so that your regular application will retrieve its contextual help texts from the contextual help database from now on.
The Contextual Help 1.0 application may become available as a paid-for addition in future model applications. Please contact our Sales department for more information. In bespoke setups it will then either be installed for you if your applications are hosted by Axiell or you'll receive a ready-made application and possibly a SQL backup containing our latest model application help texts for your local installation. The main Help application folder must be pasted in your root Axiell folder, so on the same level as the \adapls, \data and \screens folders of your regular Collections application. Any provided backup must be restored in its own, separate SQL database, so it won't conflict with the database of your regular application. In the contexthelp.inf in the \data folder of the Contextual Help 1.0 application you must then set the server and data source properties to point to the newly restored help texts database. You must also assign Write or Full access rights to one or more user roles which must be allowed to add, edit and/or delete help text records. Then you must create a new Collections application in IIS for the Contextual Help 1.0 application so that users can open the new application in Collections and edit help text records.
Then, on the Advanced tab in the properties of the .pbk of your regular application you must simply replace the existing Help texts reference by a reference to the new .inf, so replace e.g. ../texts/applic.adh by ../Contextual Help application 1.0/data/contexthelp.inf, save the .pbk and recycle the application pool*.
(Alternatively, if you've named the .inf differently or if field tags in that database are different from the default (hard-coded) tags, you can leave the option empty and add a schemas.json file to the application root folder in which you specify the deviating .inf name and/or field tags. See General topics: renaming hard-coded database names for more information about that. The presence of a schemas.json file will override the Helpt texts property if you fill in something anyway.)
Now everything is set up to start working with the new application. It can be started separately and you can work in it like you can in a regular Collections application. Any changes to help text records will immediately become visible in your regular application which now retrieves the contextual help texts from this database.
The Contextual Help application offers a lot of advanced functionality in the form of special tasks to import, edit, add, merge and synchronize help text records. A separate manual ("Managing help texts using the Contextual Help 1.0 application.docx") is available to learn how to use this application optimally.
If you find performance of Collections slow after setting up this functionality, try setting the compatibitlity level of both involved SQL databases as high as possible (to the current SQL Server version preferably) to get good performance. You can do this safely as long as you don't have any SQL backups from older versions of SQL Server that you ever need to be able to restore.
* Note that the option to set a a path to an .inf in the Help texts property of the .pbk is not specific to Designer 7.11 because the property already existed: you can use older versions of Designer too, but only Collections 1.17 and higher will be able to deal with the path to the contexthelp.inf.
IndexTool.exe was already capable of creating indexes for Full Text-enabled database but can now create normal indexes too (for databases that haven't been Full Text-enabled) and create your indexes substantially faster than Designer can. However, indexed links and indexes for metadata tables are not supported by the tool yet.