Title: TeamPage 6.2.12

TeamPage 6.2.12 is the first planned patch release for TeamPage 6.2. Highlights include integration with FullCalendar to add new calendar capabilities, many improvements related to integration with external identity services such as Microsoft Active Directory, reduction of TeamPage's memory usage, and improved responsiveness of interactive requests. It also includes bug fixes, optimizations and other updates that we feel makes this the best TeamPage release yet. TeamPage plug-in developers will want to review the long list of developer-oriented changes.

Download TeamPage 6.2


Table of Contents


FullCalendar



We're pleased to announce the first release of the FullCalendar plug-in for TeamPage. FullCalendar is a customizable and open-source JavaScript event calendar with many extensible capabilities and a popular API. This plug-in overrides all built-in calendar views and dashboard components with versions that use the FullCalendar API to provide a more interactive and customizable experience, including support for easily changing the time span of events, and showing events from external sources, such as Google Calendar. It also integrates with some other calendar-oriented TeamPage plug-ins such as the 2-Week Dashboard Calendar.

Example FullCalendar Basic Month View

Please refer to Forum6901: FullCalendar plug-in for more details.

Other Improvements



• The context menu, which can be summoned by right-clicking where an entry or paragraph is displayed, or by clicking the "More" link in the hover outline around an entry or paragraph, now includes a "Copy" item to support a simple copy operation. Clicking "Copy" will launch the same form that would be used to edit the entry being copied, with all tags, content and other properties pre-loaded in the form, allowing the user the chance to modify the new copy of the entry. (Server84978: Implement a simple entry copy capability to be offered on the context menu)

• Many under-the-hood improvements related to loading configuration files during server startup, including shrinking the memory footprint of the cached configuration properties. (Server84926 / Server84900)

• The "Change Tags" action now works properly in calendar views. (Proteus14674)

• Changed to a much faster HTML-to-plain-text transformer. This is an important improvement because of how often this transformer is used -- dozens or hundreds of times per view in many cases, such as those using "Snippets" or "Feed" volume renderings. This will be an even more important improvement for you if your TeamPage journal contains many large entries, with lots of text. (Server80770)

• Improved diagnostic logging of various types of failures to create or modify new entries, apply tag changes, and perform moderation operations. It should now be easier to determine the underlying cause of the failure, whether related to insufficient permissions on the part of the requesting user, or an unexpected error due to, e.g., a prevailing condition in the TeamPage server's host environment. (Server84834)

• Made TeamPage's handling of operations saving configuration properties for, e.g., user preferences or space settings, safer and more fault tolerant, particularly in the case of low disk space on the volume hosting the journal or the TeamPage installation itself. (Server83962)

• Made the storage procedure for attachments to newly created or edited entries more reliable. (Server85600)

• Made the default value for the "Volume" setting to "Feed" for "Search" type sections. (Server71135)

• Changed some diagnostic logging related to attachment queries to prevent unnecessary warnings like this from appearing in your TeamPage server's log files:

[WARNING] Failed to locate or open the attachment metadata file journal/attachments/foo/1234/1/filedata.txt
(Enable file debugging for further information.): java.io.FileNotFoundException:
journal/attachments/foo/1234/1/filedata.txt (No such file or directory)


A warning or error will only be logged in this situation a more serious environmental issue, such as a problem with the disk volume where your TeamPage journal is stored. Administrators or developers who are actively investigating an issue related to attachment query failures can get access to more verbose logging by activating "file" debug logging (server settings > Server Files page under Log Files > Debug). (Server86016 / Server86266)

• Updated the libraries that TeamPage uses to support NTLM authentication to their latest respective versions to ensure that the latest fixes and improvements are available to customers who rely upon these capabilities. (Server86469)

• Updated to the most recent version of the Apache Derby JDBC connectors to pick up all the latest fixes and improvements for TeamPage customers. (Server86873)

• Improved the way that certain diagnostic information is classified for logging. This will make it easier to obtain the desired information -- and to avoid seeing other noise -- when developers or administrators are using debug logging to investigate questions or issues, particularly those related to external libraries that TeamPage uses to support various capabilities and features. (Server86464)

• Improved the information that administrators can see related to ongoing "crawler" operations -- feed or verify (used to populate external search engines). The administrator will now at least be able to see what the last document was that was processed, and when it was created, which can help give an idea of how much progress the crawler has made. (Server86738)

