Release notes 7.7

Below you'll find a brief overview of new functionality implemented in Axiell Designer 7.7.#, 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.

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.

Contents

Additions and changes to XML documentation

New option for default search filter on linked field

New &1[4] reserved variable to identify the process that started a before-storage adapl

WebAPI XML payload functionality supported in ADAPL

Spanish, Hungarian and Catalan added to optional application languages

Conditional suppression of download possibility in application and image fields

Alphanumerical sorting added to REPSORT function

New WHERE option for ADAPL FACS READ to fetch records using an advanced search statement

A FACS READ NEXT USING can now be abbreviated to a READ NEXT

New &W reserved variable contains number of hits from last FACS READ

New ADAPL COUNT function to count field occurrences matching a condition

Setting up record merging per data source

Finding and linking orphaned labels

New optional indexed link table structure for heavily used linked fields

New Media type tag property for image and application fields

A substituting Original filename tag property for image and application fields

New &1 execution codes 30 and 29

Copy record and Record template methods added

Enumerative fields can no longer accidentally be made multilingual anymore

Field inheritance now enforced for entire field group

Allowing non-media file downloads from an image field linked to a DAMS

Making a linked field validable on more than one field

Using adapl-only output formats for PDF and plain text printouts

Image and application fields path properties now available in field list grid view

yesno ADAPL function now supported

Link screen adapl supported in Collections 1.10

Using the Destination dataset field property

Numeric field properties

Disable download of images

Errorm messages in different colours

A formatting option for integer fields

Having adapl-created documents uploaded to a repository via Collections

Prompted output formats for Axiell Collections

New ADAPL function: GUID

Importing data into a database with None default access rights

2022-04-07: release notes Axiell Designer 7.7.5

The following bug fixes for Designer 7.7.5 and new functionality for Axiell Collections version 1.13 have been implemented:

2022-04-07: additions and changes to XML documentation

In the Application browser, right-click a single screen reference (in a data source) or a single screen file in the \screens folder and select Create documentation in the pop-up menu to create documentation about that screen, or right-click the \screens folder (or another folder containing screen files) and select Create documentation in the pop-up menu to create documentation all screens in that folder. The View menu in the Documentation window offers several formats to convert the documentation result to. New additions are:

An updated documentation format for .inf files:

2022-04-07: new option for default search filter on linked field

The values which can be selected for a linked field can be limited by the application manager to a fixed or variable domain, to force users to pick an appropriate value for this field. Similarly you would sometimes like to limit the offered list of values even more or differently, based on an advanced search. For example, for databases that have multiple record levels (e.g. archives/film), it is only relevant to see the item-level records when attaching items to a loan. In that case you'd like only item records to be presented in the list of records to link to. One may also want to pre-limit that list to items that are actually available (i.e. items without lending restrictions or condition problems) so that an unavailable item isn't inadvertently selected by the user.

From Designer 7.7.5.3038, therefore a new Search filter option is available on the Linked field properties tab of a linked field. In it you can specify any advanced search query you'd like to apply always when a list of available values for this linked field is retrieved from the relevant linked database, for example when the user starts typing in the linked field and the auto-complete drop-down opens for the user to pick a value from or when the user opens the Find data for the field window to search for a list of available values. Also when using the Extend search option from within the Find data for the field window, will the filter will be applied to the list of found records.

The Search filter you set here, will be additional to any domain and lookup field you set for this linked field.

Also, the filter won't be visible in the Collections user interface anywhere. In many cases you probably don’t want that anyway if you have set a search filter based on sensitive information (the object value, for instance).

Collections version 1.13 or higher is required to handle this functionality. Note that if you set this option, you'll also have to update all other Axiell software!

2022-04-07:new &1[4] reserved variable to identify the process that started a before-storage adapl

In a before-storage adapl it is sometimes handy to know which process caused the execution of the adapl, because you'd like certain code to be executed for one process but not for another. Although the adapl is associated with an .inf (database table specification), there might be different reasons for its execution: the WebAPI may have written a record in the database or the Move app did, or an import process has inserted new records, for example.

Therefore now the &1[4] reserved variable has been introduced. In a before-storage adapl this will contain a number ranging from 0 to 6 to indicate which process caused the adapl execution:

This addition is independent of Designer or adapl.exe version.

2022-01-18: release notes Axiell Designer 7.7.4

The following bug fixes for Designer 7.7.4 and new functionality for Axiell Collections version 1.12 have been implemented:

2022-01-18: WebAPI XML payload functionality supported in ADAPL

The Axiell WebAPI 3.0.21344.1 and higher support the processing of posted XML payloads to extract their data to write or update Axiell database records using an adapl.
Imagine for example some media ingest software which generates metadata about the result of an ingest action, in the form of a snippet of raw XML or JSON, with the purpose of having some or all of the information in such a file processed in certain Axiell database records, maybe in the media records that were just created or in object records linking to those media records or maybe in some new event records.
The Axiell WebAPI is now capable of requesting such processing with the load command and the payload argument. The processing of the posted XML file itself however, must be done via a custom adapl. A new <payloadConfiguration> section in the WebAPI adlibweb.xml configuration file specifies the Axiell database name and (location of) the adapl to use, tying it all together. So a raw XML or JSON file posted with a wwwopac.ashx?command=load&payload=my_payload_type1 request would process the posted file according to the my_payload_type1 configuration, using a custom adapl for a specific database, as set in the adlibweb.xml.

