| Step 1 - Name & Record Types |
Description |
| Report Name |
The name of the merge report as seen by Relate administrators. |
| Report Label |
The name of the merge report as seen on end user interface pages. |
| Description |
The description of the report as seen by Relate administrators on the relate structure and while editing the multi-entry report. |
| Folder Location |
The folder in Relate structure where the merge report resides. |
| Bundle Settings |
Merge reports may belong to bundles, assuming bundles have been created. These settings are complex and virtually identical for all Relate components. They are described in the article on bundles. |
| Applies to what types of records? |
A record is normally needed to retrieve dynamic values to insert into the merge report. This setting specifies what types of records may be the current or primary record for the report. In cases where any record will do, or no record is needed at all, this setting may be left blank. |
| Fixed Id/Frozen |
These settings are available only to BlueStep staff and are used to identify and lock merge reports that are used by the underlying platform logic. By convention, positive numbers are reserved for use by the Java development team. Negative numbers can be used for other purposes.
|
| Custom Lookup Properties |
This setting is used to add additional identifying attributes as a part of the underlying platform logic or for use by RelateScript. Merge reports can be looked up by RelateScript logic using the lookupMergeReport() function of the System field. |
| Step 2 - Record Categories |
Description |
| Record Categories |
If record types were selected in step 1, all applicable record categories for those types will be shown in this step. This allows further refinement of which type of records this report applies to. In other words, it defines what types of records may be the primary/current record of the report.
For each category you may select "N/A", "Must Have", "Has Any Of These" or "Cannot Have". If the category is unimportant in determining whether a particular record may be used as the primary record, leave the setting as "N/A". If the category is required choose "Must Have". The "Must Have" option may not be available if multiple record types were chosen in step 1 and the category does not apply to all selected record types. If the record must belong to at least one of a group of categories, select "Has Any Of These" for all of the categories in the group. If the report should not be applied to records of a particular category, select "Cannot Have".
The record types and categories determine which forms and other dynamic values will be available within the current record when the report is displayed. The record type and category setting determine what data will be available to work with in steps 3 and 4.
|
| Step 3 - Usage |
Description |
| Show Edit/delete links |
A merge report may include multi-entry reports within its content. This setting determines whether such included multi-entry reports will include edit and delete columns to allow the user to navigate directly to the entries, or just display the multi-entry report content without links to the source data. There is one additional restriction on the display of delete links: If the report allows editable data, it cannot also display delete links, and will only show edit links if this option is selected. This setting is available as two separate settings for HQ/Relate and Connect sites. Generally Relate and HQ are used by staff members who may need the links to see additional detail while Connect sites are intended primarily for non-staff users where the ability to retrieve additional data may be undesireable. |
| Replace Record Summary |
If chosen, the automatically generated record summary for all relevant records (based on the selected record types and categories in steps 1 and 2) will be removed, and this report will be displayed instead. If multiple merge reports applicable to a single record have this option selected, all of them will be shown. However, the order of their display may be somewhat unpredictable. It is important to note that this option is separately available for Relate/HQ and Connect sites, as the summary data presented to staff in Relate/HQ often differs from the summary data shown to non-staff in a Connect site. Additionally, please be aware that editable fields are not available on a record summary page. |
| Insert as a Header |
This setting causes the merge report to be displayed as a header at the top of a page. It works in two separate ways depending on whether there is a primary form selected.
1. If there is a primary form, the merge report is displayed as a form-specific header when viewing or editing entries of the primary. It does not display when viewing a list of entries of the primary form, only when viewing or editing a specific entry.
2. If there is no primary form selected, the report becomes a general header at the top of every page while viewing and editing a record. However, it will not display on the summary screen if the summary screen has been replaced with a merge report. Nor will will it display if there is a form-specific header defined for the current form. In other words, record summary reports and form-specific header reports take precedence over general header reports. If you want a general header to show up on pages with a form-specific report or record summary report, you must explicitly include the general header inside the other merge-report.
As with record summary merge reports, if more than one merge report is marked as a header and has the same primary form setting, then both will be displayed in an arbitrary order. Of course, record type and record category requirements must be met in all cases. For instance, It is perfectly normal to have different general header merge reports for different record categories, and as long as the record type/category requirements don't overlap there will never be a conflict between them.
Also, this setting may be applied separately to Relate/HQ sites and Connect sites. This is intended to allow staff users to see different header data than non-staff users. As with record type and category requirements, no conflicts will occur between header merge reports if one shows only on Connect sites and the other shows only in Relate/HQ.
|
| Available in Record Navigator |
If selected, this merge report will be shown in record navigation along with folders and forms. This option is not available if the merge report has a primary form that is a multi-entry form because the report would not have a specific entry to display when selected directly from record navigation. This setting is also available separately for Relate/HQ and Connect. This is intented to allow staff users to view different reports than are available to non-staff users. |
| Available for Pagelets |
Although this setting only has a checkmark in the "In Connect" column, it applies to all sites including HQ. If checked, this merge report will be available to site designers when sourcing pagelets. A pagelet is used to insert dynamic content into a page from a variety of sources, including merge reports. |
| Primary Form |
This setting is only available if advanced Relate features are enabled or for BlueStep staff editing locked reports. Setting the primary form means that the merge report requires a current entry of the primary form in addition to a current record. If the primary form is a multi-entry form then the merge report cannot replace the record summary, be shown in record navigation or be used in a pagelet because a specific entry is not available in those cases. This setting is required when you wish to make a form-specific header report, if you want the report to be an alternate view of a form, if you wish to write a formula that uses the "current" entry of a multi-entry form, if you wish to use merge-tags for fields of a multi-entry form (the primary form) on step 4, and when you wish to lookup this report in RelateScript using the lookupMergeReport() function of the System field. |
| Alternate View |
This setting requires a primary form. A form entry may have multiple alternate views defines using merge reports in addition to the generic view. A user viewing an entry may select from the alternate views of the entry using a selection box in the upper right corner of the page, near the page title. |
| Edit data |
This setting is only available if advanced Relate features are enabled or for BlueStep staff editing locked reports. It allows editable fields to be inserted into the layout using merge tags. It also causes delete links to be hidden for multi-entry reports, even if the option to display them is selected. If a merge report which allows editable fields is included within a merge report which does not allow editable fields, the editable fields in the included merge report will become read-only. Also, if editable fields are inserted via dynamic merge-tags in a RelateScript formula, they will become read-only fields if this option is not selected.
|
| Calculated display values |
This setting is only available if advanced Relate features are enabled or for BlueStep staff editing locked reports. Selecting this option allows a RelateScript formula to compute additional values to be inserted into the layout of the merge-report. Configuring and writing RelateScript formulas is explained in the article on formulas. Configuring and authoring merge report formulas is nearly identical to other formulas except there is no option to modify data. However, merge report formulas are used very differently than other formulas. Merge report formulas are used to display computed data, add CSS and client-side scripting to pages, build dynamic form layouts, add dynamic search criteria to queries and modify the display properties of option lists. |
| Formula Security |
This setting is only available if calculated display values have been enabled. By default, merge-report formulas can only read data that the user who is viewing the report has permission to read. If the formula attempts to use data that the user does not have permission to view, the formula fails and all formula results are excluded from the final report. However, this setting allows the merge-report formula to run at an elevated security level which allows it to read data that the user does not have permission to. Using this setting, it is possible to circumvent security by displaying the data retrieved via formula. Carefully consider the security consequences of your choice. |
| Step 4 - Report Content |
Description |
| Content |
The content of the merge report is just a piece of HTML which may include CSS or scripts. This HTML is displayed when the report is viewed. The power of merge reports is that "merge tags" may be embedded into the HTML. When the report is viewed, the merge tags are replace with dynamic content. While editing the merge report, merge tags are represented within the HTML as special images. These images are added to the HTML using the "Insert Merge Tag" button of the editor, which is described below. Holding your mouse over a merge tag gives you more information about that tag. If you edit the raw HTML, the merge tag images have special "bsid" attributes which identify the tags and determine their behavior. |
| Inserting Merge Tags |
|
| Step 5 - Permissions |
Description |
| Permissions |
With merge reports it is very important that you understand exactly what you are and are not granting permission to. Merge report permissions grant access to view the layout of the report and the formula results. Permission to actually edit the merge report has a fix permission granted only to Relate administrators. In other words, granting any permission level above "Reader" is exactly the same as granting "Reader" permissions. The layout and formula result can only be viewed, not edited, while viewing the report, so granting a higher permission level has no effect.
Merge report permissions do NOT grant permission to the fields or sub-reports embedded in the report. The items included in the report via merge tags have their own permissions which are not changed in any way by the merge-report permission. Granting "Editor" permission will not make any fields embedded in the report editable. Whether an embedded field is editable is determined by it's own permission settings. By the same rules, whether or not the field data embedded in the merge report is viewable is also determined by the embedded data's own permission settings.
If a field is embedded in a merge report as a read-only value, but the user viewing the report does not have reader permission to the field, then the field will be omitted from the report. If a field is embedded in a merge report as an editable value, but the user viewing the report does not have editor permission to the field, then the field will become read-only or be omitted depending on the permissions granted to the field.
It may be helpful to think of a merge report as a window through which Relate data may be viewed. Permission settings on a merge-report determine whether or not a user may look through the window, but do not effect the permission settings of the things viewed through the window.
|
Print
PDF