• Type-ahead completion suggestions offered from TeamPage's main search box now include named pages from various spaces, sorted according to their relevance in the context of the current page and for the requesting user. (Proteus14940)

• Changed the way that the indexing status of documents is tracked for integration with external search engines to require much less memory. (Server86872)

• The "No Access" status has been removed from the external search index administration dialog. It no longer applies, since the tracker event listener and indexing daemon both run as the built-in "super-user" ("(super)") account. (Server86977)

• The external search engine index administration dialog now has a link that an administrator can use to generate a CSV report on all the documents in the "Error" and "Skipped" status categories. The report includes the document ID, the status, and the detail message. (Server86980)

• Optimized the way that user account activity is recorded to remove any possibility of slowing down interactive requests, and to make the required database operations more efficient. (Server86953)

• Optimized the way that "read tracking" is performed to remove any possibility of slowing down the display of pages focused on single entries. (Proteus14958)

• Improved logging of journal setup operations. (Server86995)

Bug Fixes



Integration with External User Identity Services



• Fixed a regression introduced in TeamPage 6.2 that could prevent a newly selected user directory (e.g., Active Directory) from being applied if the administrator concurrently set up a migration for existing accounts' security principals as part of the cut-over. (Server86478)

• Fixed a regression introduced in TeamPage 6.2 that caused too many results to be returned for certain types of queries, including inline type-ahead completion suggestions for user @ mentions. (Server86696)

• Fixed a regression introduced in TeamPage 6.2 that caused certain types of type-ahead-completer tag form fields to be rendered as selectors. This may have been visible to some TeamPage customers who have custom forms. (Proteus14729)

• Fixed a regression introduced in an earlier version of TeamPage related to session management that could cause an administrator to be logged out of TeamPage when testing login for a new user directory configuration. (Server86458)

• Fixed a bug that caused the user directory tester view to appear blank after a failed test login attempt. (Server86460)

• Fixed a bug that caused TeamPage to attempt to record successful or failed authentication when an administrator used the test login feature when setting up a new user directory configuration. (Server86294 / Server86481)

• Fixed a bug that prevented certain diagnostic information related to attempted authentication attempts using NTLMv2 from being logged in a readable fashion. (Server86461)

• Changed the way that NTLMv2 authentication failures are handled to produce more useful error messages, particularly for administrators who are testing login for a new user directory configuration. (Server86477)

• Changed the handling of failures to connect to external LDAP services to be correctly treated as internal server errors (HTTP response code 500) rather than a general bad request error (HTTP response code 400). These problems likely represent configuration or environmental issues -- not a problem with the request from an end user. (Server86300)

Other Bug Fixes



• Fixed a regression introduced in TeamPage 6.2 that could prevent new journals from being created. (Server86138: Journal creation fails)

• Fixed a regression introduced in a preview release of TeamPage numbered 6.2.06 or greater that prevented a user's preferred locale and time zone from being applied in background processes, e.g., generation of digest email messages. (Server86502)

