Title: TeamPage 5.2.67

This article describes what's new in Traction® TeamPage version 5.2.67. The main purpose of this release is to upgrade the bundled installer from Java 6 to Java 7 and to introduce support for the forthcoming Attivio AIE 3.5.1 premium search module into TeamPage.

Download TeamPage 5.2


Bug Fixes



• Fixed a bug that could cause an attachment that happened to have the same file name as one or more other attachments to appear in place of those other attachments inline in the digest email message's HTML message body. (This only affected digest skins that support the feature of sending attachments to the digest entries as attachments to the digest email message.) (3db03ef252b9)

Other Improvements



• Added support for the forthcoming Attivio AIE 3.5.1 premium search module.

• TeamPage now also ships with Java 7 instead of Java 6. If you have customizations in your TeamPage plug-ins that use Java, we recommend that you recompile them, although they should continue to function regardless.

Developer Features



• The distinction between custom entry type and entry class has been restored, in the SDK and in the GWT entry forms API (FormFactories using tsi.sdk.data.EntrySourceFactory). The main purpose of this change is to make it easier for developers to use a special form for editing entries by binding those entries to an entry class, while allowing them to mark the entries as belonging to a custom entry type, such as "task", with a different logical name. This is particularly useful when creating forms for creating and editing custom "sub types" of the built-in custom entry types, such as tasks, milestones, projects and events. For a FormFactory configuration file that specifies sources=entry, the custom type of the entries created with that form can still be set via the "entry_custom_type" property, and now the entry class can be set via the "entry_class" property, e.g.

# config/data/forms/myform.properties

class=tsi.sdk.data.EntryFormFactory

display_name=My Custom Form

# located in the current directory
xml=config.data.forms.myform-schema
sdl=config.data.forms.myform-layout

sources=entry

# These entries will be treated just like all other tasks, including belonging
# to the "task" index entry type (config/entry/indextypes/task.properties)
entry_custom_type=task

# But they will belong to the "mine" entry class (config/entry/classes/mine.properties)
# so that they will open in this form for editing.
entry_class=mine


The EntryClass returned by Entry.getEntryClass will now prefer to return the EntryClass with the configuration name given by the "_class" entry property. If no such property is defined, or if its does not refer to a known EntryClass configuration, the EntryClass with the same name as the custom entry type will be used instead, if the entry is marked as belonging to a custom entry type. This is in keeping with an existing and very useful behavior, while still allowing the "_class" entry property to "win" when it is present. Because an entry's EntryClass knows what form to use to edit the entry, is it no longer necessary to override the "editmenu" function in src/com/traction/sdl/gwtrpc/shared.sdl to ensure that the correct custom form is loaded. (Existing plug-ins that include custom forms that don't yet take advantage of this new capability will still require this workaround to be in place so that existing entries continue to be editable in the correct form. But new plug-ins created against TeamPage 5.2.67 and later will not require it.)



Article: Customer4377 (permalink)
Categories: :Doc:R52, :Doc:changelog
Date: September 9, 2013; 5:37:57 PM Eastern Daylight Time

Author Name: Dave Shepperton
Author ID: shep