Lodash in Service Portal

Lodash in Service Portal There are a number of client-side libraries included in Service Portal. We will be going over some of them in this next series, starting with the Lodash library. The version of Lodash that is included in the Service Portal is 4.17.11. Please keep in mind that Lodash is only available client-side, so you can use it in your Client Script, but not in your Server Script. About Lodash Lodash is a JavaScript library that helps programmers write more concise and maintainable JavaScript and contains tools to simplify programming with strings, numbers, arrays, functions, and objects. You can find the full documentation here: https://lodash.com/docs Lodash can be broken down into several main areas: Utilities - for simplifying common programming tasks such as determining type as well as simplifying math operations. Function - simplifying binding, decorating, constraining, throttling, debouncing, currying, and changing the pointer. String - conversion functions for performing basic string operations, such as trimming, converting to uppercase, camel case, etc. Array - creating, splitting, combining, modifying, and compressing Collection - iterating, sorting, filtering, splitting, and building Object - accessing, extending, merging, defaults, and transforming Seq - chaining, wrapping, filtering, and testing. Some examples Lodash contains hundreds of helper functions. Although I can't go through all of them here, I have put together some common examples. OBJECTS _.clone(value) Creates a shallow clone of value. [crayon-5df46451d1a82483505532/] _.assign(object, [sources]) Assigns own enumerable string keyed properties of source objects to the destination object. Source objects are applied from left to right. Subsequent sources overwrite property assignments of previous sources. [crayon-5df46451d1a8e126263087/] ARRAYS _.times(n, [iteratee=_.identity]) Invokes the iteratee n times, returning an array of the results of each invocation. The iteratee is invoked with one argument; (index). [crayon-5df46451d1a94063075710/] _.uniq(array) Creates a duplicate-free version of an array, using SameValueZero for equality comparisons, in which only the first occurrence of each element is kept. The order of result values is determined by the order they occur in the array. [crayon-5df46451d1a9c033041887/] FUNCTIONS _.bind(func, thisArg, [partials]) [crayon-5df46451d1aa2877180345/] COLLECTION _.includes(collection, value, [fromIndex=0]) Checks if value is in collection. If collection is a string, it's checked for a substring of value, otherwise, SameValueZero is used for equality comparisons. If fromIndex is negative, it's used as the offset from the end of collection. [crayon-5df46451d1aa7787448722/] _.filter(collection, [predicate=_.identity]) Iterates over elements of collection, returning an array of all elements predicate returns truthy for. The predicate is invoked with three arguments: (value, index|key, collection). [crayon-5df46451d1aad862747675/] _.find(collection, [predicate=_.identity], [fromIndex=0]) Iterates over elements of collection, returning the first element predicate returns truthy for. The predicate is invoked with three arguments: (value, index|key, collection). [crayon-5df46451d1ab3312437683/] SEQ _.chain(value) Creates a Lodash wrapper instance that wraps value with explicit method chain sequences enabled. The result of such sequences must be unwrapped with _#value. [crayon-5df46451d1ab9670428945/] _.sortBy(collection, [iteratees=[_.identity]]) Creates an array of elements, sorted in ascending order by the results of running each element in a collection thru each iteratee. This method performs a stable sort, that is, it preserves the original sort order of equal elements. The iteratees are invoked with one argument: (value). [crayon-5df46451d1abe552344032/] _.map(collection, [iteratee=_.identity]) Creates an array of values by running each element in collection thru iteratee. The iteratee is invoked with three arguments: (value, index|key, collection). [crayon-5df46451d1ac7583297897/] Conclusion Although some Lodash methods are becoming native JavaScript functions with ES6, there are still many useful methods that complement functional programming in Service Portal. For more on Lodash, check out the website: https://lodash.com For a Lodash cheatsheet, check out: https://devhints.io/lodash What other Lodash methods do you find useful in Service Portal? Let me know in the comments.

GlideSPScriptable Cheat Sheet

Overview Did you know there are over 60 server-side methods available in GlideSPScriptable ($sp)? Many of these methods are hidden or not documented, so we've combed through all the widgets and source code to provide you with this cheat sheet that includes all of the $sp methods available in Service Portal. Now updated for the New York release. Save time and maximize your productivity with this quick reference document for you to use day-to-day. Enjoy!

Service Catalog Item Wizard in Service Portal

