This Traction® TeamPage release is focused on bug fixes and incremental improvements. Some highlights include fixing an issue that prevented access to the "Email Articles" feature in certain cases; fixes for two bugs affecting rich text editing for users of Internet Explorer; support for configuring section queries to cover dynamic custom time ranges; and reducing the CPU load required to handle event listener tasks run in response to the creation or modification of journal entries, attachments or other documents.
• Fixed a bug that prevented the "Email" action (e.g., "Email Article", "Email Task", etc.) context menu or page tool action from working properly unless the "Classic Traction TeamPage Components" (com.traction.classic) happened to be installed. Attempts to use the action would result in the user being redirected to the all spaces > Dashboard view (home page), although the Collector's "Email Articles" action worked fine and could be used as a workaround. The "Email" actions now work properly regardless of whether the "Classic" plug-in is installed. (Unless you have a particular requirement to use a specific old component, such as using the Mexico skin to support old browsers, we recommend against using the "Classic" plug-in, and TeamPage's installers no longer install it by default.) (Server87967)
• Fixed a bug that could, in certain unlikely conditions, prevent one or more results from being displayed in a search view driven by an external search engine (e.g., Apache Solr). (Server87761)
• Fixed a bug that could cause certain "fully qualified" URLs typed directly into entry content to be broken when included in the context of email notifications, email digests, emailed articles, and certain other situations. Such URLs -- e.g., a URL using the "data:", "file:" or "ftp:" protocols, or the "protocol-relative" "://" prefix. -- erroneously fully-qualified again by having the configured external protocol and address prefix added to the beginning of the URL. (Server87783)
• Fixed a bug that caused an erroneous in-page notification message to appear when viewing a project or milestone dashboard view in one tab or window as an apparent result of posting a new status update to the project or milestone in another tab or window. The confirmation message would read, "Your new task was posted but it does not match the current filter." (Server80017)
• Fixed a bug which could, in certain cases, cause some configuration changes to be applied even when an error with one or more provided setting values could have been rejected, circumventing the usual requirement for all modified settings to be validated (i.e., checked that they are legal and correct as applicable) before any changes being made from the same page are actually committed to any underlying store. Although this issue was never reported "in the wild," it is possible that it could cause invalid values to be stored for certain configuration settings. This fix ensures that can no longer happen. (Server87843 / Server87851)
• Fixed a bug that could cause a script error to be reported in TeamPage's in-page status bar when loading a form that contains a rich text editor if an inline comment form had previously been loaded in the same tab or window. (Proteus15106)
• Fixed a bug affecting Internet Explorer users that could cause a widget being modified in TeamPage's rich text editor to be removed from its current location and placed at the beginning of the content. (Server88016)
• Fixed a bug affecting Internet Explorer that could cause the cursor position to be lost when selecting and deleting an individual image or widget place-holder in TeamPage's rich text editor. The user would not be able to type or perform other editing operations, including typing text or inserting an image or widget, without manually placing the cursor back in the desired location. (Server88024)
• Fixed a bug that could prevent certain journal specific settings -- the journal description under the server settings > General, and "Navigation Links" settings under the server settings > Frontpage -- from being modified. The setting changes would be committed, but not reflected in the setting editor when the page is re-displayed after the administrator clicks the "Apply" button, and would not appear to have taken effect. This is only known to happen with these settings, and with TeamPage journals that were created with TeamPage versions 4.1 and earlier. (Server87890)
• Fixed a bug that might cause an error message to be reported in certain cases when a user has posted a new comment using the inline comment form, or which might cause the newly posted comment not to be immediately displayed. (Server87883)
• Fixed a bug that caused the "Content-Type" HTTP response header to be set to the wrong value by TeamPage when handling certain requests. This issue is not likely to have caused any problems unless the TeamPage server is being accessed through certain types of firewall appliances which rewrite HTTP responses marked with a "Content-Type" header of "text/html". (Server87990)
• Fixed an issue that could prevent the space plug-in settings dialog from targeting the correct space. While the correct space's settings would be reflected in the dialog, the wrong space would be reflected in the space selector at the top of the dialog, and the wrong space's settings might be modified if changes were applied in the dialog. (JPBO18951)
• Fixed a bug that could cause an error to be displayed when selecting (or creating and selecting) a journal to use with TeamPage if the journal lacks a db.properties journal configuration properties file. This is unlikely to affect TeamPage customers in ordinary usage scenarios, but could come into play if a journal database were copied without the entire containing directory structure, e.g., in order to test a metadata index rebuild on a different host. (Server87929)
• Fixed an issue with TeamPage's Windows installer that could cause the Windows "Unlock Traction" service to be set up to run repeatedly. It is only supposed to run at most once, when the host system is starting. (Server87971)
• Fixed a regression introduced in a recent version of TeamPage that could, in some cases, prevent a currently selected per-browser cookie setting for a skin or locale from being properly removed. (Server88060)
• Fixed a bug that could prevent TeamPage from handling certain types of requests properly. The main known consequence of this issue was that TeamPage could fail to log certain requests. It is also possible that this issue could cause certain requests, including those using entry permalink (/traction/permalink/*) and "rapid selector" (/rs/*) URLs, from working properly. (9e877aa521c9)
• Improved TeamPage's performance when many users are simultaneously attempting to perform write operations (e.g., attempting to create, edit or tag entries) by more tightly controlling the number of background tasks spawned to set up and run event listeners. (Server87928)
• Slightly reduced the amount of memory used by TeamPage's journal database metadata indices and certain other related data structures. This is a small change not likely to make a large difference by itself, but the cumulative effect of multiple such optimizations over time will make a difference, particularly for customers who have large journals.
For Developers
SDL
• The set of built-in tags for TeamPage's SDL language has been substantially slimmed down. Some tags that were never used have been removed; other tags that are not used outside of TeamPage's built-in have been replaced, and some of these come with improved implementations and better semantics. (Server79397: Use a new SDL annotation type to get rid of some automatically generated tags no one ever uses)
Forms API
• Proteus now supports "form-field-value-change" events. You can set up your custom event listener by attaching a handler like this:
Proteus.addHandler("form-field-value-change",
function(data) {
// your code here.
});
The data parameter is an associative array that carries information about the change and the current form state as follows:
"formName": the name of the FormFactory configuration (from config/data/forms), e.g., "taskdialog" or "article".
"changedFieldNames": an array containing the names of the form fields whose value changes triggered the event. This has to be an array rather than a single name to cover the case of a single form field change causing any dependent form field values to be updated.
"formState": an associative array whose name-value pairs represent the current state of all form field values, as they would be sent to the server for a form submission (i.e., saveFormData) operation.
Here is an example in the form of a tree view of the associative array data as displayed in Firefox's JavaScript console:
In this case, the Space field ("project") is the one that was changed, and the other field names represent those whose values were changed as a result of dependencies expressed in the form's DataSource. The "originally" changed field name will always be the first one in the "changedFieldNames" array.
Developers can use this capability to add special behaviors corresponding to form field values, e.g., showing a warning message if the user sets a field to a value that may be inadvisable. (Proteus15068)
