Customer5153: TeamPage 6.2.37

Title: TeamPage 6.2.37

Traction® TeamPage 6.2.37 is a maintenance release focused on bug fixes and other general improvements. Highlights include support for pluggable mailbox protocols, refinements to TeamPage's handling of configuration or environmental problems, performance improvements for built-in search filtering, improved protection from cross-site forgery attempts, and improvements to TeamPage's SDK. Please read on for the full list of changes.

Download TeamPage 6.2.37

Bug Fixes

General

• Fixed a bug that caused words that are very common to be added to TeamPage's fulltext index, taking up generally unnecessary space on disk or possibly in memory. If you're using TeamPage's built-in fulltext index, in order to reclaim some disk and memory space, please perform an index rebuild after upgrading to this version of TeamPage. (Server92002)

• Fixed a bug that could cause TeamPage's startup to be substantially slowed down when using a custom user directory configuration that connects to an external service such as a Microsoft Active Directory server. Some customers with these configurations reported that TeamPage could take 3-15 minutes to become available after startup. (Server91863)

• Fixed a bug that could prevent users who have Space Setup permission in a space from being able to use the space settings > Tags page if they did not also have Server Setup permission. In this case, an error would be reported to the user when they attempted to visit the Tags page with the text, "You are not permitted access to that area." (Server91874)

• Fixed a bug that could cause the wrong caption text to be used for certain TeamPage forms when loading an existing entry for editing from certain links or buttons. For example, the caption text might appear as "New Article" for a form loaded to allow editing an existing entry. (Server90900)

• Fixed a bug that prevented the "Show" controls from appearing in the side column of a Milestone > Calendar view, preventing users from controlling which sorts of entries to display on the calendar. (JPBO21813)

• Fixed an issue that could cause entry-level tags displayed on comments appearing in the calendar item details dialog to be displayed in a strange place. (Proteus15913)

• Fixed a bug that could prevent TeamPage from replacing inline references to automatically downloaded images with a reference to the attached image if the URL contained certain characters. (Server92179)

• Fixed a bug that often prevented a useful name from being automatically chosen for automatically downloaded files, such as embedded references to remote images appearing in entry content. (Server92183)

• Fixed a regression introduced in TeamPage 6.2.31 that prevented tags from being preserved when moving an entry from one space to another. (Server92189)

• Fixed a few small issues related to TeamPage's handling of the HTTP HEAD method, including certain situations in which HEAD methods would fail entirely, and some other cases in which TeamPage could improperly send a body in the response to a HEAD method. (Server92226 / Server92254 / Server92255)

• Fixed a bug that could prevent custom configurable selector form field options from being correctly handled in certain cases. (Proteus16028)

Work in Progress

• Fixed a longstanding issue related to the behavior of the "Cancel" or form close button ("X") actions in forms loaded from existing Works-in-Progress. Previously, after loading an existing Work-in-Progress, if a user clicked the "Cancel" button without making any changes, the Work-in-Progress would be deleted without any confirmation being offered. Now, if a user clicks "Cancel" or the form close button ("X") in this situation, they will see this confirmation dialog:

For convenience, pressing enter will choose the "Close and Keep This Work in Progress" option by default. (Proteus15124)

• Fixed another much more minor issue also related to the behavior of the "Cancel" or form close button ("X") actions in forms loaded from existing Works-in-Progress. Previously, after loading an existing Work-in-Progress, if a user clicked the "Cancel" button after they had made some changes, but before the changes had been automatically saved, a confirmation dialog would be displayed allowing the user to choose whether to update the Work in Progress with the changes, or discard the Work in Progress altogether. The text used for the explanation and options in the dialog was slightly confusing since it used the same text and options offered when the user was canceling from a form not loaded from an existing Work in Progress. Now, if a user clicks "Cancel" or the form close button ("X") in this situation, they will see this confirmation dialog:

For convenience, pressing enter will choose the "Finish Later" option by default. (Proteus15130)

Social Enterprise Web (SEW)

This release includes changes that address a few bugs and issues related to TeamPage's SEW features. (Server92138 / Server92176)

• Fixed a bug that could cause prevent users from sharing, tagging, commenting on or tasking certain external web pages using TeamPage's SEW bookmarklet (and other widgets) due to incorrect handling of certain kinds of relative URLs used in those pages' Open Graph metadata properties.

