Title: TeamPage 6.2.27

This Traction® TeamPage release is focused on bug fixes, including some issues related to sections, a problem that prevented template entries from being loaded, and a bug that prevented TeamPage from ingesting RSS or Atom syndication feeds with certain properties. Please read on for the full list of changes.

Download TeamPage 6.2




Bug Fixes



Journal Metadata Indices



• Fixed a bug which, in certain situations, could cause TeamPage's journal metadata indices not to be properly updated. When this happened, TeamPage would fail to start properly, and an index rebuild would be required to get it back in working order. This fix ensures that this can no longer happen. (Server88226)

Web Sockets



• Fixed a bug related to TeamPage's management of open web socket connections. From time to time, an error message like the following, along with a diagnostic stack trace, might appear in the TeamPage server's console output or log file:

Apr 20, 2018 4:43:01 PM com.google.common.eventbus.EventBus$LoggingHandler handleException
SEVERE: Exception thrown by subscriber method onServerMessageEvent(core.traction.event.ServerMessageEvent) on subscriber core.traction.server.jetty.Me
ssageRouter@xxxxxxxx when dispatching event: core.traction.event.ServerMessageEvent@xxxxxxxx


This bug could prevent one or more in-page push notifications for a given event (e.g., a newly created article or tag changes) from being successfully dispatched to all clients. Push notifications will now be reliably dispatched to all clients. (Server88781)

Permission to View User Profile Information



• Modified the appearance of type-ahead user suggestions in various contexts so that email addresses will not appear for any user results for when the requesting user does not have permission to view that user's profile details. (Proteus15418)

• Fixed a bug that could, in certain rare cases, cause certain user profile details to appear for users who should not necessarily have permission to view them. (Proteus15420)

Entry Visibility Dialog



• Fixed a bug that caused users to be listed in the entry "Visibility" dialog even when they didn't have permission to view the entry. This issue did not affect users' actual permissions to view entries or other permissions-controlled resources, but only the display of certain permission related information. (Server88978)

Sections and the Section Editor



This release includes fixes for some minor bugs introduced in TeamPage 6.2.22.

• Fixed a bug that prevented inactive section definitions from being listed in the section list setting editor. Since they were still in the list of sections to be edited, selecting one section might cause the definition for another section to appear in the editor. No data were lost as a result of this bug, but presumably administrators or other users editing section lists would be confused by the inconsistent behavior. (JPBO19592)

• Fixed a bug that caused some anomalies related to the requested types of entries to be included in the results for a section. The "Include" checkboxes for "Articles," "Comments," and "Other" would always appear unchecked which could cause a section's entry type filter to be lost during editing; and certain combinations of requested entry type filters would not be applied correctly to the section's query. These issues have been fixed: the section editor now correctly reflects the section's entry type filter, and the requested entry type filter will always be correctly applied. (Server89052)

Furthermore, checking the "Articles" checkbox for a section's "Include" options will, for now, cause other types of content entries (except comments) that are not normally considered articles -- e.g., tasks or projects -- to be included in a section's results. This is the intended behavior as of this release. In a future release, the "Include" options will be changed so that all entry type options that apply to the requested type of query will be available to be individually selected or deselected.

Templates



• Fixed a bug that prevented templates from being listed in TeamPage's web forms interface when the "Templates" menu is displayed. (Server89096)

Other Fixes



• Fixed a bug that prevented email notifications from being generated to represent the cancellation of calendar events when the associated entry is being erased. (Server88830)

• Fixed a minor concurrency issue that could in certain cases cause some diagnostic information associated with errors that occurred while servicing previously completed requests not to be cleared along with other transient per-request data. This issue is harmless other than the effect of a temporary small amount of memory that might not be eligible to be reclaimed as soon as it might otherwise have. (Server88877)

• Fixed an issue that prevented logging of a standard message when entries are created via TeamPage's GWT SDK service. This includes, for example, status update entries. (Server88838)

• Fixed a bug in TeamPage's internal background process handling that could prevent the Feed Reader module from being able to ingest syndication feeds. (Server88994)

• Fixed the Export and Email links that appear at the top right corner of Project or Milestone list views, such as All Tasks, Activity and Related Articles, so that they will correctly target the listed entries. Previously, these links incorrectly targeted just the Project or Milestone entry itself, and it would have been necessary to use the "Page > Export Articles" action on the context menu to target the listed entries. (Proteus15424)

• Fixed some bugs related to proper handling of inline HTML table formatting attributes, including ensuring that such values are valid before attempting to use them. Exported PDF documents may not precisely reflect the formatting users see in the HTML versions in their browsers, but these changes at least ensure that any manually specified properties will be reflected as closely as possible, and that fewer errors and warnings related to PDF export appear in TeamPage's log files. (Server88813 / Server89022)

Improvements



• A plug-in is now available that offers administrators the opportunity to see a simple report of all users who have subscriptions to a particular space, entry, document folder, author, or tag. (Server88760)

• Modified the appearance of a project entry expanded in a feed so that if there are no results to display in the "Milestones" column, the "Tasks" column takes up the full available width. (Proteus15411)

• Improved diagnostic logging related to TeamPage's Feed Reader module. This is intended to make it easier to see what the feed reader is doing and to provide more helpful information in certain cases when the Feed Reader fails to ingest entries from a syndication feed. (Server88988)