We've had a number of clients ask about structuring catalog item forms as more of a "wizard" that only renders one section at a time. After thinking about it for a while, I realized that I could use the GlideForm API to programmatically hide and show the different sections (containers). So over the past couple of weeks, I've been working on a new widget that simply interacts with the out-of-box catalog item widget, and uses the API's to add all of the wizard-like capabilities. I think it turned out pretty cool, it's fully themeable, and best of all, it does not require cloning of any widgets. I still have a few more features to add, and I'm also considering adding an accompanying library of Variable Sets that provide a more graphical UI than the out-of-box catalog variables. If all goes well, I may end up including the widget in our RocketFuel library of widgets, so if you're interested in adding some wizard-like capabilities to your portal, feel free to contact me and we can schedule a demo. I'd love to hear what you guys think in the comments below. Is this a useful widget? Does this improve the user experience of the service catalog item form?

Restyling Notifications in Service Portal

Today I am going to show you how to change the styling of the built-in notifications in Service Portal. The default notifications in Service Portal are based on the Bootstrap Alerts components, but I prefer the smaller "Toast" notifications of Bootstrap 4. Default   New Style         The following CSS sets a new width and aligns the notifications in the upper right corner of the screen rather than spanning the whole page. You will need to add the following styles into a CSS Include in your theme. CSS [crayon-5df46451d2dea015308408/] If you are already on the Madrid release, I recommend replacing the above HEX colors with the $brand-success and $brand-danger variables so that they can be driven by the variables defined on your theme. If you wish to trigger notifications from your own widget, you can trigger notifications using either of the following. Server Side: gs.addInfoMessage("Success goes here"); gs.addErrorMessage("Error goes here"); Controller: spUtil.addInfoMessage("Success goes here"); spUtil.addErrorMessage("Error goes here");   BEFORE AFTER This is just a small example of how you can restyle the default notifications, but there is still plenty of ways this could be improved. If you have some ideas or other styles that you would like to share, feel free to post them in the comments below.

Localization in Service Portal

As most companies experience globalization in some capacity, it’s important that they localize their portals to accommodate users from different areas around the world. In this article, I will go through the different components involved with localizing your Service Portal. Before we begin, make sure to activate the internationalization (i18n) plugin and the required language pack plugins that will be used by your organization. Also, there is an OOB widget called "Language Switch." Simply include this widget somewhere in the portal to enable users to update their language preferences. The two primary tables in ServiceNow responsible for storing translations for Service Portal are: Message Translated Text We will also cover some of the other tables and plugins that can potentially impact translating a portal. Message table (sys_ui_message) The UI message table contains translations using key/value pairs. The key is the string in the base language and the value is the localized version of that string. The main fields on this table are: Key: unique identifier of this message (usually the English version of the string). Language: language the message is translated into. Message: translated text that users see. In Service Portal, the primary area you would see UI Messages used is inside widgets (in the HTML, Client Controller, and Server Script), but can also be commonly found in other areas with server-side scripts (e.g. Scripted Menu Items, Script Includes, etc.). HTML Use the ${} syntax in widgets to tag strings for translation [crayon-5df46451d4363577688032/] If translating a string stored in a variable, it is also possible to wrap a data binding {{}} with ${} to translate the contents of the variable. [crayon-5df46451d436c210058515/] However, I do not recommend using this approach. It is much better to do the translations server-side whenever possible. Client Controller Similar to HTML, you can also use ${} in the controller if it's going to be displayed in the HTML [crayon-5df46451d4372965140797/] Note: In some cases, the translation might have quotes or double quotes in it. That could lead to JavaScript errors if you are using the ${} syntax in the client script. The safest way to fetch a translated message is to do it in the server script. Another way, and perhaps better way to access translated strings in the controller is using the i18n service. [crayon-5df46451d4378646962714/] In order to use the i18n service, you must also declare the variable in the HTML using the <now-message> syntax [crayon-5df46451d437d120962733/] And then you can render the message in HTML using the {{}} syntax [crayon-5df46451d4381657566616/] Server Script For all server-side translations, use the gs.getMessage() method [crayon-5df46451d4386379448956/] It is also possible to format certain template strings by passing in an array of strings as the second parameter: [crayon-5df46451d438b552207199/] This would return: "Welcome Nathan Firth – you have 5 active tickets." Demo To demonstrate the various ways of doing translations using the sys_ui_message, here is a quick screen capture of the Widget Editor showing the string translated and used four different ways in the same widget. The string in all four cases is "Hello World", and I'm translating it to say "Hello There". Click image to see full size Translated Text table (sys_translated_text) The Translated Text table stores translations for fields with the field type translated_text or translated_html. The main fields for this table are: Document: internal identifier of the record this translation applies to. Field name: field this translated text appears in, for example, Close notes. Language: language the text is translated into. Table Name: table this translation applies to. Value: translated text that the user sees. Some common areas in Service Portal using Translated Text fields include: Widget Instances (title, short_description) Catalog Categories (title, description) Menu Items (label) Knowledge Categories (label) Other translation tables Although the Message and Translated Text are the primary tables used in Service Portal, there are also a few others worth noting: Knowledge (kb_knowledge) if you've activated the "com.glideapp.knowledge.i18n2" plugin, you can also translate articles directly using the Knowledge tables. Choice (sys_choice) table contains translated text for options that appear in choice lists. Field Label (sys_documentation) table stores the text of table names along with the singular and plural labels for each field in the table. Session at K19 Manually extracting, translating, and importing strings is time-consuming and error-prone. We will be leading a CreatorCon session at Knowledge19 in Las Vegas where we will be presenting on internationalization and making recommendations on to make this process less painful. Stay tuned for more information about that session. Lastly... We're working on a brand new scoped application that will automate the extratction and importing of translations for Service Portal. If you are interested in seeing a demo or would be interested in this upcoming application, please don't hesitate to reach out.

