Title: TeamPage 6.1


Traction® TeamPage 6.1 is focused on improvements to the Project Management suite, including a new "Burn-up Chart" for tracking progress, improved section tables, and better tools for understanding the big picture for a project or milestone. This release also includes several under-the-hood improvements to TeamPage's forms SDK to make it easier for developers to create custom forms, or customized variations of standard forms.

Download TeamPage 6.1


Features



Project and Milestone dashboards now include a Burn-up Chart. A Burn-up Chart tracks the scope of work to be done to complete a Project or Milestone versus time. You can see the rate at which you're making progress, the scope of the work left to do, as well as track any scope changes, see Why I prefer to use burn-up charts for project planning. The graph is based on on the sum of hours for Completed versus Total Tasks associated with that Project or Milestone. The Default Task Estimate for Task hours can now be specified as a Server default as well as a specific number of hours for each Task.

Section Tables



The Section Table feature has become one of the most popular and important tools in TeamPage's Project Management feature set. In this release, we've given them a visual makeover, but more importantly, we've also made these improvements:

• When a user adds an entry to a section table via its "Add" button, it will be immediately added to the section table.

• When a user updates an entry appearing in a section table, the row for that entry is immediately updated to reflect the modifications.

• When a user right clicks on an expanded section table row, the context menu is displayed for that entry.

• Section table row expansion has been optimized. This improvement reduces the load on TeamPage hosts where section tables get extensive use. This is particularly helpful for customers who nest section table widgets (i.e., include a section table widget in an article which itself appears in the results for another section table widget, and so on).



Other Changes



• The Task Summary is now shown in the side column for Project or Milestone Dashboards. Click the Show Details button to see shows a tabular breakdown by assignee and by Project (for Milestones).



• Made a change to the way that attachments and other files are retrieved from the WebDAV file repository to improve performance for heavy use of file-oriented features. (0bf80ba91a0b)

• Removed the text that would normally link to an ICS file for an event from the collapsed feed rendering of event entries' body text. It is not useful or appropriate in this context, since the body text is displayed as plain text, and therefore doesn't actually link to anything, and just takes up space. (Proteus11511)

• Made a minor change to the way in which TeamPage determines when it is safe and appropriate to update its native fulltext tables, and fixed diagnostic logging associated with native fulltext building. (733ca1864aa3/d2f7b963b67a)

• Added two new space level display settings that allow administrators to specify what display date and attribution display is preferred in single entry views in a particular space. (SPO7590)

• Added a journal setting allowing administrators to specify the default value, in hours, that should be assumed for the purposes of calculations of estimated effort for tasks that have no Estimate. (Proteus11558)

• Added the normal details displayed in other single entry views to all Project and Milestone views, in the details block beneath the title. This information is useful.

Bug Fixes



• Fixed a bug that prevented customers from migrating their old-style file system based attachment stores to the standard WebDAV attachment / share file store; and a bug that prevented the graceful shutdown/restart of the server when the migration process was complete. (Server75815/Server75823)

• Fixed the formula used to automatically display some events and tasks on a User Profile > Calendar. Previously, some events or tasks might appear on a user's calendar to which the user had no direct or discernible indirect relation. (Proteus11488)

• Fixed a bug that could cause the file listing in a Documents view fail to load in Internet Explorer certain cases. (Server75733)

• Fixed a bug that could cause harmless but verbose warnings accompanied by diagnostic stack traces to be printed to TeamPage's traction.log or debug.log files in many cases when the Social Enterprise Web feature is not licensed. (Server75788)

• Fixed a regression introduced in TeamPage 6.0.15 that could prevent the contents of certain folders from being displayed when accessing the folder via certain links that appear in a Documents view. (Server75789)