• Japanese localizations have been added for some new setting editor interfaces that were added in TeamPage 6.2.25. (Server89092)

For Developers



Entry "User Roles"



This release introduces the concept of "entry user roles," which are chiefly used to offer stereotyped API methods to answer questions of the form, "which users fill a particular role or have a particular relationship to this entry?"

com.traction.sdk.Entry contains a new interface and two new enums that implement it:

    /**
     * Represents a role that one or more Users can have with
     * respect to an, and provides a mapping from an Entry to a
     * UserSet.
     *
     * @author Dave Shepperton
     */
    public static interface UserRole {

        /**
         * Returns a Function that provides a mapping from an
         * Entry to a UserSet reflecting the
         * Users who have this role for the Entry.
         */
        public Function<Entry,UserSet> entryToUsers();

    }

    public static enum StandardIntrinsicUserRole implements UserRole {

        /**
         * The contributors to an Entry.
         */
        CONTRIBUTORS,

        /**
         * The users mentioned in an Entry's content.
         */
        MENTIONED;

    }

    public static enum StandardAuthoredUserRole implements UserRole {

        /**
         * Users who are considered the assignees for an entry that
         * represents a task.
         */
        ASSIGNEES,

        /**
         * Users who are considered the invitees for an entry that
         * represents an event.
         */
        INVITEES,

        /**
         * Users who are considered members for an entry that supports
         * some sort of membership, such as projects.
         */
        MEMBERS,

        /**
         * Users who are considered owners for an entry that supports
         * some sort of ownership, such as projects.
         */
        OWNERS,

        /**
         * Users who have been subscribed to instant notifications of
         * activity by an entry author or editor.
         */
        SUBSCRIBERS;

    }


The mappings for all the StandardAuthoredUserRoles are handled by these new EntryClass methods:

    public Set<User> getUsers(Entry entry, Entry.StandardAuthoredUserRole role);

    public Set<User> getUsersAssigned(Entry entry);

    public Set<User> getUsersInvited(Entry entry);

    public Set<User> getUsersMembers(Entry entry);

    public Set<User> getUsersOwners(Entry entry);

    public Set<User> getUsersSubscribed(Entry entry);


The following methods have been added to Entry to provide direct access to those Users in the form of a com.traction.sdk.UserSet:

    public UserSet getAssignees();

    public UserSet getInvitees();

    public UserSet getMembers();

    public UserSet getOwners();

    // This will likely be changed to "getSubscribers"
    public UserSet getAutomaticSubscribers();


The main visible change related to these API changes are related to TeamPage's "notifier" event listener, which produces TeamPage's instant notifications (sent via email or other transports). In determining which users should receive a notification for a particular event (e.g., a newly created entry, a tag change, or a newly uploaded file), TeamPage treats the users in all of the standard "authored" roles -- assignees, invitees, subscribers (i.e., the "Notify" list), owners and members -- as candidates for notification regardless of whether any subscriptions they've created for themselves cover the event. For example, users whose name appears in a task's "Assigned to" or "Notify" field will generally automatically receive notifications of activity on that task (as long as they weren't the user who performed the operation that triggered the event).

Previously, the definitions of these roles were all based upon hard-coded references to entry properties, but they're now driven by these newly added APIs. This means that it's easy for plug-in authors to customize the definitions of these user roles simply by creating custom EntryClasses that override one or more of those newly added methods with an alternative implementation of their choosing. For example, a custom task EntryClass could extend com.traction.sdk.TaskEntryClass (see below), and could override the getUsersAssigned method to pull in users from other entry properties to have those users treated as assignees for the purposes of receiving instant notifications. (Server89038)

com.traction.sdk.EntryClass Changes



Users' Permission to "Use" an EntryClass



EntryClass's long-deprecated checkCanAuthorOrEditQ method has been removed, as has the rarely used checkCanAuthorByEmailQ method. There are now four separate methods that can be used to find out whether an EntryClass can be used by a particular user:



In the built-in com.traction.sdk.view.ViewActionDisplay classes, wherever checkCanAuthorOrEditQ was previously used, the applicable one of these newly added methods is now used so that the links or buttons for adding or editing entries belonging to various EntryClasses continue to be included or omitted as appropriate for the viewing user and the context.

These methods are also used in the SDK implementation layer alongside the standard appropriate security checks to determine whether the user is allowed to perform an entry creation or edit operation, making them more than advisory/informational. This allows plug-in authors to create properly tailored custom rules for different sorts of entry creation or edit operations, and to have them enforced on top of TeamPage's built-in permissions model. (Server89066)

Class Hierarchy Reorganization



PM EntryClasses


The EntryClasses representing entry types in TeamPage's PM module have been moved around and reorganized.



These changes make it easy to override the "entry user role" API methods with definitions for those roles specific to each of these PM entry types.

"Microblog" EntryClasses


There have been a few changes to the com.traction.sdk.EntryClass classes representing "microblog" entry types:



These changes clarify the definitions of these EntryClasses, and the relationships among them. (Server88772)



Article: Customer5083 (permalink)
Categories: :Doc:r62, :Doc:changelog
Date: May 28, 2018; 9:28:54 PM Eastern Daylight Time

Author Name: Dave Shepperton
Author ID: shep