view tags that use name="CalendarControls" or name="TaskListControls" can now be set up to fire "filter-toggle-change" events instead of automatically performing navigation. (Proteus15552)
The following SDL illustrates how this could be done using the events= attribute on the appropriate SDL tag to request this behavior:
<sdl.function name="calendar-controls">
<gwt.rpc.view name="CalendarControls" events="true">
<gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_goal}" param="hp"></gwt.rpc.view>
<gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_milestone}" param="hm"></gwt.rpc.view>
<gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_task}" param="ht"></gwt.rpc.view>
<gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_event}" param="he"></gwt.rpc.view>
</gwt.rpc.view>
</sdl.function>
...
<sdl.function name="tasklist-controls-box">
<gwt.rpc.view name="TaskListControls" title="#{sidebox_tasklist_controls_title}">
<variable.boolean name="changeTags" default="true">
<gwt.rpc.property.set name="changeTagsRg" value="a#form&form=<variable.value name='changeTagsRg' index='form' default='mrecat' />&pageaction=<variable.value name='changeTagsRg' index='pageAction' default='feed' />&onsave=<variable.value name='changeTagsRg' index='onSave' default='rv' />" />
</variable.boolean>
<gwt.rpc.view key="ShowCompleted" events="true"></gwt.rpc.view>
<scope.haslist>
<gwt.rpc.property.set name="list-context" value="__list.name__" />
<gwt.rpc.property.set name="list-ordered" value="<list.ordered>t<else>f</list.ordered>" />
</scope.haslist>
</gwt.rpc.view>
</sdl.function>
Plug-in authors can use their own JavaScript to register to receive these events in order to customize the behavior of these controls for views involving calendars and task lists:
(function() {
function onFilterChange(data) {
// ...
}
function registerMyListeners() {
Proteus.addHandler("filter-toggle-change", onFilterChange);
}
Proteus.addHandler("load", registerMyListeners);
})();
The data passed to the event listener is structured as follows:
{
/**
* the name of the parameter
*/
"param": "hp",
/**
* the true/false state of the checkbox
*/
"checked": "true",
/**
* the value that the parameter should generally take
* when the checkbox is in that state
*/
"value": "f"
}
To query and modify these controls, the following functions may be used:
Proteus.FilterControls = {
/**
* Returns true if there is a filter with this parameter name.
*/
hasFilter: function(parameterName) {
},
/**
* Returns true if present and checked; false otherwise.
*/
isChecked: function(parameterName, defaultValue) {
},
/**
* Sets the state of the checkbox without firing an event.
* Returns true on success and false otherwise.
*/
setChecked: function(parameterName, checked) {
}
};
Other New Proteus Event Types
Some new types of events have been added to the Proteus skin JavaScript API. (Proteus15574)
Reference: SDK339
These are defined as follows:
- "auto-refresh-loading" and "auto-refresh-load" - These events are fired when there is an automatic refresh of the contents of a page. They are fired, respectively, whe the refresh is initiated and when the refresh completes successfully. These are similar to the "loading" and "load" events. Currently, they are only fired in Status Updates pages which do background cyclic automatic refreshes, but may later be fired in other similar cases. No argument is passed to the event listener, and the return value is ignored.
- "entry-update" - This event is fired when a single entry among many in a page (when not displayed as a comment) is updated in place. The argument passed to the event listener will be a map with a single entry, mapping the "rec" key to the specification for the Traction ID of the updated entry. The return value is ignored.
- "comment-insert" and "comment-update" - These events are fired, respectively when a newly posted comment is inserted into the page and when an existing comment has been updated. The argument passed to listeners for these events is a map with the following entries:
- "id" and "targetId" - respectively, the specifications for the Traction IDs of the newly posted or updated comment and that of the comment's target.
- "domId" and "targetDomId" - respectively, to the DOM IDs of the containers for the newly posted or updated comment and that of the comment's target.
- "comment-before-save" and "comment-save" - These events are fired when a comment is being saved from the inline comment form. The "comment-before-save" event is fired first, and the data passed to event listeners contains the current comment form state. Listeners may return false to prevent the comment save operation from proceeding. "comment-save" is fired when a new comment has been successfully saved from the inline comment form. (This will always be before the "comment-insert" event is fired.) The argument passed to listeners for the "comment-save" event is a map that contains the same entries as the one for the "comment-insert" and "comment-update" events.
Filtering for com.traction.sdk.token.ReferenceBucketEntryFields
Filtering using the built-in "Filter" menu for com.traction.sdk.token.ReferenceBucketEntryFields, which are driven by com.traction.sdk.data.ReferenceBuckets, now functions properly. It is now possible to support filtering for these EntryFields using a configuration like this:
# plugins/com.example.foobar/config/entry/fields/props/bar.properties
class=com.traction.sdk.token.ReferenceBucketEntryField
# Defined elsewhere in plugins/com.example.foobar/config/data/referencebuckets/bar.properties
reference_bucket=bar
filter_selectable=true
filter_group=baz
filter_order=5287
filter_display_name=Bar
filter_field_type=reference_bucket_select
Using the filter_field_type=reference_bucket_select allows the user to select one or more entries in the filter form so that they can use the "Any" search type to find matches for any of the selected entries.
Context Menu Customizations
The TR elements used to display each of TeamPage's custom context menu items now come with a class="cm-row-{item name]", e.g., class="cm-row-AddLabels" or class="cm-row-Copy" so that the layout or style of individual context menu items can be more easily customized, including hiding them using "display: none". (Server87476)
Article: Customer5091 (
permalink)
Categories: :Doc:changelog, :Doc:r62
Date: August 11, 2018; 2:52:00 AM Eastern Daylight Time
Author Name: Dave Shepperton
Author ID: shep
