Title: TeamPage 6.2.25

This Traction® TeamPage release is focused on bug fixes and a small set of improvements, including a fix related to automatic creation of TeamPage accounts for accounts defined in external identity servers and some improvements related to user activity tracking and the "Automatic Unused Account Deactivation Policy" setting. Please read on for the full list of changes.

Download TeamPage 6.2




Bug Fixes



Setup



• Fixed a bug that caused the user listing in the server settings > People page to report that all users have Server Setup permission. This is a display issue only, and does not actually affect the enforced permissions of those users. (Server88497)

Editing



• Fixed a bug that caused BR tags or non-breaking spaces to be erroneously inserted into text-only entries when presented for editing in a text-only editor, or in certain other cases. (Server88454 / Server88464)

• Fixed a bug that, in some cases, could cause unnecessary work to be performed when presenting an entry to be edited. (Server88470)

• Fixed a bug that, in some cases, could cause the wrong "rendering" of an entry's content to be displayed when presenting an entry for editing. (Server88474)

• Fixed a bug that could prevent entries that have wiki page names from being edited in certain unusual cases which are not normally allowed by TeamPage's model. (Server88690)

External User Directory Service Integration



• Fixed a bug that could prevent TeamPage from automatically creating new accounts for users who successfully authenticate with an external identity server (e.g., Microsoft Active Directory). (Server88601)

Document Management



• Fixed a bug that prevented the file upload progress indicator that is displayed when a user uploads a document in a folder view by clicking the "Upload Document" button or the "Replace" link for a file from disappearing when the upload completes. (Proteus15310)

Other Fixes



• Fixed a bug that could, in certain cases, prevent the title of a section or section table widget from appearing when it's supposed to. (Proteus15333)

• Fixed a bug that could cause TeamPage to redirect a user to the wrong URL after they correctly enter their credentials into the login form. This is known to have affected the URL for the home page when logging into TeamPage for the first time after creating a new journal that is configured to require login for the built-in Visitor account: in this case, the user would see a page with the following error message:

Error (HTTP response code 404)
A view could not be found that matches: view=home,home skin=proteus



The URL for the page users see after successful login in this context, and others, will no longer cause this issue. (Server88104)

• Fixed some issues in the way that TeamPage handles losing a connection with a client. This can happen if a user cancels a request issued to TeamPage, or possibly in other cases where other network conditions cause connections to be closed prematurely, in which case the TeamPage server will not be able to finish writing the response. These conditions could previously be handled as errors or warnings in a way that suggested other possibly serious problems, and would cause voluminous diagnostic information to be written to TeamPage's log files. These conditions are now correctly handled much more "quietly," and will only generate extra diagnostic information when TeamPage's debug logging is enabled with the "http" debug logging option. (Server88557 / Server88560 / Server88564 / Server88567)

• Fixed a bug in TeamPage's recently revamped Table of Contents Widget plug-in that could prevent PDF export operations from working when the entries being exported contain at least one ToC widget. (Server88354)

• Fixed a bug that caused the wrong confirmation and moderation operation controls to be displayed after a successful entry "Lock" or "Unlock" operation. Previously, the message displayed made it seem as though a "Publish" operation had been performed, and the Lock or Unlock control which is intended to allow the user to reverse the operation they've just performed did not appear. Now, the correct confirmation message and controls are offered. (Proteus15293)

• Fixed a bug that could cause the form used for the Page level "Change Tags" action to remember the space selection from previous uses of this or other forms rather than determining the appropriate default space based upon the entries whose tags are being changed or other contextual information. (Proteus15382)

• Fixed a bug that could prevent TeamPage from being able to send error messages in response to HTTP HEAD requests. (Server87731)

Improvements



User Account Activity Tracking and the "Automatic Unused Account Deactivation Policy"



• Added a new user setting that can be used to indicate that any "Automatic Unused Account Deactivation Policy" currently configured for your TeamPage server should be ignored for a particular user account. This can be useful if you usually make use of this policy but you have have, e.g., a backup administrator account or some other account which isn't used under normal circumstances, but which needs to remain active. The new setting appears on the personal settings > Permissions page with other settings related to account status, and only appears when the viewing user has Server Setup permission, since naturally this setting is not one that ordinary users should be able to change for their own accounts. (Server87604)

• Added a new server setting that allows administrators to indicate whether the date and time of a user's last activity should be updated when a user account is reactivated. It is set to true by default, and if you're using the "Automatic Unused Account Deactivation Policy" to deactivate accounts that aren't being used, you'll probably want to keep it that way to ensure that when an administrator reactivates an inactive account, TeamPage won't deactivate it before the user has a chance to log in. (Server87603)

• When TeamPage receives an incoming email message from a known named and active user account, or when its feed reader component attempts to create entries from the items in an RSS or Atom syndication feed using an active named user account, that will be considered to represent a "user activity event," and will cause the date and time of that user account's "last activity" to be updated. This way, even if user accounts are not being used for ordinary interactive TeamPage usage (e.g., visiting a TeamPage site in a browser), TeamPage's account activity tracker will know that the account is still being used, and will not attempt to deactivate it according to the "Automatic Unused Account Deactivation Policy." (Server88641)