• Fixed several small issues related to the way in which TeamPage validates URLs or other resource identifiers for external web pages and other resources that users are trying to share, tag, comment on or task. These changes should ensure that if a target resource URL or identifier really is invalid or unrecognized, or missing from the definition data in which it is supposed to appear, that this underlying condition is identified early so as to prevent unpredictable failures later, and that a useful error message is reported to the user (and/or developers who may be working on SEW-related features).

• Changed the requirements for using SEW features so that users require at least "Read" permission in the space in which they're trying to share, tag, comment on or task resources such as links.

Other Changes

• Administrators can now review some statistics about existing user private drafts, including how many there are and how many owners they belong to. Administrators can also delete private drafts that are older than a certain number of years. This makes it easier to reclaim space in the event that users tend to abandon and not clean up their own private drafts, or in case TeamPage creates or fails to automatically delete private drafts in the expected manner. For the time being, users who have Server Setup permission can find this new information and control under server settings > Server Files > Other Files > Uploaded Files, below the "Temporary Files" information display and management control. (These controls will both be relocated in a future release.) (Server87740)

• Activity and debug logging for certain kinds of POST requests now includes additional useful information about certain non-sensitive request parameters. This information was always available in TeamPage's W3C extended log files, but since activity logs are commonly used for diagnostic purposes, this will be helpful for administrators or Traction support staff. (Server89400)

• Removed the largely unnecessary "Description" label text for the content field in some of TeamPage's built-in forms, such as the task dialog. (Proteus15894)

• Removed an unnecessary bottleneck in the TeamPage component that processes entry content for storage in the journal and certain other purposes. Removing the limit to the number of threads that can be concurrently using this component means that in environments where users are often creating or editing entries at the same time, and particularly when entries commonly have a lot of content (text and markup), users may notice a speedup when saving or a Work in Progress ("Finish Later"). (Server92123)

Section Tables

Section table filtering now works much better, as long as the section table appears in either a single entry view or in a module-specific page, such as the Impi! Risk module's Risk Table view. Support for multi-valued fields is much better, and when applicable, drill-down links do a better job of filtering, and performance of these kinds of filter search terms has been improved. (Server91924 / Server91956)

We're planning even more improvements to section tables for future releases, so please stay tuned.

Security

• Added another line of defense against cross-site request forgery attacks in TeamPage's handling of requests for certain file manipulation operations. This includes certain attack scenarios not covered by the defenses introduced in TeamPage 6.2.33. (Proteus12489)

• Fixed a bug that could cause users to be navigated to unexpected or invalid URLs after logging into TeamPage using the login form. (Server91887)

Enforcement of Permissions and Rules vs. Other Conditions

TeamPage's core security manager enforces per-request permissions to ensure that attempts to read, create or modify resources can only succeed if the requesting user should be able to do so. Previously, the security manager would also perform certain other kinds of tests, but from now on, TeamPage's core security manager only performs the following sorts of tests to narrowly determine the answer to any question of whether an operation is allowed:

whether the user has the required permission or permissions;
whether any features necessary for the operation require license support, and if so whether they are licensed; and
whether any features necessary for the operation must be enabled using modifiable configuration settings, and if so whether they are enabled.

The following categories of tests are still applied, but are now all applied outside of the security manager:

requirements that there are no current violations of license terms (e.g., too many active users or spaces);
requirements that other required features be completely and properly configured;
environmental checks and requirements (e.g., that the TeamPage service process be allowed to read from and write to certain folders, files and other resources);
any other environmental issues that the TeamPage service has determined will need to be resolved in order for certain operations to be available.

The observable effect for users will be that if an operation should be allowed, but is not available due to a condition identified by one of the tests applied outside the scope of the core security manager, UI elements will not disappear unexpectedly. Instead, TeamPage will either a) present the user with warning or informational messages indicating that there is a problem preventing correct operation of the feature; or b) attempt the operation and in the event of failure, present the user with an error message like any other they would see if an operation failed unexpectedly.

