9.0 Misc Tab

---

• Izenda 7 Series Documentation
• Release Notes
• Upgrade Best Practices
• FAQ
• Tutorials
• The Izenda API
• The AdHocSettings class
• Developer Links and Guides
• Known Issues

---

• Izenda Website
• Product Video
• Izenda Blog
• About Us
• Contact Us

---

• Guide To Report Design
• Making Custom Forms Video

---

• Acknowledgements

About

The Miscellaneous (Misc) tab allows you to add a title, description, header, and footer to the report. It also allows justification to be used on each of these items. This is also where the sharing and Scheduling controls are located as well as tools to create a drill-down.

Feature	Description	Appearance
Report Header Image Justification	Allows you to move the Report Header to the left, middle or right of the page when the report is viewed.
Title	Enter the title of the report.
Description	Enter a description for the report.
Report Header	Allows a user to set a report header. This header will appear once, at the beginning of the report.
Page Header	Allows a user to set a page header. This will appear at the top of every printed page. As of 6.9 this means only PDF print.
Footer	Allows a user to set a report footer.

Note: In the examples above, "INSERT TEXT" is where you will see the text entered for the corresponding field.

9.0.1 Headers, Footers, and Smart Tags

There are two types of Izenda headers - Report and Page. The Report header shows up once, at the beginning of the report. This header is visible in the report viewer.

The Page header shows up at the top of every printed page. This header is not visible in the report viewer, since the concept of printable 'pages' does not apply to the report until it is rendered for print.

Izenda's header and footer controls can accept HTML to create custom content. Izenda also supports smart tags:

Tag	Description
[date]	Displays the current system date.
[time]	Displays the current system time.
[pagenumber]	Displays this page's number in the total set of pages. This tag only returns values when the report is rendered for printing in a .pdf or html export.
[totalpages]	Displays the total number of pages that the report extends across. This tag only returns values when the report is rendered for printing in a .pdf or html export.
[any-field]	Displays the first value visible in the field. Any field which is visible in the currently selected data sources for this report can be viewed. This feature was introduced in Izenda 6.9.0.2

9.1 Share With & Rights

The Share With dropdown allows you to share your report with:

• Everyone - Share this report with everyone in the system. Note that this may include users or roles who are not listed in the dropdown, if the dropdown list is being edited by custom code.
• Users with specific roles - Share this report with only users who have specific roles (e.g. marketing)
• Specific users - Share this report with specific users (e.g. bob)

The Rights dropdown allows you to give the users you are choosing to share the report with different levels of access. The levels of access you can grant are as follows:

• ... - No rights are applied to this report.
• None - The report is unavailable to (hidden from) the users.
• Full access - The report is available for users to view, modify, and save changes to.
• Read only - The report is available for users to view, add or remove filters, and modify the existing filters' values. Users may also modify(design) the report but cannot overwrite the existing report. They may, however, save it as a new report.
• View only - The report is available to the user to view, but not to modify in any way or save changes to.
• Locked (v6.4+) - The report is available to users to view, and users can modify existing filters' values, but users cannot add or remove filters or fields, and they cannot save changes to the report. Users may also not change the column or operator of the filters.

Note: Access privileges will only apply to the user or group selected in the Share With dropdown. All other users will have an access level of None.

Note2: The owner will not change when a user other than the owner saves the report. Choosing "Save As" will create a new report and its owner will be the user that saved the report.

Note3: The "Rights" dropdown menu is hard-coded into Izenda and is designed to cover all possible scenarios concerning user access to reports. Therefore these values cannot be altered, but you can specify which one is selected by default.

Your system administrator will likely determine the list of groups and users available to share reports with. You may then select who you would like to share your report with. You may also determine the level of access you will give to them for this report using the Rights dropdown. The table below describes the characteristics of each option for selecting the appropriate rights.

9.1.1 Setting Sharing Permissions

The SharedWithValues and CurrentUserRoles properties allow reports to be easily shared among users and group of users.  Here is an example of what these properties can look like when used in conjunction with each other.

AdHocSettings.CurrentUserIsAdmin = (bool)HttpContext.Current.Session["IsAdmin"];
AdHocSettings.CurrentUserName = HttpContext.Current.Session["UserName"];
AdHocSettings.ShowSettingsButtonForNonAdmins = false;

if(AdHocSettings.CurrentUserIsAdmin) {
    //Sam is an administrator in the system and has full access to everything
    AdHocSettings.SharedWithValues = new string[] { "Bob", "Sales", "Alice", "Marketing", "Sam", "Mallory" }; //Sam can freely choose who to share with based on department or username
}
else {
    if(AdHocSettings.CurrentUserName == "Bob") {
        AdHocSettings.CurrentUserRoles = new string[] { "Sales" };
        AdHocSettings.SharedWithValues = new string[] { "Bob", "Sales", "Alice", "Marketing", "Sam", "PR" }; //Bob can share reports with anyone but Mallory but cannot view reports that are not shared with "Bob" or "Sales"
    }
    else if(AdHocSettings.CurrentUserName == "Alice") {
        AdHocSettings.CurrentUserRoles = new string[] { "Sales", "Marketing" };
        AdHocSettings.SharedWithValues = new string[] { "Sales", "Alice", "Marketing", "Sam" }; //Alice cannot share reports with Bob or Mallory specifically but Bob can still view reports created by Alice if they are shared with "Sales" and Mallory can view reports shared by Alice if they are shared with "Marketing"
    }
    else if(AdHocSettings.CurrentUserName == "Mallory") {
        AdHocSettings.CurrentUserRoles = new string[] { "PR" };
        AdHocSettings.SharedWithValues = new string [] { "Sales", "Marketing", "Mallory", "Sam", "Visitor" }; //Mallory can share reports with the Visitor role. 
    }
    else {
        AdHocSettings.CurrentUserRoles = new string[] { "Visitor" }; //visitors cannot share with anyone but can see reports shared with the "Visitor" role
    }
}

This sample represents the basic flow of user roles and the "Shared With" values they will see. If we were to log-in as Sam, we would have full access to everything and the values in Sam's SharedWithValues property would fill the dropdown menu. Each user would have different values based on their unique situation.

_Note: If the CurrentUserIsAdmin property is set to true, it will override the SharedWithValues security created by other users, so be careful who you use this property with.

9.1.2 Owner Control

The owner text field is only available to administrators by default. This field is populated with the CurrentUserName of the person creating the report. If no CurrentUserName is available, the application will default to "DefaultAdministrator". This is the default user account for Izenda.

9.2 Drill-Downs

The only difference between a main report and a sub-report is the drill-down key field. Setting this field will enable a report to be used by another report as a sub-report. There is no other difference between a report and a sub-report. Also, a sub-report can have sub-reports of its own. So let's start by creating a report in the Report Designer.

9.2.1 Designing the sub-report

Let's create a report with three fields in it to use as a sub-report.

9.2.2 Setting the drill-down key

We have a report with three fields created. Now we will set the drill-down key. A drill-down key is simply a field which the sub-report looks through to match values when it is passed a value by some other report. Izenda does not check to see if the value passed is valid or logical, it simply looks through the drill-down key field to see if there are any matches. If there are matches, it returns records associated with that match as if we ran a filter which equals that value. If there are no matches, it returns a page which states "No Results".

We can either set one drilldown key or both of them. A sub-report with one key set will only search through the first drill-down key field for a match. A sub-report with both drill-down key fields set will search through the first (top) field, obtain a set of matches, then search those matches for values in the second drill-down key field. This means that if the first field returns no matches at all, the second field will have no valid records to search through.

We can also select whether we want to ignore the first key and just use the second key. This means that we will pass the first value to the subreport, but then the sub-report ignores this value and immediately searches through the second drill-down key field as if the first drill-down key field returned ALL results. The main report will still require both keys to be passed, which we will cover below as well. As an example, if you have a field you do not wish to expose to users, such as an ID field, then you can specify that the drilldown link appears on a name field (such as ShipCountry) and pass the ID field to the sub-report without ever exposing it to the user.

For now, we will set the drill-down keys to ShipCountry and ShipCity and we will not ignore ShipCountry. Please see this link for more detailed information about drilldowns.

Note: Earlier versions of Izenda reports only allow one drilldown key to be used.

9.2.3 Designing the main report

Once the drill-down key is selected on the sub-report, you will need to design a main report to use it. In order to use the sub-report we made, we must select the fields corresponding to the drill-down key fields. You may hide the field corresponding to the second key value and the value will still be respected.

9.2.4 Setting the sub-report

You will then want to click on the Advanced Field Settings button for the fields you designated as the drill-down keys in your sub-report. I.e. if you made ShipCountry and ShipCity your drill-down keys, you will want to apply advanced settings for both of those fields on your main report.

On the first field you selected as a drill-down key, you should set the subreport and drilldown style properties. For the second field, you will select the subreport and the drilldown style "Combokey". This is a special drilldown style which lets this field know it is part of a combination, and therefore it should follow along with the most previous field that is also pointed at the same subreport.

This is the advanced properties form for the ShipCountry key.

This is the advanced properties form for the ShipCity key.

9.2.5 Results

Here is what the main report can look like with the drilldown fields selected.

Congratulations! You have designed a report with a drill-down. You may now interact with your main report to view your sub-report. When you click on ShipCountry, you will notice that the sub-report filters data by both ShipCountry and ShipCity. If you were to use data in a many-to-many relationship, only data that satisfied those two conditions would be shown.

Now when you click on the ShipCountry column, the result will be filtered by ShipCountry and ShipCity. In the result below, Switzerland was clicked.

9.2.6 Passing Filters from Master Report to Sub-Report

The InheritFiltersinSubreports property that your system administrator can set allows the filters applied in the parent report to automatically pass through to the child report (main report to sub-report).

9.3 Scheduler

Your application will need to be properly configured before the scheduling controls appear on the page. If you do not see them, please speak with your system administrator.

Control	Description
Schedule	Set the schedule date and time.
Repeat Type	Set the repeat frequency from a list of possibilities. You may also use custom time spans
Send Email As	Sets the format in which the email is sent. Formats include PDF, Word, Excel, HTML, Link, Embedded, RTF, and CSV.
Recipients	Enter a comma separated list of recipients.

There are two types of time period in the Repeat Type: Every TimePeriod and Alert TimePeriod. Every will run the report every specified time period, and produce an export even if there are no results to display. This means that you may get a scheduled report email with no results, if there are no results to be displayed. Alert will run the report but only email output to specified recipients if there are results - a report which returns 0 records will not send anything to recipients.