How to Stay “Out of Box” with your Service Portal

WHAT IS "OUT OF BOX" One of the most common requests we hear when developing a portal is, "stay close to out-of-box". People usually think this means staying close to the look and feel of the Stock theme, in hopes that it will minimize complications with future upgrades. This common misconception has very little to do with the portal theme, and everything to do with how many and which widgets were cloned. Staying out-of-box has nothing to do with the theming, look or feel of the portal, but how many of the widgets were cloned. The real danger of “stay close to out-of-box” is that it leaves little-to-no room for: Adhering to company required branding guidelines Delivering a delightful user experience Meeting business requirements So how do you stay close to out-of-box and ensure a smooth upgrade process without sacrificing the look, feel and functionality of the portal? In this article, we'll outline various approaches to help you deliver a portal without sacrificing the user experience. WHAT NOT TO CLONE Before we talk about what you can safely change, let’s talk about what you shouldn’t change. Changing a ServiceNow widget involves cloning it. When you clone a widget, you become responsible for ensuring your widget continues to function as expected after a ServiceNow upgrade. If a widget with complex logic is cloned and you want to align it with the recent upgrade, you may need to analyze both original and cloned widgets line-by-line to determine what changed and to ensure nothing has stopped working. We know from experience that some widgets tend to change quite often, even within patches and hot fixes! For that reason, we recommend that you avoid cloning any widget with complex logic. Some examples include: Shopping cart Catalog item Approvals Order guide Data table Form Before you clone a widget, consider the additional effort it will require to maintain the widget with each upgrade. In many cases, with a little creativity, it is possible to meet business or branding requirements without cloning. WAYS TO AVOID CLONING A WIDGET We’ve found quite a few ways to avoid cloning while still meeting requirements. Here are some suggestions in a rough order of difficulty. INSTANCE OPTIONS Many widgets already have instance options for configuring the behavior and look of the widget. You can access the options by pressing CTRL + Click on the widget and selecting "Instance Options.” CSS Making changes to CSS outside of a widget will have minimal impact on your ability to upgrade. Same thing applies to your layout. With this in mind, don't be afraid to style and theme your portal to make it more attractive and "on brand." WRAPPING/EMBEDDING WIDGETS In some cases, you just need to augment or slightly modify the behavior of a widget. By embedding a standard widget in a custom one, you take advantage of the standard functionality while gaining the control you need. This is useful, for example, when you need finer control over the instance options that are passed to the standard widget or when you need to adapt URL parameters or events. DIRECTIVES From Angular.js documentation: “At a high level, directives are markers on a DOM element (such as an attribute, element name, comment or CSS class) that tell AngularJS's HTML compiler ($compile) to attach a specified behavior to that DOM element (e.g. via event listeners), or even to transform the DOM element and its children.” In simpler terms, a directive could allow you to attach behavior to DOM elements inside a widget you don’t “own.” This is an extremely powerful way to adapt widgets without cloning them. While diving into directive development is beyond the scope of this article, keep it in mind as you evaluate your options. IF YOU NEED TO CLONE In some situations, you can't always avoid cloning to achieve the result you want. If that is the case, be sure you: Document the cloned widgets Consider analysis time as part of your upgrade validation process After an upgrade, evaluate the source widgets to determine if you should Keep the clone "as-is" Upgrade it Revert back to the original Remember, Service Portal is a UI framework built to help you create great experiences. Don’t be afraid to deviate from the Stock theme and take full advantage of all its capabilities! ADDITIONAL READING For related information on the topic, check out these articles. Out-of-Box — Widget Library, ServicePortal Widget Cloning — Clone a Widget Modifying — Widget CSS, Embedding Widgets, Configure Widget Instance Options