For ADAPL to support this functionality, the existing indirection functionality (using the prefix exclamation mark to treat the contents of a text variable or string as if it were a field tag) can now also be used to extract data from an xpath node. Simply provide the xpath path to the desired elements in the XML DOM node, preceded by the payload keyword as identifier to the payload and a space, as a string in a text variable for example and use indirection to retrieve the contents of the node: in this context, the contents are only any textual value directly underneath the specified element, so any subnodes (their element names nor their contents) are not considered contents here. You can also count "occurrences" of a provided xpath element, using repcnt, to find out how often a certain node appears in the payload XML, but note that repcnt counts the total number in the file: you cannot recursively count subnodes per some higher node. An example of an adapl counting the number of mavis/DigitalCarrier nodes in the file, which then retrieves the value of the xl:href attribute of the first DigitalCarrier node, then also counts the number of mavis/DigitalCarrier/objectResourceIdentifiers/ResourceIdentifier/resourceIdentifierType nodes, after which of each of those nodes its content is retrieved can be seen below. Note that the xpath text variable can have any name, it doesn't need to be xpath.

 

* payload test adapl

text xpath[0]
integer occ, maxocc

xpath = 'payload mavis/DigitalCarrier'
errorm 'Count = ' + repcnt(!xpath);
if (repcnt(!xpath) > 0) {
 xpath = 'payload mavis/DigitalCarrier/@xl:href'
 errorm 'First digital carrier href: ' + !xpath
}

xpath =  'payload mavis/DigitalCarrier/objectResourceIdentifiers/ResourceIdentifier/resourceIdentifierType';
maxocc = repcnt(!xpath);
occ = 1
while (occ <= maxocc) {
 errorm 'Occ[' + occ + ']=' + !xpath[occ]
 occ = occ + 1
}

end

So !xpath retrieves the value of the first node, while !xpath[occ] retrieves a specific occurrence of the node. An attribute of an element can be retrieved with the @ prefix: this works with or without attribute namespace.

The errorm texts produced by this payload adapl will end up in the WebAPI response, but only if the <debug>true</debug> setting has been made in the adlibweb.xml configuration file.

When a WebAPI load request is executed, in memory a new blank record is created for the specified database and the adapl is run for that record, so besides generating errorm messages you can use the adapl to assign data from XML nodes to field tags in the record as you would normally assign values to field tags in e.g. a before-storage adapl. To save the new record, include a write _LOCAL statement in the adapl after all relevant data has been assigned to field tags. Leave out the write _LOCAL statement if you don't want to create a new record in the currently relevant database.
You can also (regardless of what you do with the new record in memory) use the ADAPL FACS functionality to read, update or create records in FACS databases that you specify using regular FACS definitions in the adapl.

There's also a new &1 execution code value for payload adapls: 31. So if not all code in your custom adapl is meant for payload processing, you can enclose the payload section by an if (&1 = 31) { ... } condition and the other code by other &1 conditions.

2021-11-15: Spanish, Hungarian and Catalan added to optional application languages

From Designer 7.7.4.2727, three new optional application languages have been added: Spanish, Hungarian and Catalan. Translations of all application texts in these languages can be edited in the Translations manager. Collections 1.12 is required for display of the application texts in these languages: system texts are also available in said languages.
As soon as application texts in these languages have been added, backwards compatibility of the files which hold those texts is broken, so older versions of Designer and Collections cannot open screens or application structures once Spanish, Hungarian or Catalan texts have been added.

2021-11-03: conditional suppression of download possibility in application and image fields

On the Application field properties tab of an application field and the Image properties tab of an image field in database definition. (.inf), a new Disable download condition option has been added to disable the download button next to all occurrences of an image field or application field in a displayed record in Collections conditionally (and thereby disable the possibility to download the images or files registered in those occurrences). In the Disable download condition property you can enter a condition with a format equal to that used for conditional screens and fields, so you could disable the download button by means of a complex condition, e.g. by user role or by field values. When the conditional expression evaluates to true, the download button will be disabled.

Marking the existing Disable download checkbox will always disable the download button for this field and therefore takes precedence over the new Disable download condition property (which will be greyed out in that case).

Note that if you set a download button suppression condition for a linked image or application field, then you should also set it for the source image or application field in the linked database, otherwise the download button will still always be available in the media record itself (if the user has access to it) and in the zoom screen when the user clicks the underlined link to the media record.

Use of this new option breaks backwards compatibility of this .inf, but emptying the option would restore that compatibility.

2021-10-14: alphanumerical sorting added to REPSORT function

A sort mode value 3, to indicate alphanumerical sorting, has been added to the REPSORT function. Other supported options for alphanumerical sorting are +8 (so use value 11) to indicate a descending sort order and +1024 (so use value 1027) to ignore accents.

2021-10-06: new WHERE option for ADAPL FACS READ to fetch records using an advanced search statement

In ADAPL, FACS READ statements have always been limited to either subsequently reading each record in the FACS database, each record in an index in the FACS database, each record matching a certain index value in the FACS database or each record in a saved search (aka pointer file) in the FACS database. This meant that ADAPL had no way to only fetch records that matched multiple conditions. For output formats using adapls this had the consequence that in such cases the user had to perform the proper search in Collections already, possibly apply a specific sorting and mark the desired records, before printing to the output format.

This restriction has now been removed with the introduction of the WHERE option for a FACS READ. Syntax:

READ <FACS name> WHERE '<advanced search statement>'

The advanced search statement can be any query you would normally use in Collections, including any sort option if desired. It uses field tags or English field names from the .inf that is referenced by the FACS declaration: it does not use FACS field aliases. Keys to search on must be enclosed by double quotes (or double single quotes), while the entire search statement must be enclosed by single quotes. For maximum flexibility you don't need to enter a fixed query string behind WHERE: you can also put toghether the advanced search statement in a text variable and then use the text variable (without single quotes around it) as the WHERE argument. This allows you to include e.g. user input (obtained via a parameters screen for a task or output format) or values from the currently processed record in the advanced search.
A sorted query works out the same as in Collections, so note that if the sort field has multiple occurrences, sorting takes place on the value with the highest value (for descending sorting) or lowest value (for ascending sorting).
Besides the obvious use to only fetch records that match the result set of an advanced search, you could well use this functionality for statistical purposes, to calculate sums of insurance values or total volumes etc.