• The requesting user's permission to apply tags mentioned in a section definition will now be correctly taken into account when determining whether to show the "Add" button for a section based upon a tag-driven query. Previously, the "Add" button may have been offered even for a user who does not have permission to apply at least one of the tags required to make a new entry appear in the section's results. (For the sake of clarity: this bug did not allow the user to apply a tag they should not have been allowed to apply, but rather only to launch the form for adding a new entry to a section. That is, the form would be launched, but there would be no way for the user to apply any of the tags they do not have permission to apply, and thus any new entry they created would not appear in the section's results.) (Server76384)

• Fixed the "bounce" messages generated when TeamPage rejects an incoming email message due to a lack of permissions. (Server84834 / Server84835)

• Fixed some issues related to the enforcement of certain permissions concerning certain files and folders. (Server83245)

• Fixed a regression introduced in a recent patch release that caused "Oldest First" sort order not to work in certain cases, such as in the context of a "Specific Articles" section. (Server85659)

• Fixed a bug that prevented section tables from properly observing the maximum number of configured results for a section of the types "Search", "Tasks", "Projects" and "Milestones." (Server85656)

• Fixed an issue that could cause some email software or webmail environments, such as Outlook, not to be able to display the correct "friendly name" when showing sender or recipient information from email messages generated by TeamPage. (Server84997)

• Fixed a bug that prevented an entry's share folder, if it existed, from being moved along with attachments when the "Move" feature was used to move an entry to a new space. (Server83910)

• Fixed a bug that could prevent certain entries from being indexed by Apache Solr with a TeamPage server that is set up to use a Solr server. (Solr907)

• Fixed a bug that prevented the correct sub-tab from being selected in single entry views. For example, in a single entry view of a project entry the "Projects" sub tab of the "Tasks" tab is supposed to appear styled differently from the other tabs to indicate that it is "selected" as the "current" tab. (Proteus14809)

• Fixed an issue that caused the text of contiguous paragraphs to run together in certain cases, such as in an activity feed view or certain other cases when showing a "snippet" of the entry's content in text-only form. (Server85548)

• Fixed an issue related to the default user setting governing the initial state of the checkboxes appearing in the Activity > Feed view's "Filter by Type" control. The "Changes" checkbox would initially appear checked, but all entries (not just changes) would be displayed. Now, none of the checkboxes will initially appear checked. (JPBO14839)

• Fixed a bug that could cause open tasks that appear in the context of another task (e.g., tasking content within the parent task, or within the content of one of its comments) to be styled like closed tasks, with a strike-through and in lighter text. (Server81960)

• Fixed a page style issue that caused the names of assignees or other users listed in the collapsed feed renderings of certain types of entries appearing in the User Profile > Notifications page to be difficult to read due to insufficient contrast between the background and foreground text colors. (JPBO5254)

• Fixed an issue that prevented the "X" icon from being visible in rich text editor dialogs, such as the "Insert/Edit Widget" dialog. (JPBO14329)

• Fixed an issue that could prevent custom skin color stylesheets from being correctly loaded when running the TeamPage service with certain configuration options. (Server85523)

• Fixed a minor regression introduced in TeamPage 6.2 that prevented the correct HTML-to-text down-sampling from being applied to "snippets" displayed in, e.g., search results or collapsed feed renderings. (Server86313)

• Fixed a minor bug that could cause HTML entity-encoded runs of text to appear in certain contexts in which a text-only rendering is required, e.g., the subject of an email notification message. (Server86641)

• Fixed a minor regression introduced in a recent preview release of TeamPage which could cause various problems related to the display of "snippets" display in various contexts due to a failure to preserve runs of HTML entity-encoded text. (Server86916)

• Fixed a minor regression introduced in TeamPage 6.2 that prevented the templates menu from appearing in the Event form. (Proteus14878)

• Fixed a regression introduced in a recent preview release of TeamPage (numbered 6.2.06 or later) which prevented the Widget editor dialog from being correctly displayed when the user requested to see a list of all available widgets. (Server86560)

• Fixed a regression introduced in a recent preview release of TeamPage (numbered 6.2.06 or later) which prevented the log file viewer's search feature from working in certain cases. (Server86245)

• Fixed some regressions introduced in a recent preview release of TeamPage (numbered 6.2.06 or later) which prevented certain setting editors from being displayed. (Server86309)

• Fixed a regression introduced in a recent preview release of TeamPage (numbered 6.2.06 or later) which prevented selected options from being correctly applied or displayed in certain setting editors. (Server86685)

• Fixed the handling of some database query errors that can happen under normal conditions when creating a new journal so that they will no longer appear in the TeamPage service console log. They are still logged once more "quietly" as warnings if they do occur, in traction.log or debug.log. (Server86297)

• Fixed the way that TeamPage creates non-personal email messages (i.e., messages not created by a user making use of, e.g., the Email Article or Email Reply features) so that they will use the server-configured "Default 'From' Address" setting by default. It is unlikely that SMTP servers will accept an outgoing email message if its From: header doesn't match the email address associated with the email account being used to send the message. (Server86291)

• Fixed some issues with section table column widths/layout. (Server85941 / Server85945)

• Fixed a minor bug that could prevent the classic email notifier from being able to send a message. This classic capability is not generally maintained, and is definitely not recommended or fully supported, but may still be in use in some TeamPage deployments. (Server86255)

• Fixed a minor layout problem causing top-level navigation tabs to float up by a few pixels when certain locales (e.g., Japanese) are used. (Proteus14864)

• Fixed an accessibility/usability issue with the colors used in email notification messages to highlight the latest activity in a discussion thread; and added configuration settings for being able to configure those colors to the "Expand Flat Threat" plug-in. (Server82488)

• Fixed a minor issue in the HTML page that is loaded following successful completion of the TeamPage installer. Administrators will no longer see error messages in the log related to a failure to load place-holder image used in this page. (Server86228)

• Fixed a bug that prevented the initial status of the Status field for a project, milestone and task forms from being correctly initialized to Open when using the "Add" button for a Project Management section that refers to a template entry whose status is Closed. Now, as long as the section definition's "Show Completed Items" checkbox is not checked, its "Add" button for that section will open a form that has the Status field set to "Open" or the To Do / Done checkbox unchecked. (Server85776)

• Fixed a bug that prevented statistics related to certain data caches from being included in TeamPage's statistics reports and statistics logs. (Server86827)

• Fixed a bug affecting Firefox only that prevented certain actions, such as the Email Articles and Export actions, from being launched via the icon links that appear at the top right corner of most pages. (Proteus14906)

• Fixed some issues that could cause TeamPage not to pause before shutdown when certain types of "uninterruptible" operations are underway. In rare cases, these issues could lead to truncation or loss of certain important (although replaceable) auxiliary data, including search engine document index tracking information. (Server86811 / Server86812)

• Fixed some minor bugs with the way that external search engine document indexing status is tracked. The main consequence of these issues would be that in many cases when documents could not be successfully indexed, they would still end up being grouped in the "Indexed" status category, rather than in the "Error" status category. (Server80730)

• Fixed the type-ahead completion suggestions offered in the child editor dialog. Due to a regression introduced in a previous version of TeamPage, the suggestions offered would cover only possible target entries in one space. Suggestions now reflect all matching results. Additionally, suggestions are now sorted according to relevance for the context, like type-ahead completion suggestions in other areas of TeamPage. (Proteus14915)

• Fixed a longstanding harmless but annoying issue related to TeamPage's integration with the SLF4J logging library that could cause a warning to be printed on the console in some cases when using the a premium search module with TeamPage. (Solr305)

• Fixed an issue with the diagnostic "Entry Properties Views" plug-in which could cause warnings to be printed on the console when starting up with the plug-in installed and enabled, but without the "Classic Traction TeamPage Components" plug-in installed and enabled. (Server87009)

• Fixed a bug related to the handling of authentication failure and other errors that could occur during a request to update a "live activity" status display. Live activity is most commonly used to display information in an entry form about what related activities other users are currently performing, such as the case of another user editing the same entry, or commenting on another entry in the same discussion thread. Previously, when an authentication failure or other error occurred, there would be no feedback for the user to know about that error. Now, authentication fails, the user will be told that they need to log in to continue what they're working on; and for other errors, a suitable indication will be displayed so that the user knows that there has been some problem. (Authentication failures are unlikely in this scenario since TeamPage uses web sockets to force other active browser sessions to be interrupted if a user logs out of TeamPage in that browser, but it is possible in some situations.) (Server86957)

• Fixed a bug that prevented the "Delete" button from working when attempting to remove an existing journal configuration from the list in the Journal Setup > Choose Existing Journal page. (Server86998)

For Developers



Cleaner and Clearer Associations between Custom Entry Type and com.traction.sdk.EntryClass



The association between custom entry types and EntryClasses has not always been clear. Any particular custom entry type could always also be used to refer to a corresponding EntryClass. But many customizations are built around models including EntryClasses that are "sub types" of other EntryClasses -- e.g., representing a special kind of task. In order for this to work properly, the custom entry type of one of these entries had to be set to that of the "super type", and the _class entry property had to be set to the specific sub type. Although this was possible, it was redundant, since the "sub type" logically requires its entries custom entry types to be set to that of the super type, meaning that this had to be done manually in the FormFactory configuration. This was redundant, error-prone and confusing.

As of this release, however, customizers can manage the custom entry type as part of the entry class. Here is a simple example, for an EntryClass named "foo" that always goes with a custom entry type of "bar":

# plugins/com.example.foo/config/entry/classes/foo.properties
 
__inherits=_default
 
...
 
custom_entry_type=bar


And here's a simple example of how to make a special type of task:

# plugins/com.traction.foo/config/entry/classes/foo.properties
 
__inherits=task
 
prefer_custom_entry_type=false
custom_entry_type=task


Even better, for a form that creates entries belonging to a particular EntryClass, it is no longer necessary to specify the EntrySource property indicating what custom entry type is desired. Customizers can instead specify just the EntryClass by name, e.g.:

# plugins/com.traction.foo/config/data/forms/foo.properties
 
sources=entry
 
entry_class=foo


Existing FormFactory configurations that define the entry_custom_type and/or the entry_class will continue to work as ever. (If no EntryClass exists with the requested combination of custom entry type and EntryClass configuration name, the server will temporarily create one and apply its custom type and _class= entry property, which is equivalent to the existing behavior.)

This is particularly aimed at making it easier to create entries that belong to special types of tasks, milestones, goals, and events. (Server84386)

com.traction.sdk.props Package



In order to simplify interaction with the com.traction.sdk.props interfaces and classes that define a simple read/write model for property name-value pairs, such as GetProperty and PropStore, the interface and class hierarchy for those types has been substantially revised. There should be no loss of functionality, but many interfaces, classes, and methods have been renamed, removed, and otherwise changed.

Two important basic types are still GetProperty and PutProperty. But a new GetPutProperty interface extends both, and PropStore extends GetPutProperty.

GetObject/ObjectStore, ReadOnlyPropStore and ReadWritePropStore have all been removed. The GetObject functionality is now built into GetProperty; the ObjectStore functionality is built into GetProperty/PropStore; ReadOnlyPropStore can now be effectively replaced with GetProperty; and ReadWritePropStore can now be replaced with GetPutProperty. PropStore is now truly reserved for situations in which the holder of the object can commit changes.

All four main basic types -- GetProperty, PutProperty, GetPutProperty and PropStore -- descend from the basic root interface PropertyCollection, in which the following methods are defined:

public PropertyCollection getNamespace(String space);
 
public PropertyCollection getNamespace(String space, char sep);
 
public PropertyCollection getPrefix(String prefix);
 
public PropertyCollection getPrefix(String prefix, char sep);


Each of the four basic types overrides those declarations with default implementations that return an instance of their own type of object rather than PropertyCollection (i.e., the subtype methods are covariant) which means that we now advertise all these methods uniformly across all these property management types, and that we're sure to return an instance if the same type as the receiver.

Likewise, GetProperty now declares several other methods, with default implementations, most notably the following:

public String getLocalProperty(String name);
 
public GetProperty getDefaults();
 
public GetProperty getLocals();
 
public GetProperty withDefaults(GetProperty defaults);
 
public GetProperty withCache();
 
public GetProperty withCache(PropertyCache cache);


This keeps the same new pattern of advertising these useful methods uniformly across all types that support them.

As much as possible, features such as object caching, name "subspaces" and "prefixes", etc., are implemented in using the decorator pattern, with single purpose interfaces serving to modify a single behavior of the delegate at a time. The PropertyCache interface, for example, factors out the implementation strategy for object caching used for GetProperty's <T> T getProperty(String name) method, and CachingGetProperty provides a GetProperty that uses a PropertyCache to decorate a GetProperty.

These changes are aimed at simplifying the interaction with TeamPage's public SDK properties APIs, and ensuring that methods across the various basic types have, as much as possible, identical names corresponding to identical semantic purposes; and that if operations do not apply to a particular type, no corresponding method is offered.

For developers who are interested in a more careful examination of these changes, please download the TeamPage source code and look at the .java files in the src/com/traction/sdk/props directory.

Migration from joda-time to Java 8 java.time



The venerable joda-time library has been removed from TeamPage. joda-time was superseded by Java 8's java.time package, which was developed in part by the creator of joda-time. All TeamPage code that used joda-time now uses java.time classes and interfaces. This includes, for example, many helper methods in com.traction.sdk.util.DateUtil.

TeamPage does include the threeten-extra library, which was also developed in part by the creator of joda-time. It fills some "gaps", by including some functionality that existed in joda-time, but which did not "make the cut" for Java 8's java.time APIs.

If you have any TeamPage plug-ins that use joda-time, you are encouraged to update it to use the equivalent java.time and threeten-extra APIs instead. If your TeamPage installation includes such a plug-in, but there's some reason you can't perform such a migration concurrent with your upgrade to this version, including your own copy of the joda-time JAR file in your plug-in's lib folder will provide a workaround until you can.

New Proteus Skin Javascript Functions



Display a Message in Proteus's Status Bar



This function has been added to the Proteus skin's Javascript API to support showing a message in the Proteus skin's footer status bar:

Proteus.showStatusMessage(message, automaticallyHide)


Execute a Custom Label (Tag) Action



Custom label actions are not a frequently used feature of TeamPage, but they are used in many cases, including behind the scenes to implement the checkbox control that changes the status of a task from open to complete by removing the "to do" tag and adding the "done" tag from the task's containing space. The following function has been added

Proteus.processCustomLabelAction(customLabelActionId, tractionIdSpec, yourCallbackFunction)


The action ID is generally retrieved in SDL via the "customlabelaction.uniqueid" tag. It is easy to iterate over all available actions in SDL using the <customlabelactions> tag; see also the "itemcheckbox" function in src/com/traction/sdl/gwtrpc/shared.sdl to see how to get the unique ID for either the "To Do" or "Done" action from an SDL variable that is put into scope by the item.checkbox SDL tag (intended to be used with respect to the title item of any entry carrying a "to do" or "done" tag).

The Traction ID specification should be a string in the usual form, such as "FooBar123".

Your callback function, if provided, will be invoked on completion of the operation, with a value of true being passed if the operation completed successfully, and a value of false being passed otherwise.

Calendar API Functions



And the Proteus.Calendar object has been added to export the following functions related to calendar view operations:

// Move the start time of an event, preserving its length
Proteus.Calendar.moveEvent(fqidSpec, newStartTimeInMillisecondsSpec, callbackFunction)
 
// Change the end date/time of an event
Proteus.Calendar.changeEventEnd(fqidSpec, newEndTimeInMillisecondsSpec, callbackFunction)
 
// Set the properties of an event on the calendar
Proteus.Calendar.setEventProperties(fqidSpec, newStartTimeInMillisecondsSpec, newEndTimeInMillisecondsSpec, allDay, callbackFunction)
 
// Show the event details dialog for the target entry
Proteus.Calendar.showEventDetails(fqidSpec)


These expose the corresponding functionality offered by the TeamPage GWT "View" module's SdkService methods of the same names.

Note that the specifications for the date/time values must be expressed in milliseconds from the start of the epoch, and must be adjusted (when necessary) to take into account the user's time zone. This makes them compatible with the type "v" (event) regions that appear in TeamPage's calendar views.

One other special Calendar function is showSdate:

Proteus.Calendar.showSdate(newSdateSpec)


This function doesn't exist, but may be defined by a developer to override the default handling of the "refresh calendar view" behavior that occurs when an entry is created or edited on a calendar. The default behavior is to either refresh the current view, if the new or modified entry's start date is covered by the current calendar view, or to navigate to the month calendar view that contains the start date. Developers who are working on special behaviors for calendar views and need to override this default behavior should define the Proteus.Calendar.showSdate function to implement their preferred handling.

Grouped Button Styles for Proteus



The Proteus skin now natively includes styles for grouped buttons.

Default (same as the Light version)

<div class="button-group">
  <a href="#" class="button">Button</a>
  <a href="#" class="button active">Active</a>
  <a href="#" class="button selected">Selected</a>
  <a href="#" class="button disabled">Disabled</a>
  <button type="button" value="test 3">Button</button>
</div>


Light Version (Set the "group-button-light" class)

<div class="button-group-light">
  <a href="#" class="button">Button</a>
  <a href="#" class="button active">Active</a>
  <a href="#" class="button selected">Selected</a>
  <a href="#" class="button disabled">Disabled</a>
  <button type="button" value="test 3">Button</button>
</div>




Dark Version (Set the "group-button-dark" class)

<div class="button-group-dark">
  <a href="#" class="button">Button</a>
  <a href="#" class="button active">Active</a>
  <a href="#" class="button selected">Selected</a>
  <a href="#" class="button disabled">Disabled</a>
  <button type="button" value="test 3">Button</button>
</div>




Colorful Setting Panel Styling



For settings dialogs, such as those used to manage user or space settings for a plug-in, we now offer more colorful and interesting styling and layout option. Just call the setting-pane function in com.traction.sdl.admin.settings.

Examples of Colorful Panels

<#setting-panel class="primary" title="Primary" icon="check">
  This is a test.
</#setting-panel>


Use class= to specify the color of the panel. The "icon" parameter specifies the icon (the font-awesome mnemonic name) displayed in the heading.

To embed your settings inside such a panel, use the "setting-row" function, passing the names of the desired settings like this:

<#setting-panel class="default" title="Button Text for Basic Views" icon="check">
  <#setting-row settings="setting_name0" width="full" />
  <#setting-row settings="setting_name1,setting_name2" width="half" full_width_textbox="setting_name1,setting_name2" />
</#setting-panel>


If the width= parameter is "half", the width of the column will occupy half of the row.

If the full_width_textbox= parameter is set and the type of the corresponding <input> is "text", its width will be 100%.

Other Changes



• The com.traction.sdk.util.log.debug.DebugTimingTimer class's getInstance factory constructor method now accepts a Supplier<String> rather than a Function<Void,String>. (Server85018)

• The com.traction.sdk.util.cache.GuavaCacheStats.CacheStatsProvider interface has been removed, and any uses have been replaced with Supplier<com.google.common.cache.CacheStats>. (Server84901)

• TeamPage's configuration loading system now supports loading configurations for event listeners and daemons from .json configuration collections, not just from individual .properties files. (Server82947 / Server84926)

• Event listener configurations now set their NotifyUsers implementation as part of the setConfiguration method rather than as a post-processing step. If you have a plug-in with an event listener that has a custom tsi.config.ListenerConfig, you can now implement custom validation of an associated com.traction.sdk.event.NotifyUsers implementation. (Server78265)

• The html.css, html.js and html.img tags now support protocol-relative URLs for including references to static Javascript, CSS and image resources. (Fully qualified or protocol-relative URLs should generally only be used to include resources located on other servers -- i.e., not on the TeamPage server.)

• Fixed some issues that prevented custom default values from being used in the Email Reply form's "To" field (and, in certain situations, possibly some recipient fields). (Proteus14594)

• The user plug-in settings dialog no longer advertises support for settings belonging to the "cookie" setting type. (This dialog never supported this type of setting.) (Server85071)

• The transform.html2plaintext SDL tag has been added to facilitate transformation of HTML document fragments into either plain text, or plain text with entity-encoded runs left alone (and/or with entity-encoding being applied to tag delimiters and ampersands if unencoded tag delimiters are present). The withEntities= attribute may be specified with a value of either "true" or "false" (defaulting to "true") to specify whether the entity-encoding behavior is required, or whether the resulting text should really be completely text-only. (These behaviors correspond to the recently added "cleanhtml2text" and "cleanhtml2text_entities" com.traction.sdk.util.Transformers, which use the htmlcleaner package to create clean text-only renderings from HTML content.) Developers should consider using this anywhere that they were previously using the <transform> SDL tag with name=plaintext_xf. (Server86035)

• The obsolete and redundant xml.transform tag has been retired. If you're still using it in your SDL code, please replace it with the equivalent <transform> tag.

• The comment_target, task_target, event_target and related_target base form Field configurations have been added parallel to those respective EntryFields. These can be useful if you need to be able to use a form field to edit or remove one of those specific types of relationships. (Proteus14848)

• The new "entry" FieldType configuration can be used for form Field configurations to set up a single select field that uses a combo-box style control to let a user choose an entry tag for a custom type of entry. (This is a similar type of control to the one used for space, project and milestone fields.) Specify the desired type of entry in the entry_type= and index_entry_types= field configuration properties. (Proteus14914)

• The utility class com.traction.sdk.util.ColumnListSuperCsvWriter has been added to serve as a wrapper for org.supercsv.io.CsvListWriter. It currently uses only the most common options (org.supercsv.prefs.CsvPreference.STANDARD_PREFERENCE). (Server86980)

• Updated to SLF4J version 1.7.25. (Server87012)

• When a Javascript error occurs in the scope of a normal page and is reported in the in-page status bar that appears near the bottom of the page (instead of raising a feedback dialog), developers can view the browser's web error console to see the same full stack trace they would see in the feedback dialog. (Proteus14978)



Attachments:
colorful_panels.png
light.png
dark.png
basic_month.png
tp6212.png
F50A8018-3CF0-4E7C-A3A4-40C4BD6901C5.jpeg
Related Articles
Article: Customer5011 (permalink)
Categories: :Doc:changelog, :Doc:r62
Date: November 15, 2017; 2:15:14 PM EST
Author Name: Dave Shepperton
Author ID: shep