sn-record-picker Helper, Part II

“If I had eight hours to chop down a tree, I’d spend six hours sharpening my ax.”
Abraham Lincoln

Now that we have all of the form fields and controls laid out on the page, the next order of business is to build the function that will use the form input to create the desired sn-record-picker. We have already specified an ng-submit function on the form, so all we have to do at this point is to actually create that function in the client-side script. This function is actually pretty vanilla stuff, and just takes the data entered on the screen and stitches it all together to form the resulting sn-record-picker tag.

$scope.createPicker = function() {
	var picker = '<sn-record-picker\n    table="' + "'";
	picker += c.data.table.value + "'";
	picker += '"\n    field="';
	picker += c.data.field;
	if (c.data.filter) {
		picker += '"\n    default-query="' + "'";
		picker += c.data.filter + "'";
	}
	picker += '"\n    display-field="' + "'";
	picker += c.data.displayField.value + "'";
	if (c.data.displayFields.value) {
		picker += '"\n    display-fields="' + "'";
		picker += c.data.displayFields.value + "'";
	}
	if (c.data.searchFields.value) {
		picker += '"\n    search-fields="' + "'";
		picker += c.data.searchFields.value + "'";
	}
	if (c.data.valueField.value) {
		picker += '"\n    value-field="' + "'";
		picker += c.data.valueField.value + "'";
	}
	if (c.data.multiple) {
		picker += '"\n    multiple="true"';
	}
	if (c.data.placeholder) {
		picker += '"\n    page-size="';
		picker += c.data.pageSize;
	}
	if (c.data.pageSize) {
		picker += '"\n    placeholder="';
		picker += c.data.placeholder;
	}
	c.data.generated = picker + '">\n</sn-record-picker>';
	c.data.ready = true;
	return false;
};

One of the last few things that happens in that script is to set c.data.ready to true. I set that variable up to control whether or not the rendered tag should appear on the screen. Altering any of the fields on the screen sets it to false, which hides the text box containing the generated code until you click on the button again. To make that work, I just added an ng-show to the enclosing DIV:

<div class="col-sm-12" ng-show="c.data.ready">
  <snh-form-field
    snh-model="c.data.generated"
    snh-name="generated"
    snh-label="Your sn-record-picker:"
    snh-type="textarea">
  </snh-form-field>
  <p><a href="javascript:void(0);" onclick="copyToClipboard();">Copy to clipboard</a></p>
</div>

The other thing that you will notice inside of that DIV is the Copy to clipboard link. That one uses a standard onclick rather than an ng-click, because that’s a DOM operation, which is outside the scope of the AngularJS controller. The referenced script, along with another DOM script that I use to set the height of that textarea, are placed in a script tag with the HTML.

<script>
function fixTextareaHeight() {
	var elem = document.getElementById('generated');
    elem.style.height = (elem.scrollHeight + 10)  + 'px';
}
function copyToClipboard() {
	var elem = document.getElementById('generated');
	elem.select();
	elem.setSelectionRange(0, 99999)
	document.execCommand('copy');
	alert("The following code was copied to the clipboard:\n\n" + elem.value);
}
</script>

Clicking on that Copy to clipboard link copies the code to the clipboard and also throws up an alert message to let you know what was copied.

Alert message after copying the code to the clipboard

The next thing on my list was to actually place the code on the page so that you could see it working. I tried a number of things to get that to work, including ng-bind, ng-bind-html, ng-bind-html-compile, and sc-bind-html-compile, but I could never get any of that to work, so I ultimately gave up on trying to use the actual generated code, and did the next best thing, which was to just set up a picker of my own using the selected options.

        <div class="col-sm-12" ng-show="c.data.ready">
          <snh-form-field
            snh-model="c.data.liveExample"
            snh-name="liveExample"
            snh-label="Live Example"
            snh-type="reference"
            snh-change="optionSelected()"
            placeholder="{{c.data.placeholder}}"
            table="c.data.table.value"
            display-field="c.data.displayField.value"
            display-fields="c.data.displayFields.value"
            value-field="c.data.valueField.value"
            search-fields="c.data.searchFields.value"
            default-query="c.data.filter">
          </snh-form-field>
        </div>

This approach allowed me to add a modal pop-up that showed the value of the item selected.

Modal pop-up indicating option selected

The code to make that happen is in the client-side controller:

$scope.optionSelected = function() {
	spModal.open({
		title: 'Selected Option',
		message: '<p>You selected  "<b>' + c.data.liveExample.value + '</b>"</p>',
		buttons: [
			{label: 'Close', primary: true}
		],
		size: 'sm'
	});
};

One other thing that I should mention is that the snh-form-field directive that I used in this example is not same as the last version that I had published. To support the multiple=true/false option, I needed a checkbox, and for some reason, I never included that in the list of many, many field types that included in that directive. I also had to tweak a few other things here and there, so it’s no longer the same. I should really release that separately in a future installment, but for now, I will just bundle it with everything else so that this will all work as intended.

I wrapped the whole thing in an snh-panel, just to provide the means to add some documentation on the sn-record-picker tag. I had visions of gathering up all of the documentation that I could find and assembling it all into a comprehensive help screen document, but that never happened. Still, the possibility is there with the integrated help infrastructure.