When you perform the READ WHERE for the first time during an adapl run, only the first record of the resulting set will be available in the FACS buffer, so you can use the relevant FACS aliases from your FACS declaration to obtain values from the fetched record. To fetch the next record from the result set, simply use:

READ <FACS name> NEXT

(Pointers to the complete result set are kept in memory after the first READ WHERE, so the following READ NEXT automatically uses that list to fetch the next record without having to execute the advanced search again.)

Example of an adapl-only output format for any data source (no record needs to be selected):

fdstart COLLECT '../data+collect'
 %0 is COL_priref
 IN is COL_object_number
 OB is COL_objectname
 VV is COL_creator
fdend

open COLLECT noreset
 if (&E <> 0) {
   errorm 'Error opening database COLLECT, code = ' + &E
   end
   }

text searchstringvar[0]
searchstringvar = 'object_name = * and VV = "Mondriaan, Piet" sort OB'

read COLLECT where searchstringvar
while (&E = 0) {
 print 5, 70, COL_objectname
 output
 print 5, 70, COL_creator
 output line
read COLLECT next
}

end

2021-10-06: a FACS READ NEXT USING can now be abbreviated to a READ NEXT

If records from a FACS search in an index, e.g. read COLLECT using COL_objectname = 'chair', are subsequently read by a READ NEXT USING in a loop, e.g. read COLLECT next using COL_objectname = 'chair', then you could now abbreviate that next read to just a READ NEXT, e.g. read COLLECT next. The adapl processor will retrieve pointers to the complete result set from the initial READ <FACS name A> USING ... and will remember it for any following READ <FACS name A> NEXT, so the next record will automatically be read by using that list: the index search won't be executed again.
Still, the verbose way of formulating the next READ is not slower than the new abbreviated way, because the old way used the initially retrieved pointers list as well. You can still use the old syntax too.

2021-10-06: new &W reserved variable contains number of hits from last FACS READ

In ADAPL you'd sometimes like to know how many hits a certain FACS READ operation has generated. That number is now available in the new &W reserved variable. The variable is not influenced by a READ NEXT and it doesn't need to be called directly after the READ, but some time later is fine too. The number in &W always pertains to the last executed READ WHERE, READ USING or READ POINTER. The number is stored in the variable as a string, not as an integer, so if you want to do a calculation with the number, you must convert it to an integer first, using int(val(&W)).

A partial ADAPL example of an adapl-only output format which reads all records with an object number and then prints the number of retrieved records:

read COLLECT using COL_object_number = '*'
print 5, 70, 'Hits: ' + &W
output

2021-10-06: new ADAPL COUNT function to count field occurrences matching a condition

Syntax

result = COUNT(FACS_name, '<search statement>')

Arguments

result: integer

FACS_name: FACS database name

search statement: text

Meaning

COUNT (available from Designer 7.7.4.2658, adapl.exe 7.6.21279.1 and Collections 1.12, not compatible with Adlib) counts the number of field occurrences or field group occurrences matching the search statement in the named, open FACS record or in a _LOCAL record (to address the currently open database). The search statement can be something similar to an advanced search:

Example

number = count(COLLECT, 'kj=Lang* when ki=person when kn=retired')

Result

number takes as value the number of field group occurrences in which a field tag kj has the truncated value 'Lan' whilst the same occurrence of field tags ki and kn have the values 'person' and 'retired' respectively.

If the relevant field group would contain the data above, number would result in 1.

2021-06-01: setting up record merging per data source

Sometimes you may have two or more records describing the same person, the same thesaurus term or the same catalogue item or object, for example, and you'd like them merged into one, taking all the best data from those records and automatically delete the remaining ones. Collections 1.12 now offers just that functionality and gives you control over target and source record(s) and to a certain extent over which data you'd like to keep and which must be deleted. The functionality is only present if properly set up for a data source.

This simply involves adding the new RecordMerge method to the existing list of methods in the desired data source(s). Name the method something like "Record merging". You can assign access rights to limit the use of this function and that is certainly recommended. Roles which haven't been assigned access rights to this method will have full access to the function. Without the method, the function won't be available to users in the current data source.
There are good reasons to limit the use of this function because the function can't check if mandatory fields will be filled in after the merge and if non-repeatable fields haven't been assigned multiple occurrences during the merge: see the Collections release notes for version 1.12 for more information about these limitations. So merging records should only be done by knowledgeable users.

After adding the method and recycling the application pool, the Merge selected records (Ctrl+H) icon becomes available in the Result set context toolbar of Collections. The user should mark at least two records to activate the icon.

Using the new method breaks backwards compatibility, but removing the method restores it.

2021-05-06: release Axiell Designer 7.7.3.1790

Today we release an update for Axiell Designer 7.7.3 (build 7.7.3.1790), offering the bug fix and new functionality described below. Axiell Designer can be downloaded from Hornbill: see the FAQs section.

2021-04-29: finding and linking orphaned labels

Because of the new way in which screen tabs are rendered in Collections 1.11.0 and up, and the challenges so-called orphaned labels pose (an orphaned label is a label without an associated field), it has become more important to be able to find out which labels on which screens are such orphaned labels: normally when you place a field on a screen in design mode you get an associated label with it and for the new screen rendering it is important that labels are associated with a particular field, but Designer has also always allowed you to place just a label on a screen, so to be able to find those screens and labels easily now, screens with orphaned labels underneath a data source (not in the \screens folder though), are marked orange and if you open such a screen in the Screen editor the orphaned labels themselves are marked with an orange border too.