The GlideForm (g_form) API in Embedded Widgets

Ever wonder how to embed a Service Portal widget into a form and have it access fields in the parent form? GlideForm to the rescue! GlideForm is a client-side JavaScript API that provides methods to customize forms. Use the g_form object to access all of the GlideForm API methods. When using the Service Catalog variable types Macro or "Macro with Label", you can embed a Service Portal widget into the form. Within the client controller of the embedded widget you have access to both g_form and the field object by accessing them from the page object on $scope: $scope.page.field $scope.page.g_form FEATURES GlideForm supports over 50 different methods of accessing and manipulating form fields, in this quick tutorial, we will cover just a few of the most frequently used functions: getValue() setValue() getFieldNames() setVisible() setReadOnly() setMandatory() You can view the full list of supported g_form methods here. WALKTHROUGH To get started: Add a new variable with type “Macro” to a catalog item with a few existing variables From the “Type Specifications” tab, click on the Widget reference field picker and select “New” Name your widget and submit Navigate to “/sp_config/?id=widget_editor” and select your newly created widget Paste in the following code. HTML: [crayon-5df46451d51bd253752060/] Client Script: [crayon-5df46451d51c6567427264/] Update the field names (FIELDNAME) in the HTML to match some fields from your form Now if you view the catalog item in the portal, you should see your widget embedded in the form displaying 5 buttons. DEMO   FURTHER READING https://docs.servicenow.com/bundle/london-application-development/page/app-store/dev_portal/API_reference/GlideForm/concept/c_GlideFormAPI.html

Secrets of the Simple List Widget

By now, you've probably already used the Simple List widget. It is one of the default widgets on the OOB portal homepage. Similar to the Data Table widget, it is used to display a list of records from a table. However, there is a lot more to this widget than you might think. In this post, we will cover some of the secrets of the simple list widget. To give you a quick sample of its capabilities, there is an OOB demo page available at: https://yourinstance.service-now.com/sp?id=test_list Features Include: Display records from any table and filter Support for image fields Show primary and multiple secondary fields Limit the height with scrollable body Trigger an event Customizable actions To get started, let's first create a widget which shows the payload of the event that get's triggered when clicking a record. HTML: [crayon-5df46451d65a2494747434/] Client Script: [crayon-5df46451d65ab888261726/] Now if you place this widget on the same page as the Simple List widget, and if you don't specify a "Link to this page" in the Instance Options, you will see the JSON representing the record you clicked on. With this event, it'll be very easy to trigger a modal window or other user interaction, but for now let's proceed to adding some List Actions. LIST ACTIONS The Simple List widget supports adding additional actions for the records in the list. For some reason this related list is not visible on the form by default, so we'll need to add it: Pull up the Platform View of the Instance Record of the Simple List Click the hamburger icon > “Configure” > “Related Lists” Add "List Action -> Parent List" Now you should see the List Actions Related List When adding List Actions, you are able to include properties from the record in the URL field using double brackets: [crayon-5df46451d65b2268923192/] However, there are a couple of unfortunate limitations: You cannot link to an external URL You cannot use URL prefixes such as “mailto:” or “tel:” Clicking a List Action does not trigger an event This limits the List Actions to just linking to other pages, but hopefully this will get fixed in an upcoming release. DEMO Here is a quick video demonstrating how to configure some List Actions on the Simple List widget. FURTHER READING https://docs.servicenow.com/bundle/london-servicenow-platform/page/build/service-portal/concept/simple-list-widget.html

Images and Update Sets – How to Sync Attachments on Widget Instances

It’s a pretty common requirement to include images in your widgets, for example replacing the icons with images in the “Icon Link” widget (available here). However, if you have ever added an image field to one of the instance tables, you may have noticed that the images were not included in the update set. This obviously makes it difficult to migrate the portal between instances. The good news is there is a simple solution. SYNCING ATTACHMENTS First, go to a record within the table where you would like to sync attachments (e.g. sp_instance_link) Right click the heading > Configure > Dictionary Select the record where “Type” is “Collection” Click the “Advanced View” related link Paste the following into the Attributes field: [crayon-5df46451d78e6632881557/] When completed, it should look like this: Now, the next time you save or update the instance record, the image data will also get included in the update set. NOTE: If you wish to use the image field on all instance tables, you can create the field on the base “sp_instance” table. However, you will still need to follow the steps above for each one of the extension tables where the image field is used.