Pop-up widget help screen

I also added a sidebar menu item so that I could easily get to it within the main UI. It may be a Service Portal Widget under the hood, but it doesn’t really belong on the Service Portal. It’s a development tool, so I added the menu item so that it could live with all of the other development tools in the primary UI. If you want to take it for a spin yourself, here is an Update Set.

Update: There is a better (corrected) version here.

sn-record-picker Helper

“You are never too old to set another goal or to dream a new dream.”
Les Brown

One of the cool little doodads packaged with ServiceNow is the sn-record-picker. On the Service Portal side of the house, the sn-record-picker gives you a type-ahead search of any ServiceNow table with a considerable number of flexible features. I use it quite a lot, but not often enough to intuitively recall every configuration option available. Although this is a widely used facet of the Service Portal platform, the documentation for this component is relatively sparse, which is uncharacteristic for ServiceNow. A number of individuals have attempted to provide their own version of the needed documentation, and I have even considered doing that myself, but that only solves half of my problem. The other thing that I can never remember is the names of tables and fields, which you need to know whenever you set up an sn-record-picker. What I would really like is some kind of on-line wizard that stepped me through all of the necessary parts and pieces needed to build the sn-record-picker that I need at the time, and it would be even better if had the ability to go ahead and build it so that I could see it live once I completed all of the steps needed to construct it. I looked around for such a tool and couldn’t find one, so I decided to build it myself.

Here’s the idea: create a Service Portal widget that has input fields for all of the configuration options along with some kind of Build It button that would both create the sn-record-picker code based on the user input, and put the code live on the page so that you could see it in action. It seemed like it would be quite useful when it was finished, and fairly simple to put together. After all, how hard could it be?

The first thing that you need for an sn-record-picker is a Table. Since we are building a widget, the easiest way to select a Table from a list would be to use an sn-record-picker. So, it would seem appropriate that the first field on our new sn-record-picker tool would, in fact, be an sn-record-picker. Technically, I will be using an snh-form-field in practice, but under the hood, there is still an sn-record-picker doing all of the heavy lifting.

<snh-panel title="'${sn-record-picker Tool}'" class="panel-primary">
  <form id="form1" name="form1" ng-submit="createPicker();" novalidate>
    <div class="row">
       <div class="col-sm-12">
        <snh-form-field
          snh-model="c.data.table"
          snh-name="table"
          snh-type="reference"
          snh-help="Select the ServiceNow database table that will contain the options from which the user will select their choice or choices."
          snh-change="buildFieldFilter();"
          snh-required="true"
          placeholder="Choose a Table"
          table="'sys_db_object'"
          display-field="'label'"
          display-fields="'name'"
          value-field="'name'"
          search-fields="'name,label'">
        </snh-form-field>
      </div>
    </div>
  </form>
</snh-panel>

I had to look up the name of the ServiceNow table of tables, because I couldn’t remember what it was (sys_db_object), but that may just be because I never knew what it was in the first place. I also had to look up the column names for all of the fields that I needed. I should be able to avoid all of that effort once all of this comes together and I can use my new tool, which of course, is whole point of this exercise. Configuring the table selector is enough to get things started, though, and I don’t like to do too much without giving things a whirl, so let’s throw this widget onto a portal page and hit the Try It! button.

sn-record-picker tool with table selector

Once you have the table selected, you can start selecting from the fields defined for that table. Once again, this is an excellent use for an sn-record-picker, but for the table fields we will need to filter the choices based on the table selected. To do that, we need to build an encoded query for a filter. On the client-side script, we can create a function to do just that:

$scope.buildFieldFilter = function() {
	c.data.fieldFilter = 'elementISNOTEMPTY^name=' + c.data.table.value;
};

Now that we have our filter defined, we can reference it in the next picker that we will need, the Primary Display field:

<snh-form-field
  snh-model="c.data.displayField"
  snh-name="displayField"
  snh-label="Primary Display Field"
  snh-type="reference"
  snh-help="Select the primary display field."
  snh-required="true"
  snh-change="c.data.ready=false"
  placeholder="Choose a Field"
  table="'sys_dictionary'"
  display-field="'column_label'"
  display-fields="'element'"
  value-field="'element'"
  search-fields="'column_label,element'"
  default-query="c.data.fieldFilter">
</snh-form-field>

The default-query attribute of the Display Field sn-record-picker is set to c.data.fieldFilter, which is the variable that contains the value that is recalculated every time a new selection is made on the Table sn-record-picker. Whenever you select a different table, the filter is updated and then the list of available options for the Display Field selector changes to just those fields found on the selected table. This technique will be utilized for the Primary Display Field, the Additional Display Fields, the Search Field, and the Value Field.

In addition to the basic table and field attributes, there are also a number of other attributes that need to be included in the tool as well. I’m not even sure that I know all of the possible attributes that might be available, but my thought is that I will add all of the ones that I know about and then toss the others in when I learn about them. It turns out that there a quite a few, though, and after putting them all in with their associated help information, it made my page long and narrow, and put the button and results way, way down at the bottom of the page. I didn’t really like that, so I decided to split the page into two columns, and to hide any optional parameters unless needed. That format turned out to be much better that what I had originally; I like it much better.

