Extension
Note to the Reader
The Extension model has changed significantly over the past versions. This section describes key parts of the web client 2 extension facilities. However, it is not complete and should be considered Work in Progress. If you are unable to find what you are looking for here, we recommend posting a question to the Engineering team through our UI-Web Client (iAccess) channel under the Maconomy Knowledge Center team in Microsoft Teams. We will reply there and take note of your questions, feedback, and comments for future iterations of this section.
This section describes how to make client-side web client extensions using built-in extension facilities as well as tooling provided by the Maconomy Extender. Client-side extensions cover authentication methods, preferred settings, menu customization, and updates to existing workspaces/addition of new workspaces. The primary goal of web client extensions is to customize the appearance of Maconomy functionality when leveraged over a Web user interface. If you need to make fundamental changes such as extending core business logic and adding new fields and actions, use the Java extension framework to create server-side extensions. While the two extension approaches can be used together, it is important to note that the purpose of client-side extensions is to change how Maconomy functionality is rendered, not how it works.
The web client application version and the API version are specified in the root of the web client configuration files, specifically in the application.json file. In the following example, the web client application is called 22 and the current API version is 23.0.0. The PU manifest describes the backend Maconomy versions compatible with this application.
{
"api": "23.0.0",
"application": {
"version": "22.0.0"
},
"shell": {
"$ref": "Shell:Shell"
},
"workspace": {
"$ref": "Workspace:Workspace"
},
"platform": {
"$ref": "Platform:Platform"
}
}
The remainder of this file consists of JSON references to the three main web client areas:
- Platform - Configuration and tweaking of low-level web client runtime mechanics.
- Shell - Configuration of the sidebar menu, notifications, and preferences.
- Workspace - Configuration of workspaces and their layouts.
The following subsections describe these areas in greater detail.
A Note about Web Client Configuration Files
Web client configurations use the JSON format, a standard notation similar to XML. During runtime, the web client requests a single configuration file describing all extensions (standard or custom). This file is called application.json and is retrieved through the configurations end point in the REST API. In the web client source configuration files, the notation (see the following example)
{
"$ref": "Workspace:Workspace"
}
is a heavily used modularization technique. The JSON object is replaced (or macro expanded) by the Workspace.json configuration file located in the Workspace folder.
When the web client configuration files are processed by the REST API, all JSON properties with the prefix T$ are translated to the language utilized by the end-user. For example, if a web client source configuration file has the following contents:
{
"T$title": "Hello World"
}
then a Spanish user receives the following content in his/her browser:
{
"title": "Hola mundo"
}
The translation relies on standard Maconomy dictionaries. It only works if a dictionary containing the required terms exists in the chosen language.
Platform
The second main area of web client extension is the platform part which specifies various low-level web client behaviors. You can find the default configuration of the platform part in the Platform.json file:
{
"usageTracking": {
"$ref": "Usagetracking"
},
"containers": {
"$ref": "Containers"
},
"typeAhead": {
"$ref": "Typeahead"
}
}
Usage Tracking
The usage tracking part concerns the integration between the web client and Google Analytics. This feature was also present in older versions and is used to track page views, events, errors, and other usage data about end-users. You can acquire your own tracking ID directly from Google, and add it to the UsageTracking.json configuration file so you can collect usage data about a web client installation. Note that web client uses Universal Analytics. In the following excerpt, the Google Analytics tracking ID UA-123456789-1 is added to the standard configuration:
{
"enabled": true,
"endUserOptIn": true,
"trackingId": "UA-123456789-1"
}
The two mandatory properties, enabled and enduserOptIn, are used to (1) enable/disable tracking completely and (2) show/hide the cookie consent banner. If tracking is disabled, then the web client still creates cookies in the browser but performs no actual tracking. If the end-user opt-in is disabled, then users are not presented with a banner informing them of tracking.
Containers
The containers part is active and is a new feature introduced in web client version 2. The containers configuration allows consultants to supply additional metadata about REST API containers. This is necessary because the specification of containers that we get through the containers endpoint only describes a subset of the semantics of the backend. The configuration format follows a very simple convention: it is an object with properties matching the container names from the REST API. You can add information about each container's various aspects, and the web client runtime will then adapt to this new data.
Singleton Containers
Maconomy makes a special distinction between normal and singleton containers. Whereas normal containers represent collections of resources, singleton containers always represent a single resource. This leads to a slightly different navigation interface in the REST API. Only very few containers are singletons, and these are not specifically identified by the REST API. However, since some of these are very prominent for most users, the web client allows the consultant to add information about singletons in the containers configuration.
{
"TimeRegistration": {
"card": {
"singleton": {
"DateVar": "card.datevar",
"EmployeeNumberVar": "card.employeenumbervar"
}
}
}
}
The preceding excerpt specifies TimeRegistration as a singleton container. DateVar and EmployeeNumberVar are used when navigating with this container. Singleton properties on the right side refer to internal names used by the REST API when navigating this container.
File Actions
Another feature of the containers configuration is the ability to add information about file actions. The REST API supports actions for uploading files. However, it does not specify which ones are actually file actions. This information is important since the protocols for dealing with file actions are different from those for normal actions, both in the web client runtime and in terms of messages exchanged between the browser and the REST API.
{
"ExpenseSheets": {
"card": {
"actions": {
"AttachDocument": {
"attachments": {
"required": true,
"allowMultipleAttachments": true
}
}
}
},
"table": {
"actions": {
"AttachDocumentToLine": {
"attachments": {
"required": true,
"allowMultipleAttachments": false
}
}
}
}
}
}
The preceding configuration specifies that the AttachDocument action on the ExpenseSheets card pane and the AttachDocumentToLine action on the corresponding table pane are file actions. Both require an attached file, but they differ in the number of files they allow as attachments.
Action Parameters
Some Maconomy actions require certain variables to have a particular value when executed. The REST API does not specify these variables, so the web client can add this information as so-called parameters in the container configuration. In the following example, the ApproveAbsenceEntry action on the card pane of the AbsenceEntryOverview container is configured to require four variables as parameters, namely: EntryDateVar, ValidTillVar, NumberOfDaysVar, and ReasonVar.
"AbsenceEntryOverview": {
"card": {
"actions": {
"ApproveAbsenceEntry": {
"parameters": {
"EntryDateVar": "card.entrydatevar",
"ValidTillVar": "card.validtillvar",
"NumberOfDaysVar": "card.numberofdaysvar",
"ReasonVar": "card.reasonvar"
}
}
}
}
}
Filter-As-Table Panes
Standard Maconomy containers have at least one of the following pane types: card, table, and filter. The web client version 2 includes a new special type called Filter as Table which is handled purely on the client-side. This pane type allows consultants to render a standard filter pane as a table pane. In general, filters are read-only whereas tables are editable. When using a filter as a table, the currently selected record is actually the corresponding card pane record. This makes the filter appear as an editable table, although it takes a bit longer to respond since the web client has to load the corresponding card record whenever the user selects a filter row.
"AbsenceEntryOverview": {
"filterAsTable": {
"fields": {
"RelatedEntryValidTill": {
"immutable": true
},
"EmployeeName1": {
"mapsTo": "EmployeeNameVar"
}
}
}
}
To make a filter pane available as a table, you may need to add additional field specifications in the containers configuration file. In the preceding example, two changes are added. First, the RelatedEntryValidTill field is specified as immutable. This is a performance optimization which states that this field will not change its value when its card record is edited. This means that the web client does not to need to reread the field when a user edits the card record. Second, the EmployeeName1 field is mapped to the EmployeeNameVar field. This is necessary in cases where an underlying database column has different field names depending on whether it is shown in the filter or in the card. The mapsTo attribute allows the web client to link these two fields.
Configuration Attributes for Controlling Caching of New Record Data
When a new card or table record is created, the web client sends a request to the server to obtain default values for the new record. By default, these values are cached for all containers. The web client version 2.4.1 introduces a configuration setting that you can use to disable caching for a specific container.
For example, to disable caching of new record data for both the card and the table panes of the ExpenseSheets container, add the following attributes to the Containers.json file:
{
"ExpenseSheets": {
"card": {
"cacheInitResponse": false,
...
},
"table": {
"cacheInitResponse": false,
...
}
},
...
}
Type Ahead
Type Ahead is a feature available in table panes which lets the user perform changes, such as adding, editing and deleting lines, or running line actions, without having to wait for a server response after each action. The requested changes are queued and executed in the background.
In some cases, it might be desirable to disable this functionality, or to control how many uncommitted changes a user is able to make. This can be configured using the attributes available in the Typeahead.json file.
Shell
The shell part is the third main area of web client extension, and this refers to the part of the application that surrounds the workspace area after the user logs in. The core configuration covers the sidebar menu as well as documentation (the Help icon), settings, and notifications in the top-right corner.
{
"menu": {
"$ref": "Menu"
},
"documentation": {
"$ref": "Documentation"
},
"settings": {
"$ref": "Settings"
},
"notifications": {
"$ref": "Notifications"
}
}
Menu
The sidebar menu is configured in the Menu.json file. The workspace part of the web client configuration contains the total list of available workspaces. The menu is a subset of these workspaces, ordered in groups. There is no limit to the number of groups nor the number of workspaces within a group. The web client does not allow the use of nested groups, so avoid adding too many groups and workspaces to the menu. Doing so clutters the user interface and makes navigation difficult for the user.
{
"groups": [
{
"T$title": "Self Service",
"items": [
{
"workspace": "WeeklyTimeSheets"
},
...
]
},
...
]
}
Groups have a title property and a list of items. Each item represents either a concrete workspace or a hyperlink. You can assign a title to a specific workspace. The workspace property refers to the internal name of the workspace as declared in the workspace part of the web client configuration. On the other hand, hyperlinks are composed of a title and a URL. Placing hyperlinks in the menu is convenient if access to third-party systems is required.
Groups, workspaces, and hyperlinks have an optional visible property which determines their visibility. To specify this property, you must use an expression. The following example shows an excerpt of a menu where the Employee Information workspace is only visible to users with either the Project Manager or HR Manager role. When specifying a role name.
{
"T$title": "Employee Information",
"workspace": "EmployeeInformation"
"visible": "hasRole('ProjectManager', 'HRManager')"
}
Help Icon and Dropdown
The Help icon expands to a dropdown that is configurable and can include multiple items. The help menu is configured in the Documentation.json file. Each item consists of a title, a URL link, and an optional icon.
You can display items as a simple list or group them into sections. You can also apply a visible property to individual items or to sections.
{
"T$title": "Help",
"items": [
{
"items": [
{
"T$title": "User Guide",
"icon": "fa-solid fa-bookmark",
"url": "https://help.deltek.com/product/MaconomyWebClient/^{maconomyVersion()}/"
},
{
"T$title": "Help Center",
"icon": "fa-solid fa-house",
"url": "https://education.deltek.com/web/maconomy/helpcenter/"
},
{
"T$title": "Reference Guide",
"icon": "fa-solid fa-books",
"url": "https://help.deltek.com/product/Maconomy/^{maconomyVersion()}/GUID-5D2A40A4-FA18-460E-92F8-84D5D332FB2A.html"
}
]
}
]
}
Settings
Settings concern web client language and formatting. Select the language used in the web client from the dictionaries installed on the Maconomy server. To further filter the server list of languages, you can use the couplingconfiguration.mcsl.xml file found in the 'Definitions' folder on the server.
Aside from specifying the preferred language, you need to configure the fixed flag which states whether the user can change the language used. If you set the fixed flag to 'false', the user can change the language on the login screen and in the settings dialog inside the web client. If you set the fixed flag to 'true', make sure the preferred language is actually available from the server. In other words, the web client language configuration must be aligned with the set of dictionaries installed on the server and with any filters defined in the MCSL specification.
Default data formatting is location-specific. This format controls rendering of dates, as well as the decimal separator and digit grouping used. You can edit the preferred location and the settings for that location. You also have the option to assign formatting to a specific location by using the fixed property. The following example shows the preferred and fixed properties in use, as well as a single location configured with a date format, a decimal separator, and a digit grouping system.
{
"preferred": "da_DK",
"fixed": false,
"available": {
"da_DK": {
"date": {
"short": "dd/MM/y"
},
"symbol": {
"decimal": ",",
"group": "."
}
},
...
}
}
You can also configure the optional minutesThreshold property, which determines whether a time entry is interpreted as minutes or hours. The default value is '10', which means that an entry of '10' is interpreted as 10 minutes, and an entry of '11' is interpreted as 11 hours.
Notifications
Use the recalculation object to configure how often the web client retrieves the notifications computed on the server. Specifically, you can use the interval property to configure how often the web client should request the recalculation of a specific user's notifications. You can also set the initialDelay property to configure when the web client should start the recalculation after the user logs in. Both of these properties are specified in minutes. If you make the recalculation interval too short, you risk causing a serious system-wide performance degradation.
{
"recalculation": {
"initialDelay": 30,
"interval": 30
}
}
Enable Employee Pictures
Companies can now opt to display pictures of their employees in the web client. Employees use a third-party web service to upload their image and associate that image with their work email address.
By default, this functionality is disabled.
To enable images in the web client, you must change the default configuration using Extender:
Open the Settings.json configuration file from Application/Shell.
Change the following line to true:
"images": true
If images are enabled in the web client, the application displays the employee avatar image in the top right corner, provided that the Shell.json configuration file is set up to display the user avatar image:
"avatar": [
{
"condition": "isDefined(employeeEmail())",
"url": "https://www.gravatar.com/avatar/^{md5(employeeEmail())}",
"query": [
{ "s": "45" },
{ "d": "404" }
]
},
{
"condition": "isDefined(employeeInitials())",
"template": "^{employeeInitials()}"
},
{
"icon": "icon-contact-nav"
}
]
- To configure images in workspaces, add the following changes to the related configuration file. For example, in Employee Record, add the following changes:
"image": [
{
"condition": "isDefined(ElectronicMailAddress)",
"url": "https://www.gravatar.com/avatar/^{md5(ElectronicMailAddress)}",
"query": [
{ "s": "45" },
{ "d": "404" }
]
},
{
"condition": "isDefined(Initials)",
"template": "^{Initials}"
}
]
The employee image will be displayed if the employee record has an email address with the corresponding third-party image account, Otherwise, if the employee record has initials, a generic image with user initials will be displayed.
The Web Analyzer
This section contains setup instructions and some customization options for the Analyzer report functionality in the web client.
Enable the Web Analyzer
The web.services.analyzer.enabled property in the coupling service server.ini file controls whether the Analyzer web server is enabled. This property is automatically enabled along with other web services when you select the Enable RESTful Web Services check box in the MConfig OSGi products dialog.
Enable Access to the Web Analyzer from the Workspace Client
By default, the Workspace Client still uses the Java Analyzer. Follow these steps to enable the Web Analyzer instead.
To enable this feature:
Perform either of the following steps:
In the MConfig OSGi products dialog, go to the Analyzer type field and select Web Analyzer from the dropdown list.
OR:
In the coupling service server.ini file, edit the value of the
web.services.analyzer.open-analyzer-links-inproperty to web-analyzer.
In the Workspace Client, go to System Setup » Parameters and Numbers » System Parameters.
From the filter list, click the URL for Web Client system parameter.
On the System Parameter tab, specify the URL for your web client application in the URL for Web Client field.
Click Save.
Note: If you have customized reports, you will also need to add them to the web client menu.
Customize Timeout Settings
You can customize timeout settings at the server level, and at the Analyzer level. Ideally, you should set a shorter time period at the server level, and a longer time period at the Analyzer level.
Server Timeout Settings
For instructions on how to configure timeout settings at the server level, refer to the Server Timeout section.
If no Analyzer-specific timeout settings are configured, the web Analyzer follows the server-level setting.
Analyzer Timeout Settings
To customize Analyzer timeout settings, open the coupling service server.ini file and edit the value for the following property:
web.services.analyzer.run-cancellation-seconds = 600
The default value is 600 seconds.
Build Custom Reports
As with legacy view-based reports, you can use universe-based reports to build your own custom reports.
To build a custom report:
Make a copy of the .mul file for the universe-based Analyzer report you want to use as your starting point.
Rename the file and perform the necessary edits.
Add the renamed .mul file to the system under its new name.
Grant access to the custom report workspace.
Add the custom report workspace to the web client menu.
See the MUL section in the Deltek Maconomy Language Reference Guide for more information.
Configure the Streaming of Large Web Analyzer Reports
Current streaming architecture allows users to bypass size restrictions imposed by the server, the coupling service, and/or their browser. However, there are additional settings you can configure to further optimize web client performance when you are generating large Analyzer reports.
The following settings are found in the coupling service settings.ini file:
web.services.analyzer.streaming-run-cancellation-seconds = 3600
- This setting determines the automatic cancellation of streaming reports. If set, it overrides the default SQL cancellation timeout of 300 seconds (or five minutes).
- The default value is 3600 seconds (or 60 minutes).
web.services.analyzer.streaming-run-cancellation-poll-interval-seconds = 10
- This setting determines the polling interval of streaming reports, or how often the server should check if the report currently streaming should be cancelled.
- The default value is 10 seconds.
web.services.analyzer.streaming-run-max-no-of-records = 1000000
- This setting specifies the maximum number of records the streaming reports will fetch for downloaded reports.
- The default value is 1,000,000 rows, but you can specify a larger value.
web.services.analyzer.streaming-max-no-of-concurrent-streaming-report-runs = 2
- This setting specifies the maximum number of concurrent streaming reports that the web client will allow.
- The default value is 2.
- Note: If the customer is using HTTP/2 throughout their system, you can specify a larger number here if needed. Current browsers limit the number of active HTTP(S) connections to about 6 if using HTTP/1.1.
web.services.analyzer.rpc-stream-chunk-size = 1000web.services.analyzer.cs-stream-pipe-size = 100
- These two settings determine the size of the pipes passing data from the Maconomy server to the coupling service and on to the browser.
- The pipes pass data in chunks. For example: Instead of passing one record at a time, the pipes pass 1,000 records at a time.
- Warning: Do not edit these settings unless instructed to do so by Deltek support.
Customize Paging in Finished Web Analyzer Reports
To customize paging in reports for your web client application, open the FinishedReportsFooter.json file under Application/Shell.
Edit the following settings as needed:
{
"noOfRowsPrPages": [10, 25, 50, 100],
"defaultNoOfRowsPrPages": 25,
"noOfPagesPrPageGroup": 5
}
where:
"noOfRowsPrPages"specifies the options available in the items per page dropdown."defaultNoOfRowsPrPages"specifies the number of lines (or items) per page, and the option to which the items per page dropdown defaults. If left unedited, this is set to 25."noOfPagesPrPageGroup"specifies the number of page buttons between the previous and next page arrow buttons.
Customization Procedures
Create a Menu Group
You can create a menu group, and move specific menu items into this group.
To create a menu group:
In the Standard and Solution Files Filter Search field, type the Menu.json filename. You can also specify the file path (that is: Web >> webclient >> [webclient version] >> shell >> menu.json).
In the search results, double-click the Menu.json file for the web client version you want to customize. The Extender opens the Menu.json file.
Click the Copy selected file as extension to active project icon.
In the Menu.json file, look for the "groups" property. You create menu groups under this property. For example, if you want to create a menu group for workspaces used by Time and Expense users, edit the code as follows:
From
{
"groups": [
{
"T$title": "Self Service",
"items": [
{
"T$title": "Weekly Time Sheet",
"workspace": "WeeklyTimeSheets"
},
...
]
},
To
{
"groups": [
{
"T$title": "Time & Expense",
"items": [
]
}
{
"T$title": "Self Service",
"items": [
{
"T$title": "Weekly Time Sheet",
"workspace": "WeeklyTimeSheets"
},
...
]
},
- Select the code for all the workspaces you want to move into the new group. Make sure you include the braces for each workspace object.
For this example, select the code for the following workspaces: Weekly Time Sheets, Daily Time Sheets, Expenses, Mileage, Favorites, Absence, and Purchase Orders:
{
"T$title": "Weekly Time Sheet",
"workspace": "WeeklyTimeSheets"
},
- Cut and paste the selected code inside the brackets of the "items" property in the new menu group you created.
For this example, the code for the new menu group should now read:
{
"groups": [
{
"T$title": "Time & Expense",
"items": [
{
"T$title": "Weekly Time Sheet",
"workspace": "WeeklyTimeSheets"
},
{
"T$title": "Daily Time Sheet",
"workspace": "DailyTimeSheets"
},
{
"T$title": "Expenses",
"workspace": "ExpenseSheets"
},
{
"T$title": "Mileage",
"workspace": "MileageSheets"
},
{
"T$title": "Favorites",
"workspace": "Favorites"
},
{
"T$title": "Absence",
"workspace": "Absence"
},
{
"T$title": "Purchase Orders",
"workspace": "PurchaseOrders"
}
]
}
]
}
Click the Save icon.
To deploy your changes, click the Commit and Push changes to Server Repository icon.
In the window that displays:
a. Fill out the Commit message field with the details of your customization.
b. You can select the Deploy immediately check box.
c. Click OK.
The Extender pushes your changes to the server repository, and displays a progress bar.
In the Deployment success message that displays, click OK.
To view your changes:
a. Pull up the browser window with your open web client system.
b. Hold down the CTRL key, and click Refresh.
Restrict Access to a Menu Group
You can restrict access to a menu group such that it is only visible to users with specific roles.
To restrict access to a menu group:
In the Standard and Solution Files Filter Search field, type the Menu.json filename. You can also specify the file path (that is: Web >> webclient >> [webclient version] >> shell >> menu.json).
In the search results, double-click the Menu.json file for the web client version you want to customize. The Extender opens the Menu.json file.
Click the Copy selected file as extension to active project icon.
In the Menu.json file, scroll down to the menu group to which you want to restrict access.
Add a visible property to this menu group. For example, if you want to restrict access to a newly created Time and Expense menu group such that only users assigned to specific roles can view the workspaces under the group, edit the code as follows:
From
"groups": [
{
"T$title": "Time & Expense",
"items": [
{
"T$title": "Weekly Time Sheet",
"workspace": "WeeklyTimeSheets"
},
To
"groups": [
{
"T$title": "Time & Expense",
"visible": "hasRole('web T&E', 'web Manager')",
"items": [
{
"T$title": "Weekly Time Sheet",
"workspace": "WeeklyTimeSheets"
},
Note: Roles refer to window groups you set up in the Workspace Client.
Click the Save icon.
To deploy your changes, click the Commit and Push changes to Server Repository icon.
In the window that displays:
a. Fill out the Commit message field with the details of your customization.
b. You can select the Deploy immediately check box.
c. Click OK.
The Extender pushes your changes to the server repository, and displays a progress bar.
In the Deployment success message that displays, click OK.
To view your changes:
a. Pull up the browser window with your open web client system.
b. Log out, then log in again.
Remove a Menu Item
To remove a menu item:
In the Standard and Solution Files Filter Search field, type the Menu.json filename. You can also specify the file path (that is: Web >> webclient >> [webclient version] >> shell >> menu.json).
In the search results, double-click the Menu.json file for the web client version you want to customize. The Extender opens the Menu.json file.
Click the Copy selected file as extension to active project icon.
In the Menu.json file, delete the workspace from the list. Make sure you also delete the braces before and after the workspace object.
For example, if you want to remove the Weekly Time Sheets menu item, edit the code as follows:
From
"T$title": "Self Service",
"items": [
{
"workspace": "WeeklyTimeSheets"
},
{
"workspace": "DailyTimeSheets"
},
To
"T$title": "Self Service",
"items": [
{
"workspace": "DailyTimeSheets"
},
Click the Save icon.
To deploy your changes, click the Commit and Push changes to Server Repository icon.
In the window that displays:
a. Fill out the Commit message field with the details of your customization.
b. You can select the Deploy immediately check box.
c. Click OK.
The Extender pushes your changes to the server repository, and displays a progress bar.
In the Deployment success message that displays, click OK.
To view your changes:
a. Pull up the browser window with your open web client system.
b. Hold down the CTRL key, and click Refresh.
Rename a Menu Item
To rename a menu item:
In the Standard and Solution Files Filter Search field, type the Menu.json filename. You can also specify the file path (that is: Web >> webclient >> [webclient version] >> shell >> menu.json).
In the search results, double-click the Menu.json file for the web client version you want to customize. The Extender opens the Menu.json file.
Click the Copy selected file as extension to active project icon.
In the Menu.json file, add a "T$title" property to the workspace object you want to rename. For example, if you want to change the name of the Employee Information workspace to "Employee Info", edit the code as follows:
From
{
"workspace": "EmployeeSelfService"
},
{
"workspace": "EmployeeInformation"
},
To
{
"workspace": "EmployeeSelfService"
},
{
"T$title": "Employee Info",
"workspace": "EmployeeInformation"
},
Click the Save icon.
To deploy your changes, click the Commit and Push changes to Server Repository icon.
In the window that displays:
a. Fill out the Commit message field with the details of your customization.
b. You can select the Deploy immediately check box.
c. Click OK.
The Extender pushes your changes to the server repository, and displays a progress bar.
In the Deployment success message that displays, click OK.
To view your changes:
a. Pull up the browser window with your open web client system.
b. Hold down the CTRL key, and click Refresh.
Customize a Search Filter Name
You can rename the search filters found in some workspaces.
To customize a search filter name:
In the Standard and Solution Files Filter Search field, type the name of the heading.json file for the workspace that you want to customize. You can also specify the file path. For example, if you want to rename the My Open search filter found in the Expenses workspace, search for the ExpenseSheets_Heading.json file, or specify the following file path: Web >> webclient >> [webclient version] >> workspace >> EmployeeSelfService >> ExpenseSheets >> ExpenseSheets_Heading.json.
In the search results, double-click the heading.json file for the web client version you want to customize. The Extender opens the heading.json file.
Click the Copy selected file as extension to active project icon.
In the heading.json file, scroll to the "selection" property. Under this, the "options" property lists the available search filters for a workspace.
Edit the "T$title" property for the search filter you want to rename. For example, if you want to rename the My Open search filter, edit the code as follows:
From
"options": {
"MyOpenExpenseSheets": {
"T$title": "My Open",
"restriction": "not FullyApproved and EmployeeNumber = employeeNumber()"
}
To
"options": {
"MyOpenExpenseSheets": {
"T$title": "My Open Expenses",
"restriction": "not FullyApproved and EmployeeNumber = employeeNumber()"
}
Click the Save icon.
To deploy your changes, click the Commit and Push changes to Server Repository icon.
In the window that displays:
a. Fill out the Commit message field with the details of your customization.
b. You can select the Deploy immediately check box.
c. Click OK.
The Extender pushes your changes to the server repository, and displays a progress bar.
In the Deployment success message that displays, click OK.
To view your changes:
a. Pull up the browser window with your open web client system.
b. Hold down the CTRL key, and click Refresh.
Workspace
The workspace part is the fourth main area of web client extension. It specifies the structure and layout for all workspaces available in the web client. This part represents the majority of web client extension capabilities, since end-users spend most of their time in the workspaces. It has two components: a set of workspaces, and a set of global definitions.
{
"workspaces": {
"Absence": {
"$ref": "EmployeeSelfService:AbsenceMgmt"
},
...
},
"definitions": {
"$ref": "GlobalDefinitions"
}
}
In the Workspace.json file (as shown in the preceding example), the workspaces property is a map of all embedded workspaces, and includes the entire collection of workspaces. The sidebar menu is a subset of this collection.
The definitions property specifies a set of named styles that can be used across workspaces.
Each workspace has a unique name that serves as its internal identifier and an external, localizable title. The contents of a workspace has two main parts: the data bindings and the layout (as shown in the following example). The data bindings is a configuration of the Maconomy containers that provide data for the workspace. These containers are bound together in a tree, similar to how workspace definitions (MWSL specifications) are done for the Workspace Client. On the other hand, the layout is a configuration of how this tree of Maconomy containers is rendered to the end-user. This corresponds roughly to dialog layouts (MDML specifications) for the Workspace Client. The following subsections discuss data bindings and layouts in greater detail.
{
"name": "ExpenseSheets",
"T$title": "Expenses",
"dataBindings": {
...
},
"layout": {
...
}
}
Data Bindings
Copy to come.
Layouts
Copy to come.
Wizards
Copy to come.
Customization Procedures
Rename a Card Action
The web client has several actions available in the card part of each workspace. You can customize the names of most of these actions.
To rename a card action:
In the Standard and Solution Files Filter Search field, type the name of the ActionBar.json file that corresponds to the workspace you want to customize. You can also specify the file path. For example, if you want to rename the Submit action in the card part of the Expenses workspace, search for the ExpenseSheets_ActionBar.json file, or specify the following file path: Web >> webclient >> [webclient version] >> workspace >> EmployeeSelfService >> ExpenseSheets >> ExpenseSheets_ActionBar.json.
In the search results, double-click the ActionBar.json file for the web client version you want to customize. The Extender opens the ActionBar.json file.
Click the Copy selected file as extension to active project icon.
In the ActionBar.json file, scroll to the instance of the "actions" property that contains the action you want to rename. This property lists the actions that you are allowed to customize.
Edit the "T$title" property for the action you want to rename. For example, if you want to rename the Submit action, edit the code as follows:
From
"actions": [
{
"T$title": "Submit",
"source": "SubmitExpenseSheet"
},
To
"actions": [
{
"T$title": "Submit My Expense",
"source": "SubmitExpenseSheet"
},
Click the Save icon.
To deploy your changes, click the Commit and Push changes to Server Repository icon.
In the window that displays:
a. Fill out the Commit message field with the details of your customization.
b. You can select the Deploy immediately check box.
c. Click OK.
The Extender pushes your changes to the server repository, and displays a progress bar.
In the Deployment success message that displays, click OK.
To view your changes:
a. Pull up the browser window with your open web client system.
b. Hold down the CTRL key, and click Refresh.
Rename a Field
To rename a field:
In the Standard and Solution Files Filter Search field, type the name of .json file for the part of the workspace that contains the field you want to rename. You can also specify the file path. For example, if you want to rename the Total Amount field found in the card part of the Expenses workspace, search for the ExpenseSheets_Card_Row.json file, or specify the following file path: Web >> webclient >> [webclient version] >> workspace >> EmployeeSelfService >> ExpenseSheets >> ExpenseSheets_Card_Row.json.
In the search results, double-click the .json file for the web client version you want to customize. The Extender opens the .json file.
Click the Copy selected file as extension to active project icon.
In the .json file, scroll down to the "column" property for the column that contains the field you want to rename.
Edit the "T$title" property for the field you want to rename. For example, to change the name of the Total Amount field to Full Amount, edit the code as follows:
From
"unitField": {
"T$title": "Total Amount",
"source": "AmountBase",
To
"unitField": {
"T$title": "Full Amount",
"source": "AmountBase",
Click the Save icon.
To deploy your changes, click the Commit and Push changes to Server Repository icon.
In the window that displays:
a. Fill out the Commit message field with the details of your customization.
b. You can select the Deploy immediately check box.
c. Click OK.
The Extender pushes your changes to the server repository, and displays a progress bar.
In the Deployment success message that displays, click OK.
To view your changes:
a. Pull up the browser window with your open web client system.
b. Hold down the CTRL key, and click Refresh.