The fieldmapper (fm_IDL.xml) maps the fields! It defines objects’ fields, linked fields from other objects, and permissions needed to access various things. Most of the Evergreen code (including the reports engine) accesses the database content via the fieldmapper rather than accessing the database directly.

• fm_IDL.xml in Evergreen git repository

The fieldmapper is installed in two locations on your server:

• /openils/conf/fm_IDL.xml
• /openils/var/web/reports/fm_IDL.xml

To view the current fieldmapper on your own site through a browser:

• https://[your domain].org/reports/fm_IDL.xml

Outline of fieldmapper classes:

• Reporting data dictionary

While it was written for the old desktop client, this page is a good starting place to learn about the Fieldmapper and API calls:

This is the shortened term to describe this set of information. If your class will be accessible to pcrud, this is the term you'll use to reference this class in other places in the code.

There are multiple values possible for this field. They include:

• open-ils.cstore
• open-ils.pcrud
• open-ils.reporter-store

This is an estimate of how many records are expected in this class. This is used by the UI in some cases to determine whether or not it's reasonable to pre-fetch all the records of this class. There are three possible values:

• low (less than 100 records)
• high (100-1000 records)
• unbounded (more than 1000 records)

This essentially means that the class or field is not "real" in the actual database table, only in the context of the IDL. It is often used for links to other classes:

<field reporter:label="Hours of Operation" name="hours_of_operation"
 oils_persist:virtual="true" reporter:datatype="link"/>

It can also be used to indicate such things as a view that is defined by SQL in the IDL rather than in the database.

If set to true, this view will show up in the list of core report sources.

Only use this if the value is true. It should be written as

reporter:core="true"

This will be the name of your view in list of available report sources in the reporter, so it should be in readable language.

• bool - true/false
• text
• int - a whole number
• float - a decimal number
• link - a reference to a different class.
• id - a whole number. This class's links are other class's ids.
• money - an amount of money
• org_unit - a library/sublibrary etc.
• interval - an amount of time shown as a number followed by a letter for the unit e.g. 20h for 20 hours or 7d for seven days
• timestamp - an unchanging point in time

There are 3 reltypes: has_a, has_many, might_have.

These distinctions are to indicate key directionality. They are not to indicate nullability.

• has_a – the field physically exists as a column (as in, does not have the @oils_persist:virtual="true" attribute) on the SQL relation being described, and points to a unique key column (usually the primary key) of another SQL relation represented by another IDL class.

• has_many – the field is does NOT physically exist on the described SQL relation, but instead exists as a class property that will be filled with a LIST of zero or more objects built from rows on another SQL relation, described by the <link>'s @class attribute, which have a field that contains the local SQL relation's (effective) primary key.

• might_have – the field does NOT physically exist on the described SQL relation, and there is exactly one row on another SQL relation described by the <link>'s @class attribute that contains the local SQL relation's primary key.

In other words, "might_have" is EXACTLY THE SAME as "has_many", but is guaranteed to always hold exactly one object, or NULL, rather than always hold a LIST of zero or more objects.

Here's how to decide which reltype attribute to use:

• If the field is not virtual, but backed by a real column: ALWAYS use "has_a"

• If the field is virtual, but there's only ever going to be, at most, one row on the other end of the join: ALWAYS use "might_have"

• If the field is virtual, and there can be any number of rows on the other end of the join: ALWAYS use "has_many"

If you specified open-ils.pcrud in the controller, you need to have a section for permacrud. If you did not specify open-ils.pcrud in the controller, do not include this section.

This section specifies whether users should have the ability to create, update, delete, or only retrieve data from this class and its associated table (if applicable).

<permacrud xmlns="http://open-ils.org/spec/opensrf/IDL/permacrud/v1">

This should be the opening tag for your permacrud area.

• create - Must correspond to a permission
• retrieve - Can be used alone without the other create/update/delete actions. Can be used without a specific permission, if appropriate for how the class is to be used
• update - Must correspond to a permission
• delete - Must correspond to a permission

If using the create/update/delete actions, the class must also be mapped to an oils_persist:tablename.

If you specify a permission, you must also include a global_required or context_field attribute or a context element. Otherwise, you will get the error message "Invalid object or insufficient permissions".

• Information about the main fieldmapper classes
• Example of how to navigate the fieldmapper
• Relationship of the fieldmapper to reports
• Relationship of the fieldmapper to the PostgreSQL database schemas