Picker tool split into two columns

To temporarily hide the optional fields, I added an anchor tag with an ng-click above the form field, and gave both the anchor tag and the form field ng-show attributes based on the same boolean variable so that either one or the other would appear on the page.

<div class="col-sm-12" ng-show="c.data.table.value > ''">
  <p><a href="javascript:void(0)" ng-click="c.data.showFilter = true;" ng-show="!c.data.showFilter">Add an optional query filter</a></p>
  <snh-form-field
    ng-show="c.data.showFilter"
    snh-model="c.data.filter"
    snh-name="filter"
    snh-help="To limit the records retrieved from the table, enter an optional Encoded Query"
    placeholder="Enter a valid Encoded Query"
    snh-change="c.data.ready=false">
  </snh-form-field>
</div>

Now that I have configured all of the form fields for all of the attributes, the next thing to do will be to build the code that turns the user’s input into an actual sn-record-picker, and then makes it available for copy/paste operations, and hopefully, to try out right there on the wizard form. That’s actually quite a bit, so I think I will save all of that for a future installment.

Generic Feedback Widget, Part X

When I added the User Rating Scorecard to my Generic Feedback Widget, I only wanted to show it when appropriate, so I added an ng-show attribute to the snh-rating element:

<snh-rating ng-show="data.includeRating" snh-values="data.ratingValues"></snh-rating>

I did the same thing to the snh-form-field element for the rating entry for the very same reason:

<snh-form-field
       ng-show="data.includeRating"
       snh-model="data.rating"
       snh-name="rating"
       snh-type="rating"
       snh-label="Rate this {{data.tableLabel}}"/>

Providing a rating and viewing the cumulative results of ratings was something that I wanted to be optional, as including a rating in feedback is not always appropriate depending on the use case. To populate the data.includeRating variable with the desired alternative, I created a widget option, which I defined with the following JSON option schema:

[{
    "hint": "Set to TRUE if you want to include a rating with the text feedback",
    "name": "include_rating",
    "default_value": "false",
    "label": "Include Rating?",
    "type": "boolean"
}]

Once the option schema has been established, editing the widget instance in the Service Portal Page Designer will pop open a modal dialog where you can check a box to indicate that you would like ratings to be included for this instance of the widget.

Option dialog in Service Portal Page Designer

In the server side script, I look for this option and use it to determine the value of the data.includeRating variable.

data.includeRating = false;
if (options && options.include_rating) {
	data.includeRating = true;
}

This makes the widget a little more flexible, as you can check the box for one circumstance and leave it unchecked (the default) for others. Checking the box will get you the rating score card, user ratings under each user comment heading, and the ability to rate the item when you provide feedback. Without the box checked, all of those items are removed from view.

Generic Feedback Widget, Part IX

“There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves.”
Will Rogers

Now that we have the Script Include put to bed, the next thing that I need to do to wrap up this little project is to update the widget. I need to add the code that displays a commenter’s rating, and I have also decided to replace the little comment icon next to each comment with the commenter’s avatar. Since ServiceNow already has a nice HTML tag set up for that purpose, all of that turned out to be a fairly simple reorganization of the existing HTML:

<div ng-repeat="item in data.feedback">
  <div class="snc-kb-comment-by" style="margin-top: 10px;">
    <sn-avatar primary="item.userSysId" class="avatar" show-presence="true" enable-context-menu="false" style="margin: 5px; float: left;"></sn-avatar>
    <span class="snc-kb-comment-by-title">
      Posted by <a class="snc-kb-comment-by-user" href="?id=user_profile&table=sys_user&sys_id={{item.userSysId}}">{{item.userName}}</a>
      <span class="snc-kb-comment-by-title">{{item.dateTime}}</span>
      <br/>{{item.rating}}
    </span>
  </div>
  <div style="clear: both;"></div>
  <div>
    <span class="snc-kb-comment-by-text" ng-bind-html="item.comment"></span>
  </div>
</div>

To fetch and format the rating, I added a new function to the server side Javascript:

function formatRating(profile) {
	var rating = '';
	var score = feedbackUtils.currentUserRating(data.table, data.sys_id, profile);
	for (var i=0; i<score; i++) {
		rating += '★';
	}
	return rating;
}

Putting it all together, the final result turns out a page that looks like this:

Formatted feedback with individual ratings and user avatars

… and if you want to see the breakdown of individual vote tallies, you can click on the Show Breakdown option and see this:

User feedback with rating breakdown displayed

I’m still not sure if it would be better to put the new comment input box ahead of the comment history rather than at the end, but I think I will leave things as they are for now. I’m sure that I will eventually come up with some other additions or corrections at some point, so I will put off any further thoughts of making any additional changes until that time. I can’t say that I have thoroughly tested every possible aspect of this process, but what I have spent a little time with all seems to working as it should. I think I will call this one done for today, and go ahead and publish a final(?) Update Set.

Generic Feedback Widget, Part VIII

“People rarely succeed unless they have fun in what they are doing.”
Dale Carnegie

Now that I have a way to display the cumulative rating to date, I need to work that into the widget and also provide a way to display any rating that accompanies a comment. The cumulative rating is pretty simple now that we have our snh-rating tag:

<snh-rating ng-show="c.data.includeRating" snh-values="c.data.ratingValues"></snh-rating>

Of course, we have to gather up the rating values to pass to the rating tag, but we already worked that out last time, so that’s pretty simple as well:

if (data.includeRating) {
	data.ratingInfo = feedbackUtils.currentRating(data.table, data.sys_id);
	data.ratingValues = data.ratingInfo.join(',');
}

That should take care of the overall rating. Now we just have to add the individual ratings to each comment. One thing that my earlier version did not support was the one person/one vote rule, which prevents a single individual from stuffing the ballot box and skewing the results. To enforce that approach, and also to support fetching a user’s existing vote, I added a function to my SnhFeedbackUtils Script Include to go out and get any existing vote for a table, sys_id, and profile combination:

fetchUserRating: function(table, sys_id, profile) {
	var response = null;
	var pollGR = new GlideRecord('live_poll');
	var castGR = new GlideRecord('live_poll_cast');
	if (pollGR.get('question', table + ':' + sys_id + ' Rating')) {
		castGR.addQuery('poll', pollGR.getUniqueValue());
		castGR.addQuery('profile', profile);
		castGR.query();
		if (castGR.next()) {
			response = castGR;
		}
	}
	return response;
},

The first place that I used this new function was in another new function that I created to fetch the current user’s existing rating:

currentUserRating: function(table, sys_id, profile) {
	var rating = 0;
	var castGR = this.fetchUserRating(table, sys_id, profile);
	if (castGR) {
		rating = parseInt(castGR.getValue('option.order'));
	}
	return rating;
},

The other place that I used it was when I modified the postRating function to update any existing vote rather than adding a second vote on the same item for the same person:

postRating: function(table, sys_id, rating) {
	if (rating > 0 && rating < 6) {
		var pollGR = new GlideRecord('live_poll');
		var optGR = new GlideRecord('live_poll_option');
		var castGR = new GlideRecord('live_poll_cast');
		if (!pollGR.get('question', table + ':' + sys_id + ' Rating')) {
			pollGR.initialize();
			pollGR.question = table + ':' + sys_id + ' Rating';
			pollGR.insert();
			for (var opt=1; opt<6; opt++) {
				optGR.initialize();
				optGR.poll = pollGR.getUniqueValue();
				optGR.order = opt;
				optGR.name = opt + '';
				optGR.insert();
			}
		}
		optGR.initialize();
		optGR.addQuery('poll', pollGR.getUniqueValue());
		optGR.addQuery('order', rating);
		optGR.query();
		if (optGR.next()) {
			var profile = new GlideappLiveProfile().getID();
			var existing = this.fetchUserRating(table, sys_id, profile);
			if (existing) {
				castGR = existing;
				if (castGR.getValue('option') != optGR.getUniqueValue()) {
					castGR.option = optGR.getUniqueValue();
					castGR.update();
				}
			} else {
				castGR.initialize();
				castGR.poll = pollGR.getUniqueValue();
				castGR.profile = profile;
				castGR.option = optGR.getUniqueValue();
				castGR.insert();
			}
		}
	}
},

That takes care of the modifications for the SnhFeedbackUtils Script Include. Now I just need to modify the server side code on the widget to invoke the function on the Script Include to get the score, format the score into some kind of graphic display, and then finally, modify the HTML to include the rating graphic. That sounds like quite a bit of work, so I think we will leave all of that for next time!

Generic Feedback Widget, Part VII

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and starting on the first one.”
Mark Twain

One of the things that you often see in a feedback block is some kind of numerical or star rating in addition to the textual comments. I actually added that feature in the snh-form-field feedback type, but left it out when I set up the Generic Feedback Widget. The main reason that I left it out was to adhere to my general philosophy of keeping things simple in the beginning, but another driving factor was that the live_message table that I was using for the feedback did not have a column in which we could store the rating. Still, I always had in mind that I would circle back and address that later on at some point, and now, here we are at that very some point.

While nosing around for a place to put the rating without altering any of the existing tables, I came across the Live Poll feature. This feature utilizes three tables, one for the poll definition, one for the option definitions, and another for the actual votes cast. That was a little overkill for what I was looking for, but it would work. Live Polls are linked to a specific message in the Live Feed ecosystem, which is not quite what I needed, but it was close. In my case, I would need to link a “poll” to a conversation, which I have already linked to a specific sys_id on a specific table. The poll would then serve as the rating definition, the options would then be the rating choices, and the votes cast would be the actual ratings posted with the feedback.

My plan was to alter my existing SnhFeedbackUtils Script Include to add a couple more functions, one to get the current rating values and another to post a new rating. Each would take the table name and sys_id as arguments, and the current rating functions would return the average rating and the number of votes cast in an object. There was no reference field that would link the “poll” to a conversation, so I decided to use the question column to store the table name and sys_id, since that would never actually be seen in my particular use case. The function to fetch the current values turned out like this:

currentRating: function(table, sys_id) {
	var rating = {users: 0, total: 0, average: 0};
	var pollGR = new GlideRecord('live_poll');
	if (pollGR.get('question', table + ':' + sys_id + ' Rating')) {
		var castGR = new GlideRecord('live_poll_cast');
		castGR.addQuery('poll', pollGR.getUniqueValue());
		castGR.query();
		while (castGR.next()) {
			rating.users += 1;
			rating.total += castGR.option.order;
		}
		rating.average = rating.total / rating.users;
	}
	return rating;
},

Basically, it uses the table and sys_id to find the live_poll record, and if it finds one, it uses the sys_id of that record to find all of the live_poll_cast records linked to that live_poll. I tried to do that with a GlideAggregate, but apparently you can’t do a SUM on a dot-walked property and I needed to sum up the values in the order column from the referenced live_poll_option record. So, I ended up looping through all of the records and adding them up the hard way.

Getting the current rating info was the easy part (the part that I always like tackle first!). Posting the rating was a little more involved, mainly because the first poster for any give table and sys_id has to create both the poll record and all of the option records. To keep things simple for this current iteration, I decided that all ratings would be on a 1 to 5 scale, and built everything accordingly. Eventually, I may want to make that a configurable parameter, but that’s something worthy of future version — right now, I just wanted to get to the point where I could see it all work. Here’s the current version of this function:

postRating: function(table, sys_id, rating) {
	if (rating > 0 && rating < 6) {
		var pollGR = new GlideRecord('live_poll');
		var optGR = new GlideRecord('live_poll_option');
		var castGR = new GlideRecord('live_poll_cast');
		if (!pollGR.get('question', table + ':' + sys_id + ' Rating')) {
			pollGR.initialize();
			pollGR.question = table + ':' + sys_id + ' Rating';
			pollGR.insert();
			for (var opt=1; opt<6; opt++) {
				optGR.initialize();
				optGR.poll = pollGR.getUniqueValue();
				optGR.order = opt;
				optGR.name = opt + '';
				optGR.insert();
			}
		}
		optGR.initialize();
		optGR.addQuery('poll', pollGR.getUniqueValue());
		optGR.addQuery('order', rating);
		optGR.query();
		if (optGR.next()) {
			castGR.initialize();
			castGR.poll = pollGR.getUniqueValue();
			castGR.profile = new GlideappLiveProfile().getID();
			castGR.option = optGR.getUniqueValue();
			castGR.insert();
		}
	}
},

If you don’t pass it a rating value from 1 to 5, it doesn’t do anything at all, but if you do, then it first checks to see if the poll for this table and sys_id exists, and if not, it creates it, along with the 5 option records representing the 5 possible ratings. At that point, it looks for the one option record that matches the rating passed, and then finally, it builds a live_poll_cast record to post the rating.

That pretty much takes care of all of the background work. Now I just need to modify my widget to include a rating option with the feedback and configure some kind of display at the top that shows the average rating and the number of users who have participated in the process. Looks like I will be tackling all of that next time out.

Generic Feedback Widget, Part VI

“Failure after long perseverance is much grander than never to have a striving good enough to be called a failure.”
George Eliot

Well, it turns out that creating a group was not nearly as challenging as reading a group that already exists. I had already started pulling the code out of the widget proper and stuffing it into my accompanying Script Include, so I went ahead and kept that in there, but it’s pretty vanilla stuff. I also tossed in the code to verify group membership, which is also pretty vanilla stuff, so the resulting collection now includes functions to read the group profile, to create a new group, and to join the group if needed.

var SnhFeedbackUtils = Class.create();
SnhFeedbackUtils.prototype = {
	initialize: function() {
	},

	getGroupID: function(table, sys_id) {
		var groupId = null;

		var grp = new GlideRecord('live_group_profile');
		grp.addQuery('table', table);
		grp.addQuery('document', sys_id);
		grp.query();
		if (grp.next()) {
			groupId = grp.getValue('sys_id');
		}
		if (!groupId) {
			gs.getUser().setPreference('snh.live.group.read.authorization', 'true');
			grp = new GlideRecord('live_group_profile');
			grp.setWorkflow(false);
			grp.addQuery('table', table);
			grp.addQuery('document', sys_id);
			grp.query();
			if (grp.next()) {
				groupId = grp.getValue('sys_id');
			}
			gs.getUser().setPreference('snh.live.group.read.authorization', null);
		}

		return groupId;
	},

	createGroup: function(table, sys_id, name, description) {
		var conv = new GlideRecord('live_group_profile');
		conv.initialize();
		conv.setWorkflow(false);
		conv.document_group = true;
		conv.table = table;
		conv.document = sys_id;
		conv.name = name;
		conv.short_description = description;
		conv.insert();
		return conv.getValue('sys_id');
	},

	ensureGroupMembership: function(groupId, liveProfileId) {
		var mbr = new GlideRecord('live_group_member');
		mbr.addQuery('group', groupId);
		mbr.addQuery('member', liveProfileId);
		mbr.query();
		if (!mbr.next()) {
			mbr.initialize();
			mbr.group = groupId;
			mbr.member = liveProfileId;
			mbr.insert();
		}
	},

	type: 'SnhFeedbackUtils'
};