These sorts of conditions that are outside of TeamPage's security model always require the intervention of a server administrator. Not requiring these conditions in the core security manager mean that users will still be presented with the option to retrieve resources they're supposed to be able to read, and the option to perform operations that they are supposed to be able to perform -- based upon their effective permissions and any applicable configuration settings (at the level of server, spaces or user accounts).

All the same tests will be applied just as they have been in earlier versions, but without having features suddenly disappear from the interface for no apparent legitimate reason due to conditions that should be transient and easily solvable, such as a missing SMTP server address for outgoing mail, or the creation or activation of a user account beyond the licensed limit. (Server89586 / Server91790 / Server91786)

Email

• TeamPage's email retrieval and email message sending components have been given a major overhaul. There are many improvements under the hood, but the main visible consequence for customers is that TeamPage now has a pluggable API for customizing existing support for standard email protocols, or adding support for protocols beyond the usual standards (IMAP, POP3 and MBOX for message stores and SMTP for message transport). (Server91362 / Server91300)

For Developers

EntryFields

The com.traction.sdk.token.EntryField class and related APIs have been substantially revised.

• EntryField now produces instances of the new EntryField.ValueSet<T> interface to provide access to the values that a given Entry has for a particular EntryField. ValueSet provides access to an Iterable that covers EntryField.Value<T> objects representing the individual values. Both ValueSet and Value offer the following set of methods to access either a given property or value for the aggregate set of Values, or a given property or value for an individual Value:

T getValue() (Value only): the object representing the individual value.
String getRawValue() (getFullRawValue for ValueSet) a String representing the "raw" value, or encoding, of the full set of values or an individual value, and which is generally the same value used to create a filter.
getDisplayValue(Context, GetProperty) (getFullDisplayValue for ValueSet): the display text that should be used when referring to the value in the interface
getFilter(): the f() search expression, or equivalent, that could be used to filter results for entries having the same value for an EntryField.
getNormalUrl(TractionUrlGenerator): a URL that could be used to target a view focused on the object referred to by one or more values, if applicable (e.g., in the case the value represents a User or a Project).
getFilterUrl(TractionUrlGenerator): a URL that incorporates a search expression (probably the one from getFilter()) which should generally target the current view but with that filter applied as a search so as to filter the results to show only those matching the value or values.
getUrl(TractionUrlGenerator, boolean): this is a way of requesting either a normal URL or a filter URL -- the boolean represents whether a filter URL is being requested -- but which, at the discretion of the Value or ValueSet implementation, may always return one or the other.

• The same SDL tags for accessing EntryField values and properties, such as URLs or filter expressions, and decorated values via EntryFieldRenderers, all still work exactly the same as they did, and some new tags have been added. Here are all the existing and new tags in this category:

entry.field - makes the EntryField named by the name= attribute the current one in Scope.
entry.field.name - the logical name of the current EntryField.
entry.field.displayname - the display name of the current EntryField.
entry.field.value and entry.field.displayvalue - For legacy reasons, this can have multiple meanings depending upon the context, but is generally intended to retrieve either the full raw value or full display value for a whole ValueSet. The entry.field.displayvalue tag will pass all tag attributes as properties to the getFullDisplayValue method so that attributes such as dateformat= or timeformat= for a Date/UTCDisplayDate value can be applied in the usual way.
entry.field.url - The filter URL or normal URL for a ValueSet, depending upon whether the context calls for one or the other to be used.
entry.field.filterurl - The filter URL for a ValueSet.
entry.field.normalurl - The "normal" URL for a ValueSet.
entry.field.filter - The filter search expression for a ValueSet.
entry.field.associatedentries, entry.field.associatedentry - For EntryFields defined in terms of References between entries, loops over the Entry objects like an entries tag, or puts the single associated Entry into scope like various other single entry variations on the entries tag.
entry.field.references - Also for EntryFields defined in terms of References between entries, loops over the Reference objects like a references tag might.
entry.field.labels - For EntryFields defined in terms of one or more Labels currently appearing on an Entry, loops over the selected Labels.
entry.field.date - Effectively a synonym for the entry.field.displayvalue tag that works with values that are single dates.
entry.field.standarddatename - For EntryFields defined in terms of a "standard" named date, this still refers to the name of that standard date.

