Application properties
Contents
On the Application properties tab, which is present when you have selected a new or existing application in the Application browser, you determine the general properties of this application.
Click here for information on how to edit properties in general. And click here to read about how to manage objects in the tree view in the Application browser. On the current tab you'll find the following settings:
An application structure is stored in a .pbk file. Each application is usually saved in a folder of its own. The full path to the currently selected application structure is displayed here.
For safety, only edit a copy of your live application, and test it well in a test environment on a separate database before using it.
If you want to change the location of this application, use the functionality in the tree view or in Windows Explorer to move files from one folder to another, or to rename the folder.
This read-only property displays the type of character set used to encode texts you provide for properties of this object. It does not say anything about the character set used to encode data in. Best leave it to Utf8.
You can change the encoding of database structures (.inf files), application structures (.pbk files) and screens (.fmt files) simultaneously, with the Application character set conversion tool in Axiell Designer.
Here you may provide an identifying name for the current application, with the purpose of implicitly creating an "application" role with this name. But you must not assign users to this role, because this role automatically applies to everyone using this application! This application role can be assigned access rights for specific objects of the application or for database objects. So, if you were to define an Identification for this application, and then map this role to specific access rights for, let's say, a screen file, then you're saying: if this screen file is accessed in this application then these access rights should apply; for use in other applications these access rights do not apply. This way, for instance a standard screen may be read-only in one application, whilst it may be editable in another application.
The $ADMIN role is required for some Collections users to allow them to get extra administrator functionality in Collections. However, this $ADMIN role also always overruled any restricting access rights on elements of the application based on the application id: as explained above, under the hood, each Collections application (library, archive, xplus etc.) has its own id and this id combined with limiting access rights is commonly used in our model applications to hide certain data sources, access points or fields from view because they have no place in that particular application while they do in some other application. Because those application id-based access rights were always overridden, $ADMIN users would not only get the extra functionality but also some out-of-place data sources and such, causing a confusing impression. This has been remedied in Collections 1.17.2 so that $ADMIN users get to see the application as intended while still having access to the extra administrator functionality. Note that in most applications, no application ID/access rights mapping has been added to the mission.inf and missionitem.inf database definitions yet. This means that $ADMIN users still get to see the Move option in the main menu of Collections even when their application doesn't use the Axiell Move functionality. To hide this option from $ADMINs too, all relevant application IDs must be mapped to access rights None in both .inf's.
In Designer you specify roles for users of the application. So, whenever you wish to apply access rights to an application object or database object, you can choose between all user and application roles specified in the application setup.
Since access rights assigned to user roles and application roles can be contradictory, the most restrictive rights of the two, in any situation, apply.
Use large buttons on the toolbar
This setting is not applicable to Axiell Collections and will be ignored.
This setting is not applicable to Axiell Collections and will be ignored.
This setting is not applicable to Axiell Collections and will be ignored.
This setting is not applicable to Axiell Collections and will be ignored.
Truncate free text searches by default
This setting is not applicable to Axiell Collections and will be ignored.
This setting is not applicable to Axiell Collections and will be ignored.
Allow Boolean searches in the Search wizard
This setting is not applicable to Axiell Collections and will be ignored.
Maximum number of keys displayed
This setting is not applicable to Axiell Collections and will be ignored.
Maximum number of retrieved records
This setting is not applicable to Axiell Collections and will be ignored.
This setting is not applicable to Axiell Collections and will be ignored.
This setting is not applicable to Axiell Collections and will be ignored.
Allow on-screen print previews
This setting is not applicable to Axiell Collections and will be ignored.
This setting is not applicable to Axiell Collections and will be ignored.
Allow printer selection by the user
This setting is not applicable to Axiell Collections and will be ignored.
Limit the number of printed records at
This setting is not applicable to Axiell Collections and will be ignored.
Set here the standard access rights for this application, that must apply if no access rights have been set for an object through the roles functionality. If a role and access rights have been mapped for any application object or database object, then those access rights always have priority over the Default access rights for the application (whether those role-specific access rights allow more or fewer user actions than this default). By default, the Default access rights for an application are set to Full.
Setting the Default access rights to None would mean that you'd have to assign broader access rights for applicable roles to individual data sources in this application to grant those roles access to the application and the data sources within, if you're planning to run this application in Adlib for Windows.
However, this construction doesn't work if the application is run by Axiell Collections: once you set the Default access rights to None, Collections blocks access for all users directly after trying to log in, with the message: No accessible application found. So for an application that is meant to run in Collections you are forced to assign broader default access rights than None. You can then assign None access rights for role $REST to all data sources within this application as sort of a substitute default access rights and assign broader access rights for applicable roles to the same data sources.