Originally, I had the code to add the person to the group upon reading the feedback, but it turns out that you don’t really have to be a member of the group to read the feedback, so I decided to pull that out and only add the person to the group if they left feedback of their own. This keeps people out of the group who were just looking, and limits the membership of the group to just those folks who have participated in the discussion. The final version of the server side script now looks like this:

(function() {
	var feedbackUtils = new SnhFeedbackUtils();
	data.feedback = [];
	data.mention = '';
	if (input && input.comment) {
		data.table = input.table;
		data.sys_id = input.sys_id;
		data.convId  = input.convId;
		data.tableLabel = input.tableLabel;
		data.recordLabel = input.recordLabel;
		data.recordDesc = input.recordDesc;
		data.mentionMap  = input.mentionMap;
		postComment(input.comment);
	} else {
		if (input) {
			data.table = input.table;
			data.sys_id = input.sys_id;
		} else {
			data.table = $sp.getParameter('table');
			data.sys_id = $sp.getParameter('sys_id');
		}
		if (data.table && data.sys_id) {
			var gr = new GlideRecord(data.table);
			if (gr.isValid()) {
				if (gr.get(data.sys_id)) {
					data.tableLabel = gr.getLabel();
					data.recordLabel = gr.getDisplayValue();
					data.recordDesc = gr.getDisplayValue('short_description');
					data.convId = feedbackUtils.getGroupID(data.table, data.sys_id);
					if (data.convId) {
						var fb = new GlideRecord('live_message');
						fb.addQuery('group', data.convId);
						fb.orderByDesc('sys_created_on');
						fb.query();
						while(fb.next()) {
							var feedback = {};
							feedback.userSysId = getUserSysId(fb.getValue('profile'));
							feedback.userName = fb.getDisplayValue('profile');
							feedback.dateTime = getTimeAgo(new GlideDateTime(fb.getValue('sys_created_on')));
							feedback.comment = formatMentions(fb.getDisplayValue('message'));
							data.feedback.push(feedback);
						}
					}
				} else {
					data.invalidRecord = true;
					data.tableLabel = gr.getLabel();
					data.recordLabel = '';
				}
			} else {
				data.invalidTable = true;
				data.tableLabel = data.table;
				data.recordLabel = '';
			}
		} else {
			data.invalidTable = true;
			data.tableLabel = '';
			data.recordLabel = '';
		}
	}

	function postComment(comment) {
		if (!data.convId) {
			data.convId = feedbackUtils.createGroup(data.table, data.sys_id, data.recordLabel. data.recordDesc);
		}
		comment = comment.trim();
		comment = expandMentions(comment, data.mentionMap['comment']);
		var liveProfileId = getProfileSysId(gs.getUserID());
		var fb = new GlideRecord('live_message');
		fb.initialize();
		fb.group = data.convId;
		fb.profile = liveProfileId;
		fb.message = comment;
		fb.insert();
		feedbackUtils.ensureGroupMembership(data.convId, liveProfileId);
	}

	function expandMentions(entryText, mentionIDMap) {
		return entryText.replace(/@\[(.+?)\]/gi, function (mention) {
			var response = mention;
			var mentionedName = mention.substring(2, mention.length - 1);
			if (mentionIDMap[mentionedName]) {
				var liveProfileId = getProfileSysId(mentionIDMap[mentionedName]);
				if (liveProfileId) {
					response = "@[" + liveProfileId + ":" + mentionedName + "]";
				}
			}
			return response;
		});
	}

	function formatMentions(text) {
		if (!text) {
			text = '';
		}
		var regexMentionParts = /[\w\d\s/']+/gi;
		text = text.replace(/@\[[\w\d\s]+:[\w\d\s/']+\]/gi, function (mention) {
			var response = mention;
			var mentionParts = mention.match(regexMentionParts);
			if (mentionParts.length === 2) {
				var liveProfileId = mentionParts[0];
				var name = mentionParts[1];
				response = '<a href="?id=user_profile&table=sys_user&sys_id=';
				response += getUserSysId(liveProfileId);
				response += '">@';
				response += name;
				response += '</a>';
			}
			return response;
		});
		return text.replace('\n', '<br/>');
	}

	function getUserSysId(liveProfileId) {
		if (!data.userSysIdMap) {
			data.userSysIdMap = {};
		}
		if (!data.userSysIdMap[liveProfileId]) {
			fetchUserSysId(liveProfileId);
		}
		return data.userSysIdMap[liveProfileId];
	}

	function fetchUserSysId(liveProfileId) {
		if (!data.profileSysIdMap) {
			data.profileSysIdMap = {};
		}
		var lp = new GlideRecord('live_profile');
		if (lp.get(liveProfileId)) {
			var userSysId = lp.getValue('document');
			data.userSysIdMap[liveProfileId] = userSysId;
			data.profileSysIdMap[userSysId] = liveProfileId;
		}
	}

	function getProfileSysId(userSysId) {
		if (!data.profileSysIdMap) {
			data.profileSysIdMap = {};
		}
		if (!data.profileSysIdMap[userSysId]) {
			fetchProfileSysId(userSysId);
		}
		return data.profileSysIdMap[userSysId];
	}

	function fetchProfileSysId(userSysId) {
		if (!data.userSysIdMap) {
			data.userSysIdMap = {};
		}
		var lp = new GlideRecord('live_profile');
		lp.addQuery('document', userSysId);
		lp.query();
		if (lp.next()) {
			var liveProfileId = lp.getValue('sys_id');
			data.userSysIdMap[liveProfileId] = userSysId;
			data.profileSysIdMap[userSysId] = liveProfileId;
		}
	}
	
	function getTimeAgo(glidedatetime) {
		var response = '';
		if (glidedatetime) {
			var timeago = new GlideTimeAgo();
			response = timeago.format(glidedatetime);
		}
		return response;
	}
})();

With this latest version, anyone can now view the feedback, and anyone can post feedback. If you are the first person to post feedback on a particular item, then a new group gets created, and anyone who posts gets added to the group. Using the Live Feed infrastructure rather than creating my own tables may end up having some unforeseen adverse consequences, but for now, everything seems to have worked out as I had intended, so I’m calling it good enough. If you want to check it out yourself, here is the latest Update Set.

Generic Feedback Widget, Part V

“If at first you don’t succeed, you are running about average.”
M.H. Alderson

I looked at several different ways to solve my problem with the Generic Feedback Widget, but I couldn’t come up with anything that didn’t involve inactivating or altering the ACL that was at the heart of the issue.Finally, I settled on a plan that would at least involve minimally invasive alterations to the ACL. The plan was pretty simple: create an obscure User Preference and set it to true just before accessing the live_group_profile record, and then delete the preference as soon as the record was obtained. The alteration to the ACL, then, would be to check for that preference before applying the ACL. The updated version of the ACL script now looked like this:

if (gs.getPreference('snh.live.group.read.authorization') == 'true') {
	answer = true;
} else {
	var gr = new GlideRecord('live_group_member');
	gr.addQuery('member', GlideappLiveProfile().getID());
	gr.addQuery('group', current.sys_id);
	gr.addQuery('state', 'admin').addOrCondition('state', 'active');
	gr.query();
	answer = gr.next();
}

The first thing that we do is check for the preference, and if it’s there, then we bypass the original code; otherwise, things proceed as they always have. I don’t really like tinkering with stock components if I can avoid it, mainly because of the subsequent issues with patches and upgrades potentially skipping an upgrade of anything that you have touched. Still, this one seemed to be unavoidable if I wanted to salvage the original intent and still do what I wanted to do.

The next thing that I needed to do was to set the preference just before attempting the read operation, and then removing it as soon as I was done. That code turned out to look like this:

gs.getUser().setPreference('snh.live.group.read.authorization', 'true');
grp = new GlideRecord('live_group_profile');
grp.addQuery('table', table);
grp.addQuery('document', sys_id);
grp.query();
if (grp.next()) {
	groupId = grp.getValue('sys_id');
}
gs.getUser().setPreference('snh.live.group.read.authorization', null);

I ended up pulling that out of the widget and putting it into its own Script Include, mainly to tuck the specialized code away and out of sight. Anyway, it all sounded like a great plan and all I needed to do now was to test it out, so I did. And it failed. So much for my great plan.

It took a little digging, but I finally figured out that the ACL was not the only thing keeping people from outside the group from reading the group profile record. There are also a number of Business Rules that do pretty much the same thing. I spent a little time combing through all of those looking for ways to hack around them, and then finally decided that, for my purposes anyway, I really didn’t to be running any Business Rules at all. So I added one more line to my read script to turn off all of the Business Rules.

gs.getUser().setPreference('snh.live.group.read.authorization', 'true');
grp = new GlideRecord('live_group_profile');
grp.setWorkflow(false);
grp.addQuery('table', table);
grp.addQuery('document', sys_id);
grp.query();
if (grp.next()) {
	groupId = grp.getValue('sys_id');
}
gs.getUser().setPreference('snh.live.group.read.authorization', null);

That did it. Now, people who are not in the group can still read the group profile record, which is good, because you need the sys_id of that record to read all of the messages in the group, which is what we are using as feedback. The only thing that I have accommodated at this point is situations where a group profile record does not exist at all, and I have to create one.

But that’s an entirely different adventure

Generic Feedback Widget, Part IV

“For all sad words of tongue and pen, the saddest are these, ‘It might have been.'”
John Greenleaf Whittier

Well, it seemed like a good idea at the time. In fact, I was pretty proud of my Generic Feedback Widget once I had it pretty much all put together. I even felt so good about it that I went ahead and put out an Update Set. Then I started playing around with it while using other User accounts that did not have the admin role, and I realized that something was seriously wrong. In fact, nothing really worked at all. If you are not an admin or an existing member of a conversation, not only can you not enter any new feedback; you can’t even see the existing feedback that is already there. That’s not right!

It took be a little digging around to finally lay my hands on the source of the problem, but I found it. There is read ACL on the live_group_profile table that includes the following script:

var gr = new GlideRecord('live_group_member');
gr.addQuery('member', GlideappLiveProfile().getID());
gr.addQuery('group', current.sys_id);
gr.addQuery('state', 'admin').addOrCondition('state', 'active');
gr.query();
answer = gr.next();

The impact of that ACL is that you cannot read a record from the live_group_profile table unless you are an existing member of that group. Without access to the group profile, you cannot obtain the sys_id of the group to use in the query of the live_feed_message table to see all of the messages. And you cannot put yourself in the group if you can’t get the ID of the group to include on the live_group_member record you would need to create in order to make yourself a member. The bottom line to all of that is that, if you are not an admin (which overrides this ACL), you cannot see any messages related to the subject of the page and you cannot create any. That pretty much kills the entire basis of what I was trying to do.

The question now, is what, if anything, can be done about it. Obviously, I could simply deactivate that ACL and the problem would be solved, but that would also open up all kinds of other problems that that ACL was designed to avoid, so that’s not really a viable option. I could give up on my desire to leverage these existing tables and functions and just set up all new tables for this process with their own ACLs, but that seems like quite a bit more work than I normally care to undertake. Still, it seems as though there has got to be a way to leverage what I have already built without breaking things that are already in the product and not signing up for a major project. I need to figure out a way for non group members to read the group record without effectively killing that ACL for other purposes, or I am going to have to start all over with custom tables of my own design.

This should be interesting …

Generic Feedback Widget, Part III

“If you think you can do a thing or think you can’t do a thing, you’re right.”
Henry Ford

Last time, I cleaned up all of the loose odds and ends of the display portion of the Generic Feedback Widget, which should have wrapped up that portion of the project. I say “should have” because now that I have it all working I see that there are a couple more things that I would like to do. For one, I think that there should be a limit on the number of entries initially displayed with an option to show them all. Once you accumulate a certain amount of feedback, no one is really going to want to go through all of that, so I think the initial limit should be something like 5 or 10 entries, with the rest only appearing if requested.

Another thing that I noticed in looking at some existing sample data is that the live_message text can contain hashtags, and there should be some code included that formats those hashtags. Of course, that would mean that there would have to be some place to go if you clicked on a hashtag, which sounds like an entirely different project. I’m not really up for that just yet, so I decided to push all of those thoughts aside and get back to the main purpose of this little widget, which is to collect new feedback.

Since the live_message table that I am using to store this feedback supports @mentions, I decided to use the snh-form-field tag that supports @mentions as the input element. This makes the HTML for the form field pretty simple.

<form ng-show="data.showComment" id="form1" name="form1" novalidate>
  <snh-form-field snh-model="c.data.comment" snh-name="comment" snh-type="mention" snh-label="Leave a comment:"/>
  <button class="btn btn-primary" ng-click="postComment();">Post Comment</button>
</form>

In order to use the snh-form-field tags, you also need to add the snhFormField Angular Provider down at the bottom of the widget, but that’s just a matter of selecting that tab and clicking on the Edit button.

One other thing that you need to do with the @mentions is to expand those to include the sys_id before writing them to the database. Here again we will have the sys_user sys_id in the mentionMap, but what we really need for the live_message text is the live_profile sys_id. For that, we will go back to our earlier functions to translate one to the other.

function expandMentions(entryText, mentionIDMap) {
	return entryText.replace(/@\[(.+?)\]/gi, function (mention) {
		var response = mention;
		var mentionedName = mention.substring(2, mention.length - 1);
		if (mentionIDMap[mentionedName]) {
			var liveProfileId = getProfileSysId(mentionIDMap[mentionedName]);
			if (liveProfileId) {
				response = "@[" + liveProfileId + ":" + mentionedName + "]";
			}
		}
		return response;
	});
}

To save the feedback, we need the conversation, the author, and the expanded message. The conversation is the live_group_profile record that points to the table and sys_id to which this feedback is attached. If there were any existing comments, then this record already exists. If not, then we will have to create it using the table and sys_id. The author is the currently authenticated user, but again, we have that person’s sys_user sys_id, when what we really need is the live_profile sys_id. For that we will have to go back to our sys_id translators once again. All together, the code ended up looking like this:

function postComment(comment) {
	if (!data.convId) {
		var conv = new GlideRecord('live_group_profile');
		conv.initialize();
		conv.table = data.table;
		conv.document = data.sys_id;
		conv.insert();
		data.convId = conv.getValue('sys_id');
	}
	comment = comment.trim();
	comment = expandMentions(comment, data.mentionMap['comment']);
	var liveProfileId = getProfileSysId(gs.getUserID());
	var fb = new GlideRecord('live_message');
	fb.initialize();
	fb.group = data.convId;
	fb.profile = liveProfileId;
	fb.message = comment;
	fb.insert();
}

You can also mark the message public or private, and I have thought about providing an option at the widget level to let you configure instances one way or another, but for this initial version, we will just take the default. At this point, all that is left is to take it out for a spin …

Posting a new feedback comment with an @mention

Clicking on the Post Comment button saves the feedback and then reloads the page.

New feedback comment posted.

I like it! Now, this little sample page only contains the Dynamic Breadcrumbs Widget and the new Generic Feedback Widget, but in the real world this new feedback widget would just be a secondary widget on a page with the main attraction displayed in a primary widget. This widget could be placed underneath or in a sidebar, but it really isn’t intended to be the main focus of a page. But then again, how you want to use it is clearly up to you. There are still a few things that I would like to do before I consider this one all finished up, but there is enough here now to release an Update Set for any of you who are interested in playing along at home. The next one will be better, but this version does work.