Deleting Articles and Other Entries



• Changed the way an error is reported if a user somehow requests a deletion operation but doesn't specify any targets. (This is not likely to happen outside of the classic batch Delete Articles form.) (Server88675)

• Modified the classic Delete Articles form, accessible from the Collector, to make it easier for the user to understand that their requested deletion operation is being processed. Previously, for operations that may take a long time to complete, there wasn't much visual indication that the operation was happening, and the user might click the "Delete Articles" button a second time. Now, when the user clicks the "Delete Articles" button and clicks "OK" in the confirmation dialog, a small "working/loading" indicator will appear next to the button; and all three form buttons ("Add", "Cancel" and "Delete Articles") will be disabled to prevent the user from clicking them again, and giving a further indication that an operation is already underway. (Server88678)

Other Improvements



• The event form's "Invitees" field has been moved so that it now appears in the more prominent and useful location immediately after the "End Date" field. (Proteus15315)

For Developers



Sections



• The com.traction.sdk.view.Section interface and its implementations have been modified so that its methods no longer require a com.traction.sdk.Context object. The Context object is now supplied at the time the Section instance is created, and is accessible via the Section interface's new getContext() method. This simplifies the API and brings the Section object into line with other per-request transient Traction SDK objects, such as com.traction.sdk.Entry and com.traction.sdk.File objects. The Section interface also now offers the getNumber() method, which returns the 1-based ordinal representing the location of the Section in its containing list (when applicable, e.g., in a list of dashboard sections), which can be useful for identifying the section in many cases. (Server88575)

• The <sections> tag now correctly supports type=variable with a custom variable name specified by the variable= attribute. Previously, this support was incomplete even though the tag documentation indicated that it was supported. (Server88606)

ViewActions for Adding New Entries Related to Items (e.g., tasking a paragraph)



• A new com.traction.sdk.view.ViewAction class, com.traction.view.action.NewRelatedItemEntry, extending com.traction.view.action.NewArticle has been added to support creating new entries related to the currently scoped Item in SDL using the forms API's task item dialog or event item dialog form containers. The NewTaskItem and NewEventItem ViewAction configurations use this new class to provide access to this functionality. Developers can now more easily set up custom links and buttons for allowing users to set up related tasks and event entries -- or "sub types" of tasks and events of their choosing -- equivalent to the way in which the "task" and "schedule" hover item menus work without having to manually create the "region token" encoding to trigger the appropriate type of form and dialog. (Proteus15020)

Forms API



• The data provided to "form-field-value-change" event listeners now includes some additional useful information: the page-wide unique ID of the form as "formId"; the complete form bootstrap properties as "formProperties"; and if the form involves an update to an existing TeamPage journal entry, the edit target ID properties, as "editTarget". Here is an example of the tree structure of the data, as seen in Firefox's console:



• Support has been added for "form-before-save" events. Form developers can now add event listeners for these events using the Proteus.addHandler function. The event listener may return true to allow the form save operation to proceed, or false to veto it. For example:

(function() {
  function myCondition(eventData) {
    // ...
  }
  function onBeforeSaveForm(eventData) {
    if (someCondition(eventData)) {
      // Form submit vetoed.
      return false;
    }
    // Form submit allowed
    return true;
  }
  Proteus.addHandler(onBeforeSaveForm, "form-before-save");
})();


The data that is passed by the event listener includes the usual standard event data for other similar events, including the name of the form and the state of all form fields. For example:



This allows form developers to easily have a validator and other custom code run before a form save operation proceeds. (Proteus15346)

SDK Handling of Inactive Searches



There are two changes in behaviors related to com.traction.sdk.SearchExpressions that are present on a com.traction.sdk.CJournalRequest/JournalRequest but which have been deactivated:

com.traction.sdk.Context's createCleanJournalRequest() method now always provides a JournalRequest that has no SearchExpression. Previously, if a SearchExpression happened to be present on the Context's default CJournalRequest, it would still be present but deactivated via invoking setSearchActive(false) on the copied JournalRequest being used as the "clean" instance rather than being cleared by invoking setSearch(null). (Server88735)

JournalRequest's addConjunctionOrSetSearch and addDisjunctionOrSetSearch now clear any inactive SearchExpression if one is present before setting the provided SearchExpression as the current one for the JournalRequest. This is more in line with the contracts for these methods, and more useful since clients using these methods do not generally want to have a search applied on top of an existing but inactive search. (Server88738)



Attachments:
sample-data.png
sample-form-before-save-data.png
Related Articles
Article: Customer5078 (permalink)
Categories: :Doc:r62, :Doc:changelog
Date: April 23, 2018; 7:33:16 PM Eastern Daylight Time

Author Name: Dave Shepperton
Author ID: shep