If your screen with orphaned labels displays fine, it doesn't need changing of course, but if you find that display is problematic you could try adjusting the screen using the following considerations (do keep a backup of your original .fmt screen files):

2021-04-28: release Axiell Designer 7.7.3.1670

Today we release Axiell Designer 7.7.3 (build 7.7.3.1670), offering the bug fixes and new functionality described below. Axiell Designer can be downloaded from Hornbill: see the FAQs section.

The following bug fixes and new functionality for Axiell Collections version 1.11 have been implemented.

2021-03-09: new optional indexed link table structure for heavily used linked fields

The text below is the original functionality description. For the latest, updated version of this text, please clickhere.

If you have records with hundreds or thousands of reverse or hierarchical links to other records, like a loan record with many links to object records, or archive records with many child records for example, then opening, editing and saving such a record can take a very long time. To solve that problem, a new, optional SQL table structure has been designed, especially for heavily used linked fields, which can be implemented from Designer 7.7.3 (although importing data via Designer or import.exe does not support this table structure yet (06-05-2021), only imports through Collections or Axiell Migration are supported). If implemented in your databases this will lead to an enormous improvement in performance when it comes to processing such records. A requirement for the performance improvement though is that such linked field groups are displayed in table grids, because only then is it possible for Collections to resolve only the visible part of the displayed list instead of the whole list that needs to be resolved when field group occurrences must be displayed in normal fields.

This needs to be set up per desired linked field and can only be done in database tables which are empty. If the procedure is performed in a database table which has data, loss and corruption of data is the undesirable consequence. If the new linkref table structure is required for an existing database table with data, a bespoke migration procedure must accompany the setup to preserve and convert relevant data into the new table structures. Then please consult Axiell ALM for Help.

The new table structure can only be implemented for reversely linked fields (with or without metadata) and for hierarchically (internally) linked fields. (The relevant options are greyed out for other types of linked fields.)

Hierarchically (internally) linked fields

Only internal links of the Hierarchical type can get the new table structure, not the other types. In thesau.inf this would be the broader_term <-> term <-> narrower_term relationship only or part_of_reference <-> object_number <-> parts_reference in collect.inf, for example. Especially the latter is a good candidate because in archives this internal link is used for the entire hierarchy and records can often have many child records. Let's implement the new table structure for this internal link.

For internal links, the relevant Indexed link properties can be found on the Internal link properties tab of a selected internal link definition.

Reversely linked fields with or without metadata

Reversely linked fields (either internally linked or to a field in a different .inf) have new options on the Linked field properties tab, in the Indexed link properties box. Let's assume we have two reversely, internally linked fields in collect.inf: copied_to (cT with linkref tag Ct) and copied_from (cf with linkref tag cF).

2021-03-05: new Media type tag property for image and application fields

From Designer 7.7.3, image and application fields have a new property: Media type tag on the Image properties and Application field properties tab respectively.

Previous to Collections 1.11, linked video and audio files displayed broken-link icons in front of records in the Result set and Gallery views (although the files displayed or played fine in the Media Viewer), if no proper thumbnails could be generated, as is the case for audio and video files, or documents for example.
From Collections 1.11 though, if properly set up and if media types are registered together with media references in the records, then for file identifiers without file extension (which could occur when media files are retrieved via the WebAPI or a DAMS), instead of broken-link icons, the following generic icons will display for audio, documents, images and video files. These icons will also be displayed without proper setup or registered media types if the media type can be distilled from the file name extension while still no proper thumbnail can be generated.

So if the registered media files in your application all have a file extension, like .jpg, .doc, .mp3 or .pdf for example, you don't need to change anything to the setup of your image and application fields: Collections 1.11 will automatically notice and recognize the file extension and if it can't create a proper thumbnail image, one of the above icons will be displayed in the Result set and Gallery views instead.

If, on the other hand, most or all of the registered media files in your application do not have a file extension, because they are identifiers for files retrieved from a DAMS, for example, and you would like the above generic icons to be displayed instead of no icon (!) at all when no thumbnails can be generated, then you will need to do some set up, as follows:

The new setup will make sure that whenever a media file is now uploaded to one of these image or application fields in a record in edit mode, the relevant MIME type will be entered in the Media type field automatically: Collections will extract that type from the file extension or from the file itself if it has no extension. The user won't need to touch that value and Collections will use it to display the proper generic media type icon when appropriate but also to prepare the Media Viewer for the proper media type.
The reason for the media type screen field being writable is that if the above setup has been applied to fields in a database which already has data in it, the user must be allowed to enter the appropriate MIME types in this field manually, if desired. (If all MIME types are the same for a particular field, one could use the Collections Search and replace function for a record selection, to enter that MIME type for a lot of records all at once.) Note that a MIME type registered in the media type field will take precedence over any actual file name extension (if present), when Collections determines which media type icon to display.

Valid MIME types can be found on the internet. Common ones can be found here, for example: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

By the way, an actual thumbnail of an image file of which the MIME type can be determined, will only be generated by Collections if it is one of the HTML5 image types (GIF, PNG, JPEG or SVG). Of other file types, no thumbnail can be generated.

