Generating Web Views

Parent-child relationships between issues?

You can add a Child Issues tab to a Web view to allow users to link one or more child issues to a parent issue. For example:

    If you have several bugs that are all symptoms of the same problem, you can make those bugs the children of the main, parent bug for the problem.

    If a task consists of a number of sub-tasks, the sub-task issues can be children of the main task.

    If a bug is present in multiple branches of your code, you can create a child issue for each code branch.

By default, the parent issue controls the substate of the child issues. For example, when a user changes the substate of the parent to Fixed, the children are also marked Fixed. If you want the substate of a child issue to be independent from the substate of the parent issue, you must export the Substate controlled by parent field.

Customized files from the base project?

New projects automatically inherit the customized Web view files of the base project including any custom reports.

When you create a new project, everything in:

CUSTOMIZEDFILES\#Project#<base-project>\

is copied to:

CUSTOMIZEDFILES\#Project#<your-project>\

What if you don’t export a field?

Queries

If you don’t export a field, don’t export queries that reference the field. The query won’t work.

For example, suppose you don’t export the Owner field, but you do export a query like My Open Issues, which tests the value of the Owner field. When a user tries to run the query, the user gets a message saying that the query could not be completed and the view is rolling back to the previous query.

If the query is the default query for the view, users get a more informative message when they log on.

Layouts

Layouts do not include fields that are not exported.

Sorts

Sorts default to sorting by issue number if a field is missing.

Listing Reports

Listing reports (such as the Current Issue - Detailed report, which is used by the Print button) include only the fields exported to the view.

Custom Reports

Like listing reports, custom reports include only the fields exported to the view. However, unlike listing reports, custom reports do not always handle missing fields properly.

For example, if the Owner field is not exported, then, instead of showing owner names along one axis of a chart, the report may show the summary descriptions or the priority values. What the report shows depends on the order of the fields in the report definition (if a field is missing, the next one in the definition is used).

Should you automatically update choice lists?

If you expect to frequently update a choice list, set the Automatically Update List attribute to Yes. This means you won’t have to regenerate the Web view every time you update the list because the view checks for updates each time a user logs on.

By default, only the Contact, Owner, and Submitter choice lists are automatically updated.

Automatically updating a large number of choice lists may affect performance. You should automatically update only the choice lists that you plan to frequently change.

Changing field labels

To change field labels, set the Caption attribute in the Web View Editor. This allows you to override the label specified in the project.

The Caption attribute only changes the label in the HTML form. Everywhere else in the Web view (such as in reports and the Ad-hoc Query Editor), the label defined in the project is used.

When do you have to regenerate?

When you:

    Add a new field or query to a project. Remember to move the new field or query to the Export to View list before you generate.

    Change a choice list (for example, add a new choice, or change the text of a choice), unless Automatically Update List is set to Yes.

    When you change any of the attributes for a field (such as when you set Automatically Update List to Yes).

You don’t have to regenerate when you:

    Change the definition of a query, sort, or layout.

    Define new sorts and layouts. All sorts and layouts are automatically exported to views of the project.

    Create or edit reports.

    Add a group to, or remove from, the list of groups allowed to open the view. You just have to save the view.

    Enable or disable features.

Notes

Web view users must exit and log back on to see the changes.

How to control the layout of fields

The order of the fields in the Export to View list determines the order in which they are laid out in the two columns of the HTML form. For example, here’s how the first six fields in the Export to View list would be arranged, if:

    None of the first five fields are Memo fields.

    Field 3 has Column Span = 2.

    Field 6 is a Memo field and has Column Span = 2 and CSS Class = MemoFieldWidth. (Memo fields automatically have Column Span set to 2 and CSS Class = MemoFieldWidth.)

                                                graphics/FieldLayout.gif

In this example, fields 1 through 5 have the CSS Class set to either ComboBoxWidth or TextBoxWidth. You can change the default widths by editing the CSS classes in CensusMain.css.

Related Topics

Creating and Generating Web Views

Automatically Updating Choice Lists

Adding the Child Issues Tab

Changing Field Captions

Setting Field Labels

Spanning Columns

Applying CSS Styles

Planning