• Fixed a minor issue caused by a regression in TeamPage 6.0.15 that prevented error messages from being displayed correctly in certain contexts (e.g., if a user tried to navigate to a single entry view of an entry that didn't exist by its entry ID). (Server75826)

• Fixed an issue related to TeamPage's integration with the TinyMCE rich text editor that could cause, e.g., comments on the first paragraph of an entry's body to become dissociated from that paragraph if a new first paragraph was inserted at the beginning of the body. (Server75914)

• Resolved an issue that could cause a user to apparently become spontaneously logged out of TeamPage due to a switch from IPv4 to IPv6 addresses. (cbe02f3b7387)

• Fixed a minor issue that prevented the "Show Document Creation Author and Date" export setting from having any effect. (Server76020)

• Fixed a bug that could cause an unexpected error to occur in certain cases if a user tried to use the "Follow" feature. (Server75888)

• Fixed a bug that could cause an erroneous security error, "There is a draft version of this article, but you do not have permission to read it." to be reported to a user trying to edit an entry that has at least one attachment from a "Published" mode view (as opposed to a view using "Draft"/"Draft Preview" mode). (Server75502)

• Fixed a regression introduced in TeamPage 6.0.15 that caused the "Versions" tab inside the expanded row for an individual document in a Documents view to show only the most recent version. (Proteus11566)

For Developers



• Developing with the TeamPage platform now requires Java SE 8.

Section Tables



Section tables no longer have to be defined by widget attributes or contained in an entry. They can be embedded anywhere by putting a section into scope using the <section> tag, and then rendered in the usual way using the <sectiontable> tag and some other SDL to invoke the same SDL used by the section table TokenRenderer. What's more, section table columns no longer have to be defined via JSON-encoded column definitions, and may instead be specified by a combination of the EntryClass name and the names of the EntryFieldRenderers that should be used to display the column heading text and column values per entry. Here is an example of some SDL used to render a custom section table, displaying for task entries belonging to the special custom task type "foo_task":

  <section size="5" id="foo" active="true" search="c(...)" type="tasks" search="x(foo_task)" title="Open Foo Tasks" proj="__journalrequest.project.id__" entryclass="foo_task" duplicates="true">
    <sectiontable entry_class="#$type$" fields="priority,assigned,start,due,estimate,duration">
      <com.traction.sdl.gwtrpc.token.sectiontable#render />
    </sectiontable>
  </section>


Also, the new "sortby" TokenRendererSet has been added as a way to generate "entry field" renderings to be used by the section table, or other contexts in which a value may need to be rendered for sorting. The new "text" TokenRendererSet, similarly, provides a way to generate "entry field" renderings that can be used to drive JSON data embedded in the section table (via data-* HTML tag attributes) to provide non-HTML versions of the column values for any given entry/row. "text" renderings are useful for driving things like custom charts which need the same data that the section tables provide. It is a good idea to define EntryFieldRenderers in the config/entry/field/sortby and config/entry/field/text directories -- used as the primary source of EntryFieldRenderers for the sortby and text TokenRendererSets, respectively -- in your plug-in alongside the ones in config/entry/field/html and config/entry/field/gwtrpc, in case the fields are useful in section tables or other contexts in which "entry field values" are being treated as data. Besides section tables, this will also generally include the values used by the f() search expression (see below).

Forms API



TeamPage's Java forms API -- i.e., the classes and interfaces defined in the com.traction.sdk.data package -- has been substantially revised, with the goal not just of better performance, but also of achieving a "grand unification" between the forms themselves and the renderings of entry properties as they appear as part of the entries that are created and edited using those forms. This should be a welcome improvement for custom form developers.

Some changes to the Java classes and interfaces in this package will render some code that compiled and ran with TeamPage 6.0.x and earlier incompatible with TeamPage 6.1. If you have plug-ins that make use of the classes and interfaces com.traction.sdk.data package, it is very likely that you will have to recompile your code, and possibly make changes to get it to compile and run again (the required changes are almost certain to be small, such as referencing a different class or interface name, or changing the arguments provided as parameters to certain methods). Please refer to the our SDK documentation for the most up to date information on class and interface names, method signatures, and so forth. If you encounter an issue you are unable to resolve, please file a support request and we will assist you.

Perhaps the single biggest change is that the com.traction.sdk.data.Field class has been split into two parts: the new com.traction.sdk.data.FieldType abstract class now encapsulates field type-specific behaviors, including taking ownership of the existing DataProvider member interface; and the existing com.traction.sdk.data.Field class, which provides the definition of a form field as it appears in particular logical form definition. FieldType is a ConfiguredElement, whose definitions are now driven by the configuration files in the config/data/field/types directory. The default properties for a Field can now be defined in a file named according to the desired Field name (e.g., foo.properties for a field named "foo") and placed in the config/data/field/props directory. In general, a Field configuration file must specify a type= property which refers to one of the FieldType configurations in the config/data/field/types directory, thus linking the Field to a FieldType for all type-specific behaviors. The config/data/fields directory no longer exists.

The preferred way to define a form schema is now via a statically specified schema_elements= property in the FormFactory configuration file. The old method of referring to an xml= property that to an SDL template that is evaluated in order to dynamically generate an XML document is still supported, and it is not necessary to use the new preferred schema definition mechanism. But schemas that are defined statically can be cached and shared globally for all users of the server, which has performance implications beyond even displaying forms, since form schemas can now be consulted even when displaying "fields" for the entries that were created with the form they define (see "EntryFieldRenderers" below).

The form title, the class name used to apply CSS to the form, the text for the form's save button, and other properties can also be specified by properties in the form_* namespace of the FormFactory configuration file. The properties for each named field, including the required type= property, are derived by combining the properties from the configuration with the same name as the field from the config/data/field/props folder, if one is present, and overlaying any field_[name]_* properties from the FormFactory configuration file. This removes the need to repeat the type and other common or fundamental properties of each Field in the schema definition, but still allows those default properties -- such as the label text used for the field when it appears in the form, the number indicating the field's position in the "Tab" order, etc. -- to be selectively overridden as necessary.

Please see the standard FormFactory configurations located in the config/data/forms folder of your TeamPage installation for examples of the new schema definition mechanism in action.

The com.traction.sdk.data.FormLayout interface has been renamed "FormDefinition," which is a name that better captures the purpose of this type. Some methods have been added, and some existing methods have been modified. The FormDefinition represents all of the logical properties of a particular form instance. This is partially driven by the form's schema definition, but is logically independent from that schema: the base set of fields for the FormDefinition come from the schema, but fields can still be added using the addField methods, and fields that are bound to DataSources that don't end up being included in the form are omitted from the final FormDefinition.

Furthermore, the <field> tag can now be used in the SDL used to generate the custom HTML for a form's layout to put the com.traction.sdk.data.Field object into scope from the com.traction.sdk.data.FormDefinition associated with the form being set up. Since the FormDefinition reflects the final set of fields for the form, this provides a built-in way to omit a Field from the authored HTML layout: if the Field cannot be found in the FormDefinition, the markup and gwt.rpc.field tag for that field may be omitted. The form layout HTML library functions in, e.g., src/com/traction/sdl/gwtrpc/fm.sdl and src/com/traction/sdl/tasks/taskform.sdl all now offer utility functions that use the <field> tag in this manner.

it is also worth mentioning that text form fields now support supplying a value to be used for the HTML INPUT element's placeholder= attribute, which will appear as placeholder text in the form field as it appears to the user. The placeholder text may be specified statically in a form field configuration via the placeholder_text= property; or it may refer dynamically to the value of a space, user, journal or server setting via the placeholder_text_store_type= and placeholder_text_property_name= property. For examples of each, please see config/data/field/props/property_estimate.properties and config/data/field/props/property_duration.properties, which are used in TeamPage's standard task form.

Updates to EntryFieldRenderer



EntryFieldRenderers were introduced in TeamPage 6.0.15. Of course an EntryFieldRenderer, like a TokenRenderer, can exist with the same logical name in different directories that are referenced by various TokenRendererSets. This is how TeamPage provides context-sensitive renderings of tokens (widgets) and "entry fields." For example, config/entry/fields/html and config/entry/fields/gwtrpc both contain a file called "due.properties" which define slightly different EntryFieldRenderers to display a task's due date for the html and gwtrpc TokenRendererSets, respectively. But this meant that some boilerplate properties, at least for the display name (label text) of the "entry field", would have to be specified in each such configuration file. This repetition meant that when changes are required, multiple files need to be changed in parallel, which is tedious and error prone, and also just unnecessarily redundant.

TeamPage now supports defining default properties for any EntryFieldRenderer configuration, simply by adding an appropriately named file that contains the desired set of properties to the config/entry/fields/defaults directory. For example, the properties in the file config/entry/fields/defaults/due.properties will be automatically used by the configuration created from config/entry/fields/gwtrpc/due.properties. This makes it much easier to set the name of the associated form field (see below) and/or custom display name text for a named EntryFieldRenderer as it appears in all TokenRendererSets without having to repeat the same property name-value pairs in multiple files.

There was still yet another annoying place for repetition: the label text (or at least display name) for a form field is very nearly always the same text that is wanted when displaying the corresponding property, tag, etc. for an entry once it has been created with the containing form. In order to dispense with this repetition, also, TeamPage now supports binding EntryFieldRenderers to form fields via the form_field= property. This binding is natural, since many "entry field" values correspond one-to-one with form field values, often stored as entry properties. Since this form field binding will usually apply to an EntryFieldRenderer in any context (that is, for any TokenRendererSet), the form_field= property should only need to be specified once, in the corresponding .properties file in the config/entry/fields/defaults directory.

When an EntryFieldRenderer is bound to a form field, TeamPage automatically determines the display text for the "entry field" by retrieving the corresponding com.traction.sdk.data.Field from the schema for the form that would be used to edit a particular Entry. This can also apply to an EntryClass, since it is the EntryClass that binds an entry to the FormFactory that creates the form required to edit the entry. (The Entry or EntryClass is required simply so that the Field associated with the correct form schema can be retrieved, since Field instances appearing in different forms that happen to have the same name can have different display name text. Being able to use an EntryClass directly also means that display text can be retrieved for a particular EntryFieldRenderer even if no specific Entry is available.) The Field will also be put into scope for the SDL used to render the "entry field value" so that the the form.field.* tags can be used, which may be useful in some cases.

Other Changes



• Added support for the entry.displaydate, entry.displaydate.type, entry.displayauthor and entry.displayauthor.type tags, and the corresponding methods in the Entry class (getDisplayDate and getAttribution) that encapsulate the values those tags use. These are designed to work in concert with the new space display settings that allow administrators to specify which display date and attribution types they prefer to see in a given space. See single.sdl in the src/com/traction/sdl/gwtrpc directory of your TeamPage installation for examples of how these tags can be used.

• Added the entry.property.number tag which, like the variable.number or url.param.number tags, will only render a numeric value. If the named entry property is defined but is not numeric, no value will be rendered.

• Added support for a "field filter" search expression, f(). These filters will generally act as predicate filters, and will generally be generated by the user. The values used for each entry will be generated by the EntryFieldRenderer corresponding to the name of the "field" referred to in the filter. Developers, though, may add them, e.g., in SDL, like this:

<entries type="tasks" slice="month" search="f(priority:1)">
...
</entries>


This will act like a normal type=tasks query for the current month, filtering only those whose priority entry field value is "1". The "entry field values" used for this purpose always come from the "text" TokenRendererSet. Since this new "text" "TokenRendererSet" prefers the EntryFieldRenderers whose configurations are defined in the config/entry/fields/text folder, it is advisable for anyone creating their own EntryFieldRenderer to add a configuration to that folder in their plug-in if the normal HTML "entry field value" rendering would include HTML markup.

• Added a complement of EntryFieldRenderers, defined for HTML, GWT-RPC, text, and sort-by contexts as appropriate, for several standard aspects of entries, including:



• The EntryClass API has been modified to support easier handling for custom "standard dates", and to support retrieving custom standard dates in cases where a com.traction.sdk.Context is required (e.g., if an entry may have to be loaded from the journal).

• Fixed a bug that could cause the default TokenRendererSet to be used even when the JournalRequest used to load an Entry had an explicitly requested TokenRendererSet name (set via the setRenderer method). (Server75541)



Attachments:
2015-03-12 at 2.54 PM.png
2015-03-16 at 2.01 PM.png
sectiontable.gif
teampage61_burnup_chart_en.png
TP61wLogo.png
Article: Customer4793 (permalink)
Categories: :Doc:changelog, :Doc:R61
Date: March 25, 2015; 5:01:08 AM Eastern Daylight Time

Author Name: Christopher Nuzum
Author ID: cjn