• The most important new addition is the entry.field.values tag, which iterates over the individual Values from the ValueSet representing the values an EntryField's has for the currently scoped Entry. The following tags can then be used to refer to the properties of each Value: entry.field.value.rawvalue, entry.field.value.displayvalue, entry.field.value.url, entry.field.value.normalurl, entry.field.value.filterurl, entry.field.value.filter, entry.field.value.date. In the case of entry.field.value.displayvalue, as with entry.field.displayvalue, the tag attributes are supplied as properties so that attributes such as dateformat= or timeformat= for a Date/UTCDisplayDate value can be applied in the usual way.

• Inside of the entry.field.values tag, the underlying objects themselves will also be put into Scope, or otherwise used to modify the Scope, in exactly the same way as if an SDL tag were being used to iterate over those objects directly. This means, for example, that if the objects for the Values were Users, the user.* tags will all work as they would. But the tags such as entry.field.value.displayvalue and entry.field.value.normalurl will all work the same way that the corresponding type-specific tags such as user.displayname and user.url would work. This means that those objects and their usual set of type-specific tags will be available in case, e.g., a special SDLEntryFieldRenderer is required for a customized EntryField rendering, they should not be necessary in the most common cases.

• SDK client code should retrieve the value of an EntryField for a particular Entry using Entry's getValues(EntryField) method. The implementation caches the ValueSet produced by the requested EntryField's ValueSet<?> getValues(Entry) method so that it shouldn't generally be necessary to use any external caching mechanism.

`com.traction.sdk.LabelSet` and `EntrySet`

The EntrySet interface has been modified so that it offers read-only operations. The EntrySet.Builder class can be used to assemble and create instances of the the new implementing class, com.traction.sdk.SimpleEntrySet.

A new LabelSet interface has been created, parallel to others like EntrySet, UserSet, etc., to encapsulate a collection of Label instances, usually from a particular LabelIterator that comes from a particular Entry.

"Standard" Dates

TeamPage has a better API for retrieving "standard" (i.e., named) dates.

The new com.traction.sdk.DateType interface offers a stereotyped concept of a particular type of date value. The two subtypes are the existing de-facto types represent the two previously implicit categories of standard dates: Entry.StandardIntrinsicDateType represents various immutable properties of an Entry; and Entry.EntryClassStandardDateType represents a custom definition, usually in terms of entry property values, defined by the associated EntryClass's getCustomStandardDate method.

Other Changes

• com.traction.sdk.Label now has a built-in getDisplayName() method, avoiding the need to manually compose a display name using a LabelNameBucket that appears to be related (e.g., the one currently in scope in SDL). Label instances created via com.traction.sdk.Item's new getLabels(LabelNameBucket) method will automatically be bound to that bucket, and their getDisplayName() method will return the result of that LabelNameBucket's getLabelNameDisplayText(LabelName, CJournalRequest) method.

• com.traction.sdk.admin.Permission is now an enum instead of an ordinary object. Permission still supports some customizable configuration read from the named configurations from config/user/permissions, but certain properties are now correctly hard-coded and immutable.

• Utility methods in com.traction.sdk.props.SimpleProperties related to creating "empty" stores have been improved. Also, some useless methods, which were not applicable to any valid uses, have been removed. The remaining methods make better use of singletons rather than requiring the creation of new instances for objects that do not need to be duplicated. (Server91846)

• Restored proper support for a tag field that supports prefix-matching tags, using a pillbox field and only displaying the tag name with the prefix removed. A future release will have better support for simple binding between pillbox tag field type-ahead completions and a LabelNameBucket. (Proteus15532)

Attachments:

teampage_logo.jpg
cancel-confirmation-fromdraft-clean.png
cancel-confirmation-fromdraft-dirty.png

referenced by (1)

Customer5159: TeamPage 6.2.38

Article: Customer5153 (permalink)
Categories: :Doc:r62, :Doc:changelog
Date: June 17, 2019; 6:24:17 PM Eastern Daylight Time

Author Name: Dave Shepperton
Author ID: shep

Bug Fixes

General

Work in Progress

Social Enterprise Web (SEW)

Other Changes

Section Tables

Security

Enforcement of Permissions and Rules vs. Other Conditions

Email

For Developers

EntryFields

com.traction.sdk.LabelSet and EntrySet

"Standard" Dates

Other Changes

`com.traction.sdk.LabelSet` and `EntrySet`