Appboard/2.4/builder/widgets/actions/write static value: Difference between revisions
imported>Mike.berman No edit summary |
imported>Cmace (action filtering based on data source, not data collection) |
||
| (7 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE: | {{DISPLAYTITLE:Write Static Value}} | ||
The "Write Static Value" | [[Category:AppBoard 2.4]] | ||
The "Write Static Value" action provides a way to write a static value back to the data source based on the selected item. This action only works if the data source supports updates, and is configured appropriately if required. | |||
A simple example and use of this action would be to set an acknowledged flag on a selected ticket in a table widget. In this case either a database table or query would be configured to retrieve the list of tickets, a widget configured to show the tickets, and the action created to set a specific field in order to mark it as acknowledged (e.g. the setting the "Acknowledged" field to "Yes"). See the example use case further down this page. | |||
As with any widget action it's possible to configure these in context, multiple actions if it's desired to set multiple fields, and action menus can be built if different operations need to be presented to the end-user. | |||
=== Supporting Data Source Types === | |||
{|class="wikitable" | |||
!Data Source Type | |||
!Details | |||
|- | |||
|CSV file/dir | |||
|no configuration required on data source | |||
|- | |||
|Database Table | |||
|automatic for entities with primary keys defined | |||
|- | |||
|Database Query | |||
|each entity (query) needs a specific SQL update statement defined | |||
|} | |||
| Line 36: | Line 39: | ||
### Click <b>Add Rule</b> to create one or more rules that indicate what data should trigger the Action, when selected. | ### Click <b>Add Rule</b> to create one or more rules that indicate what data should trigger the Action, when selected. | ||
### Click <b>Close</b> to save the Filter settings. | ### Click <b>Close</b> to save the Filter settings. | ||
## Select the Data | ## Select the Data Source name. When the Widget is run, selection of data in this Data Source will trigger the Action. | ||
# Enter the following information: | # Enter the following information: | ||
## <b>Field Name</b>: Select the name of the field for the user-selected record that AppBoard will update. | ## <b>Field Name</b>: Select the name of the field for the user-selected record that AppBoard will update. | ||
| Line 44: | Line 47: | ||
== Sample Use Case == | == Sample Use Case == | ||
Suppose a | Suppose ticket data is retrieved via a database query to a ticketing system. The query could be something like this: | ||
<pre> | |||
select TicketID, CustomerID, `IP Address`, Error, Acknowledged from TicketTable | |||
</pre> | |||
And the '''raw''' data returned from the query: | |||
{| class="wikitable" | {|class="wikitable" | ||
|- | |- | ||
! | ! TicketID | ||
! | ! CustomerID | ||
! | ! IP Address | ||
! | ! Error | ||
! Acknowledged | |||
|- | |- | ||
| 41211 | |||
| 0001 | | 0001 | ||
| 172.21.38.220 | | 172.21.38.220 | ||
| Line 60: | Line 69: | ||
| No | | No | ||
|- | |- | ||
| 41212 | |||
| 0001 | | 0001 | ||
| 172.21.38.226 | | 172.21.38.226 | ||
| Line 65: | Line 75: | ||
| No | | No | ||
|- | |- | ||
| 41213 | |||
| 0002 | | 0002 | ||
| 172.26.11.101 | | 172.26.11.101 | ||
| Line 70: | Line 81: | ||
| No | | No | ||
|- | |- | ||
| | | 41214 | ||
| 0002 | |||
| 172.21.38.105 | |||
| | | License Warning | ||
| ''Yes'' | |||
|- | |- | ||
| | | 41215 | ||
| 0002 | |||
| 172.21.38.313 | |||
| | | Temperature too high | ||
| ''Yes'' | |||
|} | |} | ||
Within AppBoard the administrator creates a Table widget driven by this data but also configures a client side filter to filter out rows that have already been acknowledged, saving the end-user some time by only showing the outstanding tickets. Therefore the sub-set of tickets the end-user sees would be: | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! | ! TicketID | ||
! | ! CustomerID | ||
! | ! IP Address | ||
! | ! Error | ||
! Acknowledged | |||
|- | |- | ||
| 41211 | |||
| 0001 | | 0001 | ||
| 172.21.38.220 | | 172.21.38.220 | ||
| Line 98: | Line 111: | ||
| No | | No | ||
|- | |- | ||
| 41212 | |||
| 0001 | | 0001 | ||
| 172.21.38.226 | | 172.21.38.226 | ||
| Line 103: | Line 117: | ||
| No | | No | ||
|- | |- | ||
| 41213 | |||
| 0002 | | 0002 | ||
| 172.26.11.101 | | 172.26.11.101 | ||
| Line 110: | Line 125: | ||
Finally, the administrator configures a Write Static Value on the table widget and sets the Field Name to '''Acknowledged''' and the Value to "Yes". When this happens the field is updated back to the database and all end-users will no longer see the ticket on next data collection refresh as it will be filtered by the client side filter. | |||
In order for this to work it would also be necessary to configure an Update Statement on the database query. Note the '':fieldName'' is substituted by the fields from the selected row or the static value of the action if that particular field is the configured '''Field Name'''. | |||
<pre>update TicketTable set Acknowledged=:Acknowledged where TicketID=:TicketID</pre> | |||
Latest revision as of 18:53, 1 May 2014
The "Write Static Value" action provides a way to write a static value back to the data source based on the selected item. This action only works if the data source supports updates, and is configured appropriately if required.
A simple example and use of this action would be to set an acknowledged flag on a selected ticket in a table widget. In this case either a database table or query would be configured to retrieve the list of tickets, a widget configured to show the tickets, and the action created to set a specific field in order to mark it as acknowledged (e.g. the setting the "Acknowledged" field to "Yes"). See the example use case further down this page.
As with any widget action it's possible to configure these in context, multiple actions if it's desired to set multiple fields, and action menus can be built if different operations need to be presented to the end-user.
Supporting Data Source Types
| Data Source Type | Details |
|---|---|
| CSV file/dir | no configuration required on data source |
| Database Table | automatic for entities with primary keys defined |
| Database Query | each entity (query) needs a specific SQL update statement defined |
How To Create a Write Static Value Action
For instructions on adding an Action to a Widget, see the general instructions in How To Create an Action in a Widget.
How To Configure a Write Static Value Action
Perform the following steps to configure the "Write Static Value" Action for a Widget:
- Follow the instructions above to create the Action in the Widget Actions panel.
- Name: Enter a name for this Action. For convenience, a default name is provided. The Name is not used anywhere else in AppBoard, and only displayed on this configuration page.
- On selection of:
- Select "any" or "specific" for the type of data selection by the User that will trigger the Action. When selecting "specific", perform the following additional steps:
- Click the Filter button. The Filter Editor is displayed.
- Click Add Rule to create one or more rules that indicate what data should trigger the Action, when selected.
- Click Close to save the Filter settings.
- Select the Data Source name. When the Widget is run, selection of data in this Data Source will trigger the Action.
- Select "any" or "specific" for the type of data selection by the User that will trigger the Action. When selecting "specific", perform the following additional steps:
- Enter the following information:
- Field Name: Select the name of the field for the user-selected record that AppBoard will update.
- Value: Enter the value that AppBoard will write for the indicated field in the user-selected record.
Sample Use Case
Suppose ticket data is retrieved via a database query to a ticketing system. The query could be something like this:
select TicketID, CustomerID, `IP Address`, Error, Acknowledged from TicketTable
And the raw data returned from the query:
| TicketID | CustomerID | IP Address | Error | Acknowledged |
|---|---|---|---|---|
| 41211 | 0001 | 172.21.38.220 | License Expired | No |
| 41212 | 0001 | 172.21.38.226 | Server Not Responding | No |
| 41213 | 0002 | 172.26.11.101 | Slow response time | No |
| 41214 | 0002 | 172.21.38.105 | License Warning | Yes |
| 41215 | 0002 | 172.21.38.313 | Temperature too high | Yes |
Within AppBoard the administrator creates a Table widget driven by this data but also configures a client side filter to filter out rows that have already been acknowledged, saving the end-user some time by only showing the outstanding tickets. Therefore the sub-set of tickets the end-user sees would be:
| TicketID | CustomerID | IP Address | Error | Acknowledged |
|---|---|---|---|---|
| 41211 | 0001 | 172.21.38.220 | License Expired | No |
| 41212 | 0001 | 172.21.38.226 | Server Not Responding | No |
| 41213 | 0002 | 172.26.11.101 | Slow response time | No |
Finally, the administrator configures a Write Static Value on the table widget and sets the Field Name to Acknowledged and the Value to "Yes". When this happens the field is updated back to the database and all end-users will no longer see the ticket on next data collection refresh as it will be filtered by the client side filter.
In order for this to work it would also be necessary to configure an Update Statement on the database query. Note the :fieldName is substituted by the fields from the selected row or the static value of the action if that particular field is the configured Field Name.
update TicketTable set Acknowledged=:Acknowledged where TicketID=:TicketID