Further note that for one or two customers a <MediaTypeTag> element was introduced and implemented earlier (but never documented) in their settings.xml to do the same thing as the new Media type tag field property, but that setting is now deprecated (because it doesn't work in all situations) and should be replaced by using the new field property.

Using this setting will break compatibility with older versions of Designer and Collections versions older than 1.11.

2021-03-05: a substituting Original filename tag property for image and application fields

From Designer 7.7.3, image and application fields have a new property: Original filename tag on the Image properties and Application field properties tab respectively.  

The option replaces the <OriginalFileNameTag> element in the settings.xml configuration file for Collections. It has the same functionality but that older way (see chapter 4.7 in the installation guide for Collections) of matching image and application field tags to field tags which should hold the original file name when the actually linked media file is turned into a GUID, is now deprecated. The settings.xml way will still work if you don't use the Original filename tag property for fields, but if you consider using the new property, then use if for all fields that were configured in settings.xml for this purpose and then remove the section from settings.xml (although the field properties will take precedence over the relevant settings.xml section if you left it there accidentally).
So if a part of that section is the following, for example:
 

  <DatabaseName ="collect">

    <FieldTag ="FN">

      <OriginalFileNameTag>SO</OriginalFileNameTag>

    </Field>

  </Database>

You would replace it by looking up the FN field tag in collect.inf in the Designer Application browser and on its Image properties tab you would simply enter tag SO (or look it up by clicking the ellipsis button next to the property box) in the Original filename tag property. You'll have entered an existing (allowed) tag if it is being replaced by its field name automatically as soon as you leave the property.

Using this setting will break compatibility with older versions of Designer and Collections versions older than 1.11.

2021-03-02: new &1 execution codes 30 and 29

From Collections 1.11, storage and edit procedures set up for a reversely linked database are now executed when either:

When the edit procedure for a reversely linked database is executed because of one of the reasons above, &1 will be 30.
When the storage procedure for a reversely linked databse is executed because of one of the reasons above, &1 will be 29.

The new execution codes allow you to build code into an edit or storage adapl (use the latest ADAPL compiler that is issued along with Designer 7.7.3) which is only executed when the record is updated through a reverse link. If you don't need that but you just want the existing code (which might currently still only be executed if &1 = 11) to be executed as well when the record is updated through a reverse link, then you'll have to change conditions like if (&1 = 11) to if (&1 = 11 or &1 = 29).

2021-02-26: Copy record and Record template methods added

By default, the Copy record and Record template functions have always been available in all data sources and there was no way to hide these functions.

From Designer 7.7.3.1538 though, a Copy record method type and a Record template method type are now available for methods in data sources, allowing you to set limiting access rights for certain roles, to hide the function in certain data sources for certain users if desired. If you just add one or both of these methods to data sources, without assigning access rights, then those methods will be available in these data sources to everyone.
From Collections 1.11, the Copy record and/or Record template functions will only be present in the Record details context toolbar if a method of the new Copy record and/or Record template type respectively have been added to the relevant data source. This means that to maintain the current Copy record and Record template functions in all data sources, these methods will have to be added explicitly to all those data sources! You don't need to assign access rights to them if everybody is allowed access to the functions. So if these methods have not been added to a data source when Collections 1.11 is going to be used, then both functions will no longer be present in that data source.
To hide the function for all users in all data sources, you won't need to do anything: the missing methods will hide both functions by default in Collections 1.11 an up.

Adding these methods will break compatibility with older versions of Designer and Collections, but removing the methods will restore that compatibility.

2021-02-25: Enumerative fields can no longer accidentally be made multilingual anymore

Enumerative fields should never be multilingual, because of the nature of the field. However, previously you could still accidentally mark the Multilingual checkbox in the properties of an enumerative field, causing incorrect record XML (with a lang attribute for the enumerative field). Designer 7.7.3 (release version) and higher will disable the Multilingual checkbox for enumerative fields (this disabling depends on the Enumeration data type of the field) so that this error can't be made in the future. In the meantime, for fields that already have this erroneous setup, Collections 1.11 will no longer stumble on the incorrect XML and on saving a record with such improper XML it will automatically remove the inappropriate lang attribute, slowly cleaning up the faulty XML this way.

2021-02-10: release Axiell Designer 7.7.2.955

Today we release Axiell Designer 7.7.2 (build 7.7.2.955), offering the bug fixes and new functionality described below. Axiell Designer can be downloaded from Hornbill: see the FAQs section.

2020-10-13: field inheritance now enforced for entire field group

For data integrity reasons it is required that once you set a data dictionary field to Inheritable (on the Field properties tab), the same setting should be made for all fields in the same field group, except that for linked fields in the same field group only the link reference field should be set that way too (not for the linked field itself nor any merged-in fields). To enforce that requirement and to help you do it right, you are now prompted when you mark or deselect the checkbox.

The confirmation question reads the same in both cases: if you mark the checkbox and you answer Yes, all relevant fields in the current field group will be set to Inheritable as well (excluding the mentioned linked fields), while if you deselect the checkbox, answering Yes means that the Inheritable setting will be removed from all fields in the current field group.
Answering No will cancel your action, so if you just marked the checkbox, No will remove the check again (and vice versa for if you just deselected the checkbox).

2021-01-07: Allowing non-media file downloads from an image field linked to a DAMS

An Axiell DAMS may store different so-called renditions of a media file uploaded through an image field, like a thumbnail, an original-size image and/or images or movies in different formats. When Collections retrieves such a file for display or download via de WebAPI, the DAMS will provide the file in the proper format because the Retrieval path and Thumbnail retrieval paths for the image specify the rendition to retrieve via the getcontent server parameter which points to the relevant image server configuration for the DAMS.
However, when non-media files are uploaded through an image field, it is stored in the DAMS as is, and when Collections must later retrieve the file for download (because the Collections user clicked the download button next to the image field), the DAMS normally tries to apply the rendition for detail images (using the rendition specified in the Retrieval path), which is impossible in this case and thus obstructs the download and returns an XML error.

From Axiell Designer 7.7.2.764 (and the Axiell WebApi 3.0.20350.1), image fields therefore have a new option: Download path, underneath the Thumbnail retrieval path. This optional setting allows you to provide a third rendition-specific call to the WebAPI with the server parameter pointing to a different rendition configuration specific for downloading the file as is. Such a rendition configuration will have to be added to the DAMS configuration manually.

Further remarks:

2020-10-13: making a linked field validable on more than one field

Normally a linked field has a lookup field which has a single index. The production.place field in collect.inf in a 4.5.2 application for example, links to the term field in thesau.inf, for which there is a single index, with the fixed domain GEOKEYW (geokeyword). So if a user enters a partial or complete term in the production.place field in an object record, Collections will check that value against all terms with the GEOKEYW domain in the thesaurus, to establish whether the value already exists or not.
Term records in authority database tables like the thesaurus often have another field (besides the term field and the domain field) to identify the term further (as terms needn't be unique), namely the term.code field. A lot of users would like to use terms and term codes intermingled in the same field: if they know the term code by heart they would like to enter that value and have Collections show the auto-complete drop-down list for the linked field with relevant term/term code combinations as they type the code and automatically replace it by the appropriate term, while if they only know the term, they would like to enter the term and validate it against the auto-complete drop-down list or the Find data for the field window normally. Examples of such desired validation combinations are subject classification code/subject term, Dewey classification code/subject term and geographical place code/place name. So the production.place field could be a field that would profit from such double validation.

From Designer 7.7.2.760 and Collections 1.10.1 this functionality is available, but must be set up per desired linked field manually. It takes the following changes:

Here's how it works in Collections. As soon as you put the cursor in the (Production) Place field, the auto-complete list opens with all available terms (with any term codes in brackets) for this field.

You can pick one directly by clicking it or start typing either the term or the term code, after which the list only shows the matching term/term code combinations.

Click the desired term/term code combination to copy it to the field.

After leaving the field though, the term/term code combination is automatically replaced by only the term. In the record, only the record number (link reference) of this linked record will be stored: the term and term code are only retrieved for display.

Instead of using the auto-complete drop-down list, you may also click the validate icon on the right side of the field to open the Find data for the field window. On the View hierarchy tab you'll also see the term/term code combinations and you can filter the list by typing either (the beginning of) a term or term code.

2020-11-11: using adapl-only output formats for PDF and plain text printouts

From Designer 7.7.1.690 and Collections 1.10 you can implement adapl-only output formats to generate output as a plain text file (which can also be a .csv file, because that is plain text too) or as a PDF file: by "adapl-only" we mean that the output format only needs an adapl with PRINT and OUTPUT statements to generate plain text output and optionally PDEST <file_name.extension> FILE to specify the file name and extension/mime type (so you do not combine the adapl with a Word template or XSLT stylesheet in this case).
If the provided file name extension is .csv, it will return a plain text file with mime type text/csv, while if the extension is .txt the mime type will text/plain. If you leave out a PDEST command altogether or include it but leave out the FILE, parameter, then the generated output will automatically be converted to a PDF. In the PDEST command you only need to provide the file name with the extension, but it's no problem if the file name is preceded by a path (which might be the case in an existing adapl output format): the path will be ignored anyway.
Collections will stream the generated file to the user, after which he or she can open or save it at will.

When setting up this type of output format you must set the Template type to the new Custom option, which is introduced for adapl-only output formats specifically. Using this setting will break compatibility will older versions of Designer and Collections, but you can restore compatibility by removing the output format or changing Custom to something else.

You can even add a Parameters screen to this output format, if you want to collect some user input which the adapl must use.

(Former) Adlib for Windows application managers may know that their application (whether it's now being run in Collections or still in Adlib) already contains a number of adapl-only output formats. To activate them for use in Collections only(!) you would need to set their Template type to Custom, but you would still need to check the adapl for Collections-incompatible commands like INPUT, LOCATE and DISPLAY (no extensive list of non-compatible commands is available at this point). User input can now be obtained from a parameters screen, so this will require some reprogramming. You may want to check any PDEST statement in relevant .ada file to see if it generates the required file type. If you want the output format to be available in both Adlib for Windows and Collections, then just make a copy of the existing output format, set it to Custom and adjust it further if required. The copy will be visible in Collections only while the original (which doesn't need adjusting) will only be present in Adlib.

2020-11-11: image and application fields path properties now available in field list grid view

When you click the Fields header in an .inf, the right window pane fills with a grid view of all fields. The displayed columns in this view can be selected via the Column chooser (right-click a column header and select Column chooser in the pop-up menu). Three new columns are now available: Storage path, Retrieval path and Thumbnail retrieval path.

2020-11-09: yesno ADAPL function now supported

In Collections, the YESNO ADAPL function previously did not present a confirmation dialog and always assumed the answer would be yes (true), because that was the more likely response. From Collections 1.10 the user will see a confirmation dialog though. The user has about nine seconds to choose between the Yes button (true) and the No button (false). The seconds are counted down in the No button, indicating that if no choice is made, the result will be as if the user clicked the No button and the message will close by itself. Although Yes normally is the more likely answer, No would usually be the safest option because if this function appears in adapls, clicking the No button often means that the procedure or action won't be executed. So the default (after waiting nine seconds) is now the opposite of what it was.

The confirmation message works in at least before-edit, after-field and before-storage adapls, but not in output format adapls. A complete list of supported adapl types is not available at this moment.

2020-10-29: release Axiell Designer 7.7.1.658

Today we release Axiell Designer 7.7.1 (build 7.7.1.658), offering the bug fixes and new functionality described below.

2020-10-13: link screen adapl supported in Collections 1.10

Any set up Link screen adapl meant to filter out records from the View table tab in the Find data for the field window for a linked field in Collections, is supported from Collections version 1.10. The adapl also works on the auto-complete drop-down list for a linked field. Note that the functionality may slow down performance when opening the Find data for the field window.

2020-10-05: using the Destination dataset field property

On the Linked field properties tab of a linked field you can find the Destination dataset field property. The property is used for linked fields which link to an entire database table or a large dataset, while the user should be able to pick a (smaller) dataset when creating a new linked record from within the Find data for the field window. In that case, the property is usually filled with an enumerative field containing a list of data sources in which the new linked record can be created. See the documentation.title field (tag ti) in collect.inf in a 4.5.2 application for example, using the dataset.document (FE) field in the same .inf as the enumerative list. This used to work for Adlib but not for Collections. Collections offered no choice of dataset and just wrote the new linked record in the first available dataset.
From Collections 1.10 (or unreleased 1.9.6.2189) though, Collections does offer the user a choice of data sources in which he or she is allowed to create the linked record. Collections does use the field set up in the Destination dataset field property for this purpose, but not in the old way. The only requirement for the field is that it is a text field of sufficient length to contain the data source names and that it is repeatable, so it does no longer need to be enumerative and if it still is it doesn't do anything with the translations in the specified list. It is just used by Collections as a temporary container for the user-selected data source: a temporary container is required since Accept link (previously labeled Create term) is a delayed linked record creation. The list will dynamically be filled with the names of the data sources in which the user is allowed to create new records and the data source names will be retrieved from the .pbk. The field will not be stored in the record xml. So for existing applications, nothing needs to change: the enumerative lists might not serve their original purpose anymore, but you can leave them as is. Only for new linked fields which use a new destination dataset field, you now know what the requirements for that field are.

2020-09-24: numeric field properties

Collections 1.10 displays all previously stored numerical values with maximally ten decimals by default, in both edit and display mode, without any automatic padding with trailing zeros. So by default the behaviour has remained the same.

However, you can now change this behaviour in Designer 7.7.1.636 or higher: you can see that all numerical fields (in the .inf files) now have two new properties on a new Numeric field properties tab: Number of decimals (with a default value of 10) and Pad with zeros (deselected by default), matching the behaviour in Collections. You can change these options per field. Mark the Pad with zeros checkbox if you want Collections to add trailing zeros for display or other retrieval (like export or print) of a numerical value in this field. Or change the Number of decimal places to some other value if you don't want users to enter more decimals than that from then on.

For example, with Number of decimal places set to 2 and Pad with zeros marked, if you were to enter a value like 3.1 and leave the field, the displayed value will become 3.10 (although it will still be saved as 3.1, but you can only see that in the properties of the field in Collections). If previously stored numerical values contain more decimals than set in the Number of decimal places option, editing and saving the record won't change those values even if you had put the cursor in such a field without changing anything. So in this example, a pre-existing value like 3.1234 would be displayed as 3.12 but still exist as 3.1234 in the edited or stored record. The actually stored value in a numerical field can be found by right-clicking the field and selecting Properties in the pop-up menu. In this example, a previously stored numerical value with more than two decimals would only be stored differently, namely with maximally two decimals, if you actually change the value yourself. You'll see that you can still type a value with more decimals, but as soon as you leave the field, the value will be rounded off to the set number of decimal places and will be stored that way too.

With either a marked or a deselected Pad with zeros setting, it's no use typing any trailing zeros yourself to indicate the level of specificity or accuracy (of a measurment for example) because they will be stripped off when you leave the field. Use the Pad with zeros option instead and set the Number of decimal places to the expected level of accuracy.

Note that changing one of these options breaks compatibility of this .inf file with Collections 1.9.5 or older and Designer versions older than 7.7.1.636. Although every numerical field now shows these defaults, they are implicit defaults (so they're not yet stored in the .inf) as long as you don't change either option and save the .inf. Just saving the .inf because of some other change won't include the defaults and thus won't break backwards compatibility.

2020-08-19: release Axiell Designer 7.7.1.486

Today we release Axiell Designer 7.7.1 (build 7.7.1.486), offering the bug fixes and new functionality described below.

Disable download of images

Mark the Disable download checkbox on the Image properties tab of an image field to make it impossible for Collections users to download any media file linked in this field. The media can still be viewed in the Collections Media Viewer and thumbnails will still be displayed in the Result set view, but a download button next to the image field will be hidden.
Note that it is not enough to set this option for the reference_number field in media.inf, you'll also have to set it for all image fields linking to that field, like the reproduction.reference field in collect.inf, etc.

Errorm messages in different colours

The errorm statement in adapls may be used for different types of messages, just to inform the user, to warn the user or to alert the user about an error. From Axiell Designer version 7.7.1.170, command-line adapl compiler 7.6.20125.1 and Axiell Collections version 1.8.1.794, it is possible to show these messages in their own colour: blue for informative messages, orange for warnings and red for errors.

To this end the ADAPL errorm statement has been extended with a severity option. Depending on the severity level the message is shown in a different color:

errorm 'INFORMATION in blue', 0
errorm 'WARNING in orange', 1
errorm 'ERROR in red', 2

Note that there are no brackets around the arguments behind the errorm statement.

When the severity code is not set, it defaults to an (orange) warning, for backward compatibility. (Previously though, an errorm message would be red if the current &E result code from some FACS operation was non-zero while it would be green at all other times.)

When the error severity (value 2) is set, this has consequences for:

The information and warning severities (values 0 and 1) have no such consequences.
Errorm's with severity codes can also be used in task adapls, screen adapls and field adapls.

Note that Collections also still generates green messages, to indicate that an action was successful, when a record has been saved correctly for example.

A formatting option for integer fields

Prior to Collections 1.8, integer fields were by default displayed as formatted with thousands separators, but this was not always the desired behaviour and it was also not consistent with the Windows client, which just displays the integer value as is. In the Library catalogue, for example, the Search year (sj) field is defined as an integer with length 4 and is meant to contain just year values. Having the year 2018 displayed as "2,018" (or 2.018, depending on the client's Windows locale) was undesirable.

In 1.8 this was fixed. By default, integer fields now display their value without thousands separators. Here in Designer, a Presentation format option was added below the Data type setting on the Field properties tab of data dictionary fields, to allow you to still have integer fields displaying thousands separators. By default the option is set to No formatting, but you can set it to Use selected language to get the old behaviour back. This is a per-field setting.

Having adapl-created documents uploaded to a repository via Collections

When creating a new Word document via the ADAPL Wordcreatedocument function, you may provide the file name and possibly a relative path in front of it. Typically, the adapl will then insert that (path\) file name in an application field. For Adlib for Windows, the storage and retrieval path for that field would typically be some base path, so Adlib would concatenate this base path and the field contents. In Collections however, a hard-coded relative path and file name may conflict with a DAMS or image server storage URL and (a different) retrieval URL, because application fields are also open for uploading files manually by the user (turning the file names into GUIDs), bypassing the adapl, in which all uploaded files must end up in the same target folder/repository. In that case, Collections would normally not be able to write documents created by an adapl (and filled in in the application field) to the repository.
To solve this problem, an (optional) fourth option has been added to the Wordcreatedocument function, for which you must specify the field tag of the relevant application field (without quotes around it). Instead of hard-coding the tag you may also use tag indirection, so if you've stored some field tag ax in a text variable called my_tag, then !my_tag could be used instead of ax.

If the adapl needs to write a document in a sub folder of the storage path, then make sure that the repository already contains that sub folder, because Collections can't upload those files to a sub folder if it doesn't exist yet. Also note that a relative path to such a sub folder should not be preceded by ../ or ..\ because that would conflict with the storage and retrieval URLs and also pose a potential security risk.

Example:

result = WordCreateDocument (template_path + templatename, docname, 1, !docreftag)

The new option is supported by the adapl compiler in Axiell Designer from version 7.6.18347.1.

Prompted output formats for Axiell Collections

Designer 7.7 and Collections 1.7.3 and higher support so-called prompted output formats. These are normal, predefined output formats that, after selecting one, first present an entry form (a parameters screen) to the user, allowing him or her to enter some extra details pertaining to the print job, before actually printing. These details may just be some extra information to be printed (like a user name or date or reason for printing) or some data with which the output format must still do something (although that data cannot be used to filter out some of the marked records from printing).

The entry form is a normal screen with field tags (parameters) that pertain to the output format only, not to any database definition (.inf). This parameters screen must be specified in the Parameters screen option on the Output job properties tab of the output format.
The relevant field tags must also be defined underneath the relevant output format: you may copy existing tags from some .inf or create new tags, but they won't interfere with any field definition in an .inf. You may create new fields for the output format by right-clicking the output format (or the Fields header underneath it, if already present) and selecting New > Field in the pop-up menu. The requirements for these fields are the same as for tasks: linked fields still need a linked database and a link reference field and you will have to define their Linked field mapping (merged-in) destination fields in the field list as well. Fill out or check the appropriate parameter properties as you would for database fields.

In a Word template, the data entered by the user on the entry form can be printed by including normal references to the fields from the parameters screen but precede each field tag by PARAMETERS+, <<PARAMETERS+a1>> for example if a1 is one of the parameters. PARAMETERS could be considered the name of the implicit FACS buffer that will hold the field contents entered by the user on the parameters screen.

An output format doesn't need to consist of just a Word template though, you may combine a Word template with an adapl too, if you want the adapl to do some preprocessing of data. In the adapl you can access the data entered in the parameters screen by creating a FACS declaration named PARAMETERS (always use this name). There's no need to OPEN this FACS declaration since it is not a real database: after this declaration we can just use the FACS parameter aliases as if they were normal FACS field tag aliases.

Example:

fdstart PARAMETERS ''
a1 is user_name
a2 is print_date
a3 is print_reason
a4 is selection_description
fdend

For an elaborate example of creating a prompted output format, click here.

New ADAPL function: GUID

Syntax

value = guid()

Arguments

value: text

Meaning

The GUID function generates a 16 byte (128 bit) globally unique identifier, that could be used as a persistent ID for a record for example. A GUID is a pseudo random number which is supposed to be unique in the world. Although not a 100% guaranteed unique, the total number of unique keys is so large that the odds of a certain GUID being created twice is very, very small. An example of a GUID would be: 963d5dab-2d6e-4bd8-9f71-6245ba795a50

See also

Linked open data and Persistent ID's

 

Importing data into a database with None default access rights

If the Default access rights property of the database has been set to None or Read you can still import records into this database, using Axiell Designer or import.exe, but you cannot import records that link hierarchically or reversely to an existing record or have imported records force new linked records automatically, because for the latter actions the access rights mechanism of the application becomes active and since Designer and import.exe have no knowledge of user names and roles specified in the application, the $REST role is assumed instead of the proper role of the user who is doing the import (who should have at least write access).

To allow for a successful import in such circumstances anyway, the role entered in the Record owner option of an import job will now also be the role with which the import job will be carried out by Designer 7.7.19345.2 or import.exe 7.619345.3 and higher versions. So you should now use an import job Record owner with Full or Write access to the relevant database. If you don't want this record owner to end up in the Owner field in imported records too, you can still use an import job Storage adapl to empty the Owner field again.