Release notes 7.6
Contents
Below you'll find a brief overview of new functionality implemented in Axiell Designer 7.6, including links to more information. For some notes on compatibility issues see the Axiell Designer compatibility topic.
New Designer settings may pertain only to adlwin.exe-based Adlib applications, only to applications run within an Axiell Collections environment or to both, as will be noted explicitly in the documentation for each setting. New settings which do not pertain to Adlib for Windows, should have no negative effect on the operation of this software as long as you use Adlib for Windows version 7.6.
Contents
Field-level auditing: journalling field changes
Setting up an inline report for Axiell Collections' report viewer
Setting a default invariant data language
Storing reverse relation metadata in a separate database table
Making fields once-writeable in Axiell Collections
Setup of password reset functionality
New field data type: URI
A new data type, URI, has been implemented. This URI data type is covering the following:
| • | The content of a URI type field will be validated according to the .NET URI object rules as described in https://docs.microsoft.com/en-us/dotnet/api/system.uri.-ctor?view=netframework-4.8#System_Uri__ctor_System_String. URI’s usually have the form of a URL so if the URL is valid, it’s also a valid URI. |
| • | The URI data type has the option to link to another URI type field. One will be defined as the external URI and one will be the internal URI. This is especially useful if PID/URI’s are managed through an external broker like Handle/SurfSARA. The external URI will link to the external broker that will refer to the internal URI/URL. The idea behind this is to really keep the PID/URI persistent as it does not include an internal domain name of the organisation. So if the internal URL changes because of, for instance a change in the name of the organisation, the new internal URL can be linked to the external PID/URI. The internal URL could e.g. link to the Axiell WebAPI to present the record in a technical format or even in an HTML presentation. |
| • | The URI data type also allows for the definition of an initial value format which will be entered in the field automatically upon the creation of a record. |
A field definition of the URI data type gets a URI field properties tab where you can enter the relevant properties. See below screenshot for an example:
This implementation of URI fields is associated with the concept of Linked Open Data. Click here for more information about the implementation of Linked Open Data in Collections application 5.0.
Field-level auditing: journalling field changes
Axiell Collections now allows any change made to a record to be stored, journalled if you will, to be audited at any time on field level in the Record details view of Collections. For this to work, it has to be switched on per desired database definition first. To this end, the pre-existing Journal field changes checkbox on the Advanced properties tab of a database definition has been changed to a drop-down list, where it contains the following three options:
| • | Disabled - no journalling takes place in Adlib for Windows nor Axiell Collections. |
| • | Legacy (Adlib for Windows) - journalling is switched on for Adlib for Windows only (it doesn't break Collections, but you can't access the journal in there either). |
| • | Record history (Collections) - journalling is switched on for both Axiell Collections and Adlib for Windows (7.6, from 21-3-2019). If you were using the Legacy option already for Adlib for Windows, we recommend only switching it to Record history (Collections) if you have access to the Axiell DBTool.exe (formerly known as JournalMigrate.exe) tool to convert your Adlib journal to the Collections Record history journal, since Record history uses a different journalling technique than the Legacy option and you may want to hold on to the journal data accumulated by Adlib for Windows. Ideally, converting the old journal format to the new format must be done right after changing the current setting from Legacy to Record history (Collections), but conversion at a later stage is possible too. If you haven't converted any existing Adlib journal after switching to the Record history option, Adlib will generate an error every time you try to edit a record with associated journal data in the old format, to prevent the two types of journals from diverging. Even though with the Record history option editing records in Adlib will be journalled just like editing records in Collections, Adlib for Windows won't get a user interface bit to view the journalled data in the new format: for that you need Axiell Collections. |
Make the change per desired database definition: you may change them all or just a few.
The change to Record history (Collections) will automatically add a dbo.journal.<database name> table to the SQL Server database, in which the change log for the relevant database will be kept, once the table is accessed in Collections.
Setting up an inline report for Axiell Collections' report viewer
In between the Output jobs per data source, you may now also set up inline reports which become available in the Report viewer (and in the Output formats dialog) of Axiell Collections. (The Report viewer offers an alternative display of the currently selected record and any additional data.) Inline reports are just like output formats, with the difference that only XSLT stylesheets and the Calm XML format are supported.
You set up an XSLT inline report just like an XSLT output format, the only difference is that you set the Template type option to Inline.
For a Calm XML inline report the Template type must also be set to Inline, but the path to the XML template must be entered in the Template path option. (If the template name ends with .xml, it is assumed to be a Calm XML format.)
Setting a default invariant data language
For multilingual databases you can now set a default invariant* data language. The Default invariant language can be found on the Advanced tab of the properties of a database definition (.inf). If you set it, set it to one of the data languages already available in your application (as set on the Advanced tab of your application structure (.pbk)). Once you select a language, you'll have to confirm that the setting will be copied to all other database definitions in this \data folder.
Once set, editing data via the Multilingual data dialog in a mulitlingual field will behave as follows when it comes to the invariancy aspect of a translation:
| • | If one of the translations in a multilingual field has already been made invariant manually, nothing will be done with the default invariant language: the data will remain as is. |
| • | If no value has been entered in the data language that you've set as the invariant data language, nothing will be done with default invariant language, regardless of whether any of the other translations have been set to be the invariant or not: the data will remain as is. |
| • | Currently (September 2018), if none of the translations in a new or edited record have been made invariant already, while the user is currently adding a translation in the default invariant language, then on saving the record, invariancy will be applied to that translation. During editing of said translation the invariancy radio button behind the edited value will remain empty though, even though the user doesn't have to mark it manually, so there's no visual clue that this value becomes the invariant value upon saving of the record. This behaviour might still change in the future. |
| • | Currently (September 2018), if none of the translations in a new or edited record have been made invariant already, while a translation in the default invariant language is already present, then on opening of the Multilingual data dialog (either in display or edit mode), then the invariancy radio button for the default invariant language will appear marked anyway, but this invariancy will only be really applied when the record is edited and saved. There is no visual clue that the marked radio button doesn't represent the saved state of that translation. This behaviour might still change in the future. |
* Invariancy is meant to make translating easier: an invariant value is not only displayed in the field if the data language is set to the language of that value, but also in other data languages for which no translation exists yet (in which case in display mode the data is presented in a light grey font while in edit mode the field has a light blue background to indicate that an invariant value is being displayed). An invariant value in a light blue field is hidden as soon as you type something into the field.
Storing reverse relation (or internal relation) metadata in a separate database table
A reverse relation implies that many-to-many links between records from (usually) different database tables are possible. For example: you can link a single object record to multiple exhibition records (because the object appears or has appeared in multiple exhibitions), while an exhibition record can link to multiple object records (because an exhibition can obviously display many objects). In some cases you may also like to store data about the relation itself, metadata that is not specific to either record in the reverse link but to their particular relation. For the reverse relation between an object and an exhibition for example, you may want to be able to register the display period applicable to this relation, especially if that period differs from exhibition period itself. Possibly the object will even be on display during more than one specific period in the exhibition. So then you'd like to be able to link the same exhibition record as many times to the object record and register the period metadata per link. Something similar would apply to a reverse relation between objects and books where you'd like to register page reference metadata somewhere, as long as it's not in the object or the book record.
Internal relations are links between records in the same database table, like a parent record which links to multiple child records. Here too, you would sometimes like to store details about the relation itself as metadata.
That possibility is now available in Axiell Collections but must be set up per desired reverse or internal relation in Axiell Designer 7.6.18093.4 or higher. Amongst your normal database structure files (.inf files) you'll create a special metadata database (which will contain records with the metadata per relation) and an equally special, so-called triple index which will associate the linked record numbers from the reversely linked database tables to the record number of a relevant metadata record. The metadata database table won't get its own data source and screens. You'll have to add fields to the reversely or internally linked database structures and to relevant screens for data sources associated with the linked database tables, so that when a link is displayed (a link from an object to an exhibition for example), the relation metadata can be retrieved automatically and be displayed too. Such merged-in metadata can also be edited, as it must be created from such fields as well. In fact, a new metadata record will be created once a reverse or internal link between two records is registered and this record will remain associated with this link (via the triple index) as long as the link exists - on deletion of a link, the metadata record will currently not be removed - so even when a user changes earlier entered metadata for a reverse or internal link or empties the metadata field(s), the link will still be associated with the originally created metadata record and any changes to the contents of the metadata fields will simply be processed in that metadata record. Once (after editing) a record with prior reverse links (from before you set up the metadata functionality) is saved, new metadata records will automatically be created for all those existing links, even though they do not contain any metadata (yet).
You can also search the contents of metadata fields.
Proceed as follows:
| 1. | First we'll have to create a metadata database definition and its table in the SQL database. (You have to have dbo rights to the SQL database to proceed.) Although strictly speaking you'll only have to do this once, to have that table contain metadata records for any relation between any two normal database tables you care to create now or later, we recommend creating a separate metadata database definition (each with a different name) for each relation for which you'd like to be able to register metadata because metadata records do not contain a reference to the relation it originated from and if something were to go wrong with the contents of the single metadata database it'll be hard to research the cause of the problem. For now, for the single metadata relation we are creating, simply right-click the data folder in your Adlib\Axiell system in the Designer Application browser and select New > Metadata database definition in the pop-up menus. You'll be asked to enter the database name: enter metadata, for example, or metadata1 or a name which includes the linked database names or tags, if you think more metadata relations will require their own metadata table later on.  After clicking OK, the new database definition will become visible at the bottom of the list of database definitions and the relevant table will have been created in your SQL database automatically. (The SQL storage structure of this metadata table is the same as that of normal database tables, only the record access table and pointer files (aka saved searches) support tables currently have no use.) |
| 2. | The database definition should get fields and indexes, but it can't have datasets, internal links or feedback links etc. Identify which reverse or internal link you'd like to enhance with metadata storage. Let's continue with the object-exhibition relation as our example. Also think about which relation metadata you'd like to be able to register. Let's say we need a start and end date to mark a display period. We'll have to create these fields in both reversely linked database definitions, collect and exhibit in this case, and in the metadata database definition. Even though we'll create normal fields in collect and exhibit, data entered by the user will not be stored there, it will only be stored in the relevant fields in the metadata database table. Provide sensible field names:  In collect we create similar, repeatable fields which will serve as target fields in the linked field mapping, merged in from the metadata database table:  In exhibit we also create similar, repeatable fields which will serve as target fields in the linked field mapping, merged in from the metadata database table:  In both normal database definitions then also create a repeatable Integer field, named metadata_collect_exhibit_reference for example. This field will contain the record number of a referenced metadata record. (This field doesn't require an index in these database definitions.) The fields in the normal database definitions should be part of the same field group as the linked field to which the metadata pertains. |
| 3. | Now edit both reversely linked fields of this example in the normal database definitions, in collect and exhibit in this example. First mark the Meta data enabled checkbox for the exhibition field in collect. This will automatically mark the same checkbox in the reversely linked field in the other database definition as well, object.object_number in exhibit in this case. Note that if you were to do a similar setup for internally linked fields, you would have to enter a Backward reference (the forward reference of the other linked field in the relation) for both internally linked fields (something you wouldn't do normally) to enable the Meta data enbabled checkbox to allow you to mark it. The superfluous backward references would then be ignored by the software so that the internal link could still function normally.  It will also add an extra properties tab to these two fields: Meta data properties. For both reversely linked fields you'll have to fill in this tab. For the Meta data database property, select the metadata.link (or other appropriate <my_dbname>.link) file from the browser window. In Meta data reference, select the reference field you created in the previous step. Then fill in the field mapping from the metadata source fields to either the collect or exhibit destination fields that you also created in the previous step.   Saving the changed database definitions will now create a special table in the SQL database, which represents a so-called triple index, a new type of index which links three record numbers to each other: the record numbers of the reversely linked records and the record number of the associated metadata record. (In the SQL database, this table is automatically named after the three involved database definitions and ends with _linkTable, in this case the name would be dbo.collect_metadata_exhibit_linkTable. All you really need to know about it is that it will be updated along with the normal link reference index tables for the reverse link as metadata records are added to the dbo.metadata (or differently named metadata) database table. |
| 4. | Now add the start and end date fields as repeatable, writeable fields to the screens that present the reverse link, in our example the links to exhibit and collect: exhibit.fmt and objlistex.fmt:  |
| 5. | Save your work and recycle the Collections application pool: metadata can now be added to reverse links of this type in existing and new records. |
Note that the marked Metadata enabled option for a field and its Meta data properties will break compatibility for the relevant .inf with Axiell Collections older than 1.0.6673.28957 and Adlib for Windows 7.6.18093.2 (even though Adlib for Windows ignores the metadata setup). Removing the settings will restore compatibility with older versions although the extra SQL tables will remain present in the database.
Adlib for Windows will display metadata destination fields normally on the relevant screens, but they will not show any data from metadata records. Since they are writeable (which will store the field data in the catalogue record itself, where it shouldn't be stored) users should take care not to enter any data in these fields while working in Adlib for Windows even though Axiell Collections will ignore it and display the data from the relevant metadata record instead. Therefore we recommend only setting up the metadata database functionality if your organisation only uses Axiell Collections.
Searching metadata fields
You may create access points in the reversely linked data sources to allow searching on the metadata fields. The principle is the same as for access points on normal merged-in fields. Proceed as follows:
| 6. | Create appropriate indexes for the metadata fields in your metadata database table. In our example that would be two ISO Date indexes. Reindex the new indexes after creating them. |
| 1. | Create relevant access points in the appropriate data sources in the application structure: in object catalogues and/or the Exhibition data source in our example. Let's create two separate access points in the Internal object catalogue. As the Search key, look up the relevant metadata field in the current database structure: |
| 2. | Save your changes and recycle the Collections application pool. When in Collections you now open the Standard search tab in the Internal object catalogue, you'll first have to click the Settings button to select your new access points and display them on the Standard tab. You should now be able to search the contents of your metadata fields. |
The searching part of the metadata database functionality can be implemented in Designer version 7.6.18109.2 and higher, and used in Axiell Collections from version 1.0.18109.2.
Making fields once-writeable in Axiell Collections
For security reasons you might like some fields, like the Input and Edit fields on the Management details tab for example, to be writeable only once, to automatically become non-editable after saving the record. As it happens, the Input and Edit field contents (except for the Notes field contents in those field groups) cannot be edited in the fields themselves (they are read-only on the screen) while they are filled by the storage adapl when the record is saved. Nonetheless, the contents of these fields can be changed via the Search and replace functionality since this functionality has no regard for screen definitions and only looks at the data dictionary. To protect earlier saved field contents from any later changes, whether through record editing, search and replace or adapl functionality, you can now set a Write once option for such fields in the data dictionary. Simply look up the desired fields in the relevant database structure definition and mark the Write once checkbox at the bottom of the Field properties tab. The best practice is probably to set this option only for automatically filled fields which are read-only on the screen anyway, because all saved data in these fields won't be editable in Axiell Collections again.
When a user tries to edit and save a write-once field anyway, a notification message similar to the following will appear and the record can't be saved:
Important notes:
| • | New occurrences of write-once fields or field groups can still be added. |
| • | Deletion of write-once field occurrences that have saved data in them is not possible. When a write-once field is part of a field group (maybe also containing normal fields), then a field group occurrence can only be deleted if the write-once field doesn't have data in it. So, earlier saved empty field group occurrences containing one or more write-once fields can always be removed. If you click the Remove row icon for a field occurrence that can't be deleted, a notification message will inform the user of the reason why. |
| • | The copy record function copies the management details as well, but as you are creating a new record, its storage adapl will try to fill the Input fields on the Management details tab with new data. For that reason, saving a copied record won't be possible if you've set the write-once option for those fields. To prevent those circumstances from arising, make sure you also deselect the Exchangeable option for the Input fields in the data dictionary: that way they won't be copied along and the storage adapl will be able to fill them with new data. (This combination of field settings can be used from Collections version 1.0.6611.15633.) |
| • | The Write once setting is ignored by Adlib for Windows. |
| • | Once you mark the Write once option for a field, the relevant .inf will only be compatible with Axiell Collections 1.0.6599.25993 and higher and Adlib for Windows 7.6 or higher (even though Adlib for Windows ignores the setting). Removing the setting will restore compatibility with older versions. |
Syntax
RunAsRole(role)
Arguments
role: text
Meaning
RunAsRole runs the adapl under a certain role. The function (only supported by Axiell Collections) was introduced especially to allow an application setup where the current location and location history of an object cannot be edited manually or by means of search & replace, while only allowing it to be changed via the Change location task, which is more secure and also better because the Change location task at least always updates the location history.
The setup would then consist of adding some new role to the database, like ChangeLocation for example (but any descriptive role name will do) and subsequently setting Read access rights for role $REST in collect.inf for all current location and location history fields except the merged-in fields and the context field (which would block these fields from being edited in any way, even when filling in a new record) while you must also set Full access rights for your new role to the same fields. Now by adding the RunAsRole statement (RunAsRole(ChangeLocation) for example) to the beginning of the ChangeLocation adapl (which takes care of the Change location task), you make sure the adapl won't be hindered by the read-only rights and will have full access.
Example 1
RunAsRole('ChangeLocation')
Result
For all users, the adapl will be run under the ChangeLocation role and access rights set for this role anywhere in the Adlib application or database structures will apply and determine what the adapl can or can't do. So for example, if the adapl writes a new value to tag 2A, then the ChangeLocation role should have at least Write access rights to that field in the data dictionary.
Setup of password reset functionality
The Axiell Collections login screen may present the user with an option to reset his or her password, which comes in handy if the user forgot what it was. The option will be visible only if the functionality has been set up properly. This consists of two parts:
| • | The authentication service functionality is built into Collections and you can therefore let either Collections itself handle the two-factor authentication and/or password resetting or install a separate instance of a Collections application in IIS to be solely used as an authentication service. You can let your current Collections instance handle the password resetting itself if you have it installed on your local network and Collections is allowed to communicate with Active Directory directly if users are authenticated by their AD account. In an entreprise environment where different Collections applications cannot be allowed direct access to Active Directory, a separate authentication service with its own access to Active Directory is recommended: password reset requests from the normal Collections applications will then be passed on to this authentication service. For two-factor authentication Collections doesn’t need write access to AD (like password resetting does), so for this functionality you are free to choose which Collections instance to use. For Active directory authentication, the application pool Identity must be set to a user who has sufficient access rights to manage AD accounts (to allow resetting of a password). |
| • | Extend the setup of your preferred authentication method in the Adlib application itself, to include password resetting. |
With regards to the Adlib application configuration, see the new settings on the Application authentication properties tab of an Adlib application structure file (.pbk) in the Designer Application browser: E-mail field, Phone number field, (Two factor authentication) Provider, (SMTP settings) Server and Port number. These extra settings are required because the password resetting functionality offers so-called two-factor authentication, meaning that a user can also be identified by his or her e-mail address or phone number and that on actual resetting of a password an e-mail or sms with a unique code will be sent to the user, after which that code must be used to validate the user for the second time. (The language of any texts in the e-mail will be determined by the interface language of the browser in which Collections is running.)
This functionality can only be set up for Authentication methods Adlib database and Active directory and is additional to settings you already made for either of those types of authentication. For the Active directory method, e-mail addresses of users need to have been specified in their AD accounts (per account only one e-mail address can be used, so authentication by AD groups might not be good idea), while for Adlib database you must select the field in the authentication source which contains either the e-mail address or the phone number of the user, in the E-mail field or Phone number field properties respectively: you only need to provide an e-mail field if you set the (Two factor authentication) Provider to E-mail while a Phone number field is only required for the Mobile App and SMS providers (which currently, January 2018, are not functional yet). Leave the Provider to None if you don't want to allow users to reset their own passwords.
For the e-mail method, please also fill in the SMTP settings. You must have an SMTP server to be able to use this method. Enter its name in the Server property and also fill in the Port number (typically 25, but your system administrator will know for sure).
Note that for Adlib database authentication, user names need to be unique.
For further information, please see the Installation and configuration of Axiell Collections manual.