To create a new report with the same columns, terms, and properties as the current report, select Do Setup Action->Copy this Report. Then choose either of the Create options described below.
If you tweak the layout or is-about rules of a report, you then have the option of either saving or clearing them. If you decide those temporary rules will be of use to you in the future, click on save them and then on the appropriate radio button. That is, either update the current report, or use one of the Create options described below.
If you want the new report to be independent of the current report, click on the Copy columns/terms radio button. If you want future changes to the pieces of info in either report to be applied to both reports, click on the Share columns/terms radio button. (Note: a report that actually contain its columns/terms cannot be deleted if any other report is currently sharing them).
The Share choice is appropriate if both reports are simply canned versions of the same report. For example, perhaps you sometimes need to output a formatted table and sometimes just raw data.
To create a new report from scratch, select Do Setup Action->CREATE REPORT. Then specify its core properties and layout and click on the Create Report button. This creates an empty report with the chosen settings, and also sets it to be about the signups/people of the current event.
Now use the Make page to build the desired report. (In particular, set your is-about rules if the report is not about the current event's signups/people).
To delete a report, select Do Setup Action->Delete this Report.
To update a report's core properties, select Do Setup Action->Update its Props.
These are initialized via Do Setup Action->CREATE REPORT and edited via Do Setup Action->Update its Props.
The name you specify is used in 2 ways:
Naming conventions supported for report names:
When you create a report or whenever you update its properties, you can add a column that will contains its row number. Once you have created such a column, you can edit, format, move, or delete it the same as any other column.
The row number starts at 1, and resets to 1 for each new chunk. Also the column is only actually drawn when the tabular layout is used.
To explicitly identify which signup status's a Report-is-about item matches, create a Search item and choose something from its Signup Status menu. For all other is-about items, status matching is controlled by this dropdown menu. Your options are:
These are initialized via Do Setup Action->CREATE REPORT and edited via Tweak Layout.
PRESTO supports 5 types of reports: Tabular, Activity x Time Grid, Calendar, Label, and Raw Data. (When you set a report's type via its dropdown menu, this causes the applicable input fields to appear as well).
The Build Report user interface displays the Tabular view. Also the Help refers to fields in the report as columns, and signups and people as rows — except in the Activity x Time Grid, Calendar, Label subsections below. There, row and column refer to the "higher level" grids rendered by these report types. For example, there is a column for each day of the week in a calendar.
This kind of report is a table containing all the formatting you specified and one row for each thing that the report is about.
If you leave Report Width blank, the browser will choose its width. When you do enter a width, you must also identify whether it is a percentage of device width, or in inches or millimeters.
Specifying a percentage means that the browser will determine the actual width from the device's available width when the report is output. For example, when you print a report, the browser looks at whether the page is landscape or portrait, and then also subtracts any page margins you have set up.
There are three cases:
This kind of report visually shows when during a day a signup is, like a grid on a signup page does. However rather than showing an activity's start and end time as data, it shows them by the activity's vertical position and height — like a day calendar does.
This kind of report is most useful when there are many signups and several different activities per day. However if there are so many that page width or page height will be greatly exceeded, you might find a Tabular report will look better. The number of fields in the report can also influence this aesthetic decision.
Note: since a planning activity does not have a start time, grid reports do not include planning activities.
Schedule Item's Day is made the report's last title term, unless Day or When Info is already a title term. If so, that existing term will be used. (To cause a 1-day-only report to omit the date from its title, have a Day or When Info title term and give it the Hidden property).
As implied, you can have other title terms. This is how you create a report with multiple chunks/day. For example, if you wanted a chunk/day for Precinct 1 and a separate chunk/day for Precinct 2, you would make Schedule Item's Location your 1st title term.
Schedule Item's Activity and Schedule Item's Start Time are made the report's 1st two non-title fields. However if Schedule Item's Location is a title term, Base Name is inserted rather than Activity. (As noted above, these fields determine the grid's row and column headers, and thus where signups appear in the grid, rather than being data fields within a grid cell).
Any field of the report that duplicates (fully or partially) an added field is ignored during the rendering process.
Except when Row Height is 1 Signup/Time Slot:
The choices for Row Height are as follows.
1 Signup/Time Slot is primarily for "well-behaved" appointment books: all providers service one person at a time and no field is extremely long. Its layout rules are:
Free Form means the height of each time period has no padding. It is simply the height needed by the browser across all columns of the grid. In other words, an hour will sometimes be tall, and other times it will be short.
Same Height means that each hour in the report is given the same height. In other words, short columns are padded as necessary. Thus this option works best when there are relatively few signups per time period. Otherwise the grid gets really tall really fast (i.e. Free Form might work better).
Caveat: the report renderer cannot calculate the effect of line wrapping done by the browser. Thus if you have signups that wrap to multiple lines and short-duration activities, the grid will always be somewhat free form.
Squeezing OK keeps the table more compact when you have a few multi-line quick activities. In particular, suppose you need 2 lines per activity and you have a few 15-minute activities. Squeezing OK will halve the table's height — and the only price will be that those 15-minute activities will have a smaller font and be slightly taller than 1 line.
This property controls the frequency of time labels. You might have to play around to see what looks best for your report, but generally more labels per hour only looks good if you have numerous signups for quick activities. However you must specify 3 per hour if you want a 20-minute oriented layout. Otherwise start times and end times are rounded to the nearest quarter-hour.
This property controls how many Time columns are including in the report. If this field is left blank, there is only a time column at the left edgeof the report. A time-repeat value of 1 is a special case. It causes each interior time column to be a narrow hour-of-day column.
Otherwise the repeat factor applies to both sides of the table. For example, if you enter 3 and the grid has 5 columns, there will be a right-edge time column but NO interior time column. This is because the interior time column would be less than 3 columns from the grid's right edge. Conversely if the grid has 8 columns, the 1 interior column would be after the 4th column — so it would be the same distance from each side of the table.
If this field is left blank, activity names only appear at the top of each report page.
The activities row is repeated at the bottom of a day's grid if the number specified is less than or equal to the number of rows in that day. A row in this context means the number of possible start times in that day. For example if you have activities that start on the quarter hour (even if you only requested 1 time label per hour), you have 4*hours_in_day rows.
If the browser inserts a page break into a day's grid, it will automatically insert an activities header (and footer if applicable) as it does the page break.
This kind of report is for signups. Each report chunk displays its signups within calendar months. It is most useful when each chunk has at most a few signups per day and the report contains at most a few fields. This is simply because day boxes in a calendar are pretty small.
If you leave Width of Each Day blank, the browser will choose the width of the calendar's day columns. If you have wide data in your report, this will mean that data-heavy day columns will be wider than data-less columns.
If you set it, each day column will have the same width. However if you set it too small (particularly if you have don't-wrap fields), data-heavy columns will overflow their widths. Conversely if you increase it to accommodate your widest day column, the overall width of the calendar may exceed the width of a desired output device, and thus be truncated on the right. In other words, some calendar reports simply have too much data in them to use fixed-width day columns.
When you do enter a width, you must also identify its units. Note that % of Page expands or contracts calendar width for the current output device.
Color coding options are provided because putting signups into date boxes spreads like-signups all across the calendar. In other words, you can use colors rather than positioning to emphasize what you want if desired.
There are three cases:
Requesting color coding when you need too many colors is not appropriate. This is because too many colors in a document just becomes visual noise. So in practice, PRESTO's 16-color palette should always suffice.
This type of report is for printing name tags, address labels, and the like.
For a Label report, the report generator outputs an Across x Down grid per page. Each label in the grid contains the non-title fields of one signup or person. If the report has multiple non-title fields, they appear 1 per line in each label, and the 1st one's alignment sets the alignment for all lines in the label. Also Field's Width is ignored, and Wrap and Don't Merge always applies.
This layout uses the available width and height of the current output device. Thus when you display a label report, the shape you see is not the shape you see when you print it. See the Output Report help for more on this.
A label report contains page breaks between chunks — but no chunk titles. Chunking applies so you can create a different set of labels for day1, day2, and so on. If you want the day on the label, instead of just being a page divider, you need to make Day a non-title field. You can also do both by setting the Day title term Hidden.
This type of report is an unformatted table. It should be specified if you want to manipulate the report's data in another application, such as a spreadsheet. (Normally you use Put Report in File for this kind of report, but you can also Display it and then use your browser's Select and Copy to Clipboard commands).
For a Raw Data report, the report generator outputs:
If the report generator cannot render the value of a field for a signup/person, it handles the problem according to the setting of this dropdown menu. Your choices are:
If there are any bad values in a report, a summary error box is displayed. If this indicates any unexpected bad values, we suggest you temporarily do the following things before re-outputting the report.
After outputting the report, use the ??? links to help understand why the bad values occurred.
Sometimes all of your bad values are expected. If you think of them as empty values, you would simply use the Convert to Blank setting.
On the other hand, if a bad value means its signup/person is not applicable to the report, you would use the Omit Row setting. For example, suppose people can signup for a Host activity or Self-guided activity; and that the former has a field identifying the host's guest and the latter doesn't. Also suppose you have a report listing all hosts and their guests. Then each Self-guided signup is going to cause a bad value because its signup form lacks the Guest field.
You can often choose to avoid expected bad values. For the example above, rather than having Current Event be your is-about item, you could have used a Search is-about item that matches only Host signups. Similarly if you have planning activities and on-site activities, and a report applies only to the latter, you could use a Search about-item that only matches on-site activities.
You choose which signups/people are in a report by selecting from the Add People/Signups of dropdown menu or by doing one or more Search commands. Each such rule is called an is-about item.
A People/Signups of->The Entire Database is-about item and Search is-about items that have no Signup Info criteria match people (and all their signups). All other is-about items match signups (and the people with those signups). (Note: since People/Signups of->The Entire Database matches everything, any other is-about items would be redundant).
A report has a row per signup if any column or term in the report contains a value from the Schedule Item's dropdown menu or the Signup's dropdown menu. Otherwise it has a row per person. Note that Calendars and Grids implicitly have Schedule Item fields.
If a report has a row per person:
If a report has a row per signup:
With per-person matching, the report generator uses the items before the per-person marker to identify people and then applies the items after the marker to each such person. In other words, you decide who a report is about and then independently choose which of their signups are included in the report. Thus this kind of matching is primarily used for row-per-person reports containing a Person's Signups field or a # of Signups field.
To setup per-person matching:
Suppose you have a row per person report containing a Person's Signups column.
Per-person matching also allows you to go from more restrictive to less restrictive. For example, if a report is about: Current Event, Per-Person Marker, Matches of Signups done in last year, the report would only have rows for the people who signed up for the current event. But each's row would contain all the signups that person did in the last year.