Fielden Management Services Web viewEnhancement requests and queries can ... The above image depicts the expanded Wiki Pages section of the incident ... Replace :colour_green” with

Fielden Management ServicesR-148 Web/Python Investigation5250 Implementation of stand-alone web-based call centre and timesheet system

WeBaCC2 User DocumentationRevision: 7

Date: 18-May-2011

Copyright Fielden Management Services 2023

Revision HistoryRev Date Description Author(s)

0 20-Jul-2010 initial revision R1 16-Aug-2010 Updated to reflect mainly visual design changes R2 06-Oct-2010 Added a section on the wiki. R3 22-Oct-2010 Added a section on the close milestone facility. R4 31-Mar-2011 Added a section on saved searches. R5 03-May-2011 Enhanced the milestone section to include the milestone testing facility R6 09-May-2011 Altered the milestone incident testing facility to reflect recent changes in

this area.R

7 18-May-2011 Describe the email requirements in more detail. Included a section on SLA. R

Copyright Fielden Management Services 2023 Page 2 of 82

Table of Contents

Revision History............................................................................................................2Table of Contents..........................................................................................................3Document Navigation....................................................................................................4Abstract.......................................................................................................................5WeBaCC2 User Documentation......................................................................................5

Getting started – create a new password.........................................................................................5Logging in to WeBaCC2..................................................................................................................11The menu....................................................................................................................................... 12Reporting an incident via email......................................................................................................16

Specific email requirements..........................................................................................................................18Asciano-specific email requirements........................................................................................................18Other [non-Asciano] client email requirements........................................................................................21

Following the progress of an incident...........................................................................................................22Finishing incidents..........................................................................................................................37Milestones......................................................................................................................................40

Closing a milestone’s incidents.....................................................................................................................46Entering test information for a milestone’s incidents...................................................................................48

Incident list.....................................................................................................................................57User-defined saved searches........................................................................................................................58

Reports...........................................................................................................................................64Wiki............................................................................................................................65

Creating and editing pages.............................................................................................................65Incident-related wiki pages.............................................................................................................75Markmin markup syntax.................................................................................................................79

SLA – Service Level Agreements...................................................................................80


Document Navigation

Use the Table of Contents (on the previous page) to navigate to each section by Ctrl-clicking the required section (i.e. click on the section title in the Table of Contents while holding down the Ctrl key on the keyboard). Alternatively, and as recommended, turn on the Navigation Pane in Microsoft Word by selecting View from the menu, then check the “Navigation Pane” option. This is illustrated below. The navigation pane provides a quick, efficient and simple way of navigating between the different sections of the document.


Abstract

WeBaCC2 is the FMS Web-Based Call Centre, version 2. This document provides an overview of WeBaCC2 from a user perspective.

WeBaCC2 User Documentation

Getting started – create a new password

Upon being assigned a WeBaCC2 account in order to undertake support activities, you should setup an initial password. This is achieved by visiting the WeBaCC2 site and providing the email address with, which your account was created.

The URL is: http://www.fielden.com.au/callcentre

Note that the illustrations in this document use a different URL, that of the development system. The above URL should be used by all users.

Visiting the WeBaCC2 URL will display the index page. In the upper right corner is a “login” link (just under the “Welcome to WeBaCC2i3” message) that should be clicked to initiate the login process.


http://www.fielden.com.au/callcentre

Before the first login, you will need to click the “lost password” link in order to setup your initial password. This appears below the fields on the login form.


When resetting a lost password, or creating an initial password, you must supply the email address with, which your account was registered. An email is sent to this account with instructions on resetting your password.

After entering the email address and clicking the Submit button, if the email address is recognised an email will be automatically sent, and you will be returned to the login page.


Depending on the frequency of your email delivery, the email should arrive immediately or at least within a few minutes. The email, such as above, contains a link, which should be clicked or copy/pasted into your web browser.


The link resolves to a page where a new password can be specified. The new password must be entered twice to avoid problems caused by mistyping.

Note that passwords are complex in order to protect your WeBaCC2 account from malicious tampering by sinister miscreants. Passwords must:

contain at least 8 characters must include at least 1 of the following : ~!@#$%^&*()_+-=?<>,.:;{}[]| must include at least 1 upper case must include at least 1 number

Some common tricks to help remember a password are to replace characters with digits or symbols that appear similar to those characters, for example to replace “S” with “$”, “O” with “0” and “a” with “@”. An example of a valid password would be P@ssw0rd - it contains 8 characters, an “@” sign from the list of special characters, an uppercase “P” and the digit “0”. It is not recommended that you use this password.


mailto:P@ssw0rd

After resetting your password, you will be returned to the login page.


Logging in to WeBaCC2

Enter the username (noting that usernames are case-sensitive and are all UPPERCASE) and the new password (or your old password if you are a returning user). Clicking the “Remember me” checkbox will keep the session cookie valid for up to 30 days. Clicking the “Submit” button will log you in.

Once logged in, a “logout” entry appears near the top right corner of each page (where the “login” link was, and can be used to terminate a WeBaCC2 session. Otherwise an idle session will timeout after approximately one hour (if the “Remember me” checkbox was not checked during login).


The menu

After successful login, the index page will be displayed. You can return to the index page from any other page by clicking the “Index” link to the left of the main menu.


The Search link on the main menu will display the search form, which allows searching all incidents by the following criteria:

Incident no./Client.Ref. allows searching if you know the incident number, or your own reference number (if that reference number has been recorded against the incident).

From date places a limit on the date range of incidents that match the other criteria.

To date places a limit on the date range of incidents that match the other criteria.

Description does a partial case-insensitive match on incident descriptions (long and short descriptions). It is recommended to search for only one word in this field.


The Incidents menu entry drops down to a submenu where options can be selected to enter a new incident, review milestones (a milestone typically relates to a release) and pre-defined incident selections can be chosen.


The Reports menu drops down to a submenu where options can be selected to run various online reports (at the time of writing only one report is available).


Reporting an incident via email

During a hypothetical working day, a problem occurred with T32, and the need arose to create an incident. Most typically incidents are created via email, sent to the specific support email address for your organisation (, which will have been advised to you in the same email advising your WeBaCC2 account name).

Note that the example below uses the test email address - you should send emails only to the support email address that you have been advised.

An ideal email to raise an incident should have a meaningful subject line, a brief but accurate description, and attachments to illustrate the problem. Enhancement requests and queries can also be sent via email – each will generate a new incident that can be independently tracked, and it is better to send multiple emails for a series of different problem rather than combine multiple different elements into one email.

In some cases it is necessary to specify a subject line in a particular format. If this is a requirement, your site champion should be able to provide you with example subject lines, or it may have been explained in the email advising your WeBaCC2 user name. Specific examples of mandatory subject line formatting are contained below. Where subject line format is a specific requirement, submission of an email with an incorrect subject line will usually result in a bounce email. The bounce email should include examples of what the correct subject line format is. If you do receive a bounce email due to an invalid subject line, please note that the email will have been delivered to all FMS business analysts and management anyway.


An incident will be generated automatically, and a confirmation email sent back to you advising the incident number. The above example confirms creation of incident 10778.

An incident number must be quoted in all email correspondence regarding that incident, and any such emails should be sent to the support email address so that they can be cross-referenced to the correct incident (see below for more information).


Specific email requirements

Asciano-specific email requirements

When reporting a new case or sending an email discussing an existing case, the following subject line format is required:

infraEnterprise External Call Requiring Action <call number> : DB : InfraProd

The <call number> should be replaced with the correct infraEnterprise call number, for example:

infraEnterprise External Call Requiring Action 209401 : DB : InfraProd

For example, the above email was received to create a new incident to correspond to infraEnterprise call 209401.


Incident 11808 was automatically created as a consequence, and the above email returned to Asciano advising the new incident number, and also the correct subject line to use in further correspondence regarding this case.

WeBaCC2 parses the subject line of incoming emails, extract the infraEnterprise call number, and then search to see if it is already associated with an incident. If no matching incident can be found, a new incident will be created and a return email (as above) sent advising the new incident number (and also reminding the correct specific email subject line for this new incident).

When sending an email to automatically close an existing incident, the following subject line format is required:

infraEnterprise External Call Requiring Action <call number> : DB : InfraProd : Your Incident has been Closed

There are no specific requirements for the body of the email.


For example the above email was sent from Asciano in order to close incident 11808.

Note that each email can be cross-referenced to only one incident. If an email relates to multiple incidents, it will need to be sent once for each incident, with the subject line of each email containing the respective infraEnterprise call number.


Other [non-Asciano] client email requirements

When reporting a new incident, a short but meaningful subject line is recommended. The “incident:” tag (described immediately below) should be omitted from the email body.

When sending an email discussing an existing incident, the “incident:” tag should be included in the body of the email to ensure that the email can be cross-referenced to the correct incident. This tag is typically included on the first line of the email, for example:

incident: 12345

Dear Support,

The following information has come to light since …

The incident tag must consist of the following:

The literal string “incident” (it is not case-sensitive, “incident” and “Incident” are equivalent) A colon “:” A space “ “ The correct incident number (12345 in the above example)

Note that there is no space between the word “incident” and the colon “:”, and that apart from the incident number nothing else should appear on that line. There can be multiple incident tags in a single email (each on a separate line), and the email will be cross-referenced in WeBaCC2 to each distinct incident that is specified.


Following the progress of an incident

Accessing WeBaCC2 after receiving the incident creation confirmation email and searching for the specific incident number is illustrated above. If you have your own reference number and cannot recall the incident number, typing your reference number into the “Incident No./Client Ref.” field will search on the client reference number rather than the incident number.

The from and to dates can be used to limit the number of incidents returned when searching by description, especially when common words are searched.


A list of matching incidents is displayed (more than one incident will be displayed if a description search matches multiple incidents, but a search for a specific incident number will return at most one incident). Clicking the incident number will open the incident details page.


The incident details page contains a number of sections, each of, which is collapsible. The page opens with the “Incident Details” and “Status/Progress” sections expanded, and all other sections collapsed. A section can be expanded or collapsed simply by clicking the section heading e.g. “Status/Progress”.


The above image depicts the same incident with the Comments and Attachments sections expanded (and the page scrolled down slightly).

Each section on the incident details page contains a table of information, with action links to the right (such as insert, view or download).


Viewing an attachment by clicking the “view” link next to the attachment will open a page displaying the contents of the file. Emails are stored as text files and are viewed inline. Many other types of text files (e.g. SQL scripts, CVS files) can also be viewed inline. Most image types are also viewed inline. Other files, such as proprietary binary document files, cannot be viewed inline, however they can be downloaded (by clicking the respective “download” link) and viewed using a proprietary file viewing utility.


The above image depicts an image attachment being viewed inline.


Selecting “Action” and then “Detailed History” from the main menu, results in the detailed incident history being shown. The above image depicts the start of the detailed chronological history for the incident. Typically the first entry in the list will be the email that caused the incident to be created.


The above image depicts the bottom of the detailed chronological history for the incident. In this example the incident has not seen much action, so the email attachments appear as the most recent entries.


The above image depicts editing the incident. Only selected attributes of the incident can be changed. Most of these edits will be performed by FMS staff, typically by the business analysis to whom the incident is allocated.


Meanwhile, in the background, wheels turned, events transpired, and the incident was allocated to a business analyst who commenced analysis. The above image depicts the updated incident short description, allocation and status.


And the detailed history page reflects the recent edits.


After business analysis, the results are forwarded via email by the business analyst, quoting the incident number and copied to the support email address (note again that this is the development email address – you should use the support email address you have been advised).

Note that any replies or communication you send regarding an incident should generally be sent to, and only to, the support email address you have been advised. Emails sent thusly will be copied to all FMS business analysts and management, as well as a copy being forwarded to WeBaCC2. In the event that you mistype the incident number (or subject line in some cases), you will receive a bounce message, however the email will still be delivered to all FMS business analysts and management.


Reviewing the incident details shows that the incident has been transferred.


Expanding and reviewing the lower sections of the incident details page shows a new comment, and a new attachment corresponding to the above email.


Reviewing the detailed history shows the historical changes in chronological order, including the status change, the new comment, and the new attachment.


Finishing incidents

Assuming that the problem is resolved (or the query answered or the enhancement implemented), you would login to WeBaCC2 and finish the incident to indicate acceptance of the changes. This is achieved by clicking the “status change” link on the incident details page.

Clicking the status change link shows the status change page, where each possible status change is shown in a separate section. In this case the incident has been transferred, and can now progress back to programming (if the change does not address the situation raised in the original email), or to finished (if the change is acceptable and the incident can be finalised). In this example the incident will be finished.


The incident details page now shows that the status is “finished”, and also shows the extra new comment. The detailed history page would also show these changes.


Typical incident status progression is as follows (rows in italics are status changes performed by FMS staff):

Event Status Code

Description Comments

Incident created W4 Waiting – not allocated to programmer

Default status code for all new incidents

Business analysis commences P Programming Business analysis commencesQueries about the change W2 Waiting – no specification

etc.Business analysis of the specification raised queries that must be answered by the client

Responses, received, analysis continues

P Programming Once the business analyst has received a response to the queries

Quotation forwarded to client for approval

W3 Waiting – quoted no purchase order

Waiting for the client to provide a purchase order

Purchase order received P Programming Changes being implementedChanges completed T Transferred Changes committed and/or made available

for client reviewChanges accepted F Finished Changed by the client to indicate acceptance

of the changesIncident completely finished C Closed No further changes possible

Additional status codes do appear from time to time, such as:

Status Code

Description Comments

X Cancelled If a change is requested and subsequently becomes not required, the incident would be cancelled.

W1 Waiting – placed on hold by client

If a change does not fit within the client’s budget for this month, or the client representative requesting the change is on extended leave

W5 Waiting – no FMS approval The incident is waiting for internal FMS approval e.g. approval of an estimate

A simple, but also very common, incident status progression is from W4 -> P -> T -> F -> C (waiting – not allocated to programming -> programming -> transferred -> finished -> closed). In this case there were no queries about the specification and no quotation/approval step to go through.


Milestones

The milestone facility is intended primarily to assist in the management of releases. A milestone consists of one or more incidents typically targeted at a planned release date. Each incident can be assigned to one milestone, and assignment of an incident to a milestone by either FMS or by you will indicate to all concerned that the specified release should contain the changes associated with that incident.

Assuming that the above example was to be included in a special SQL-only release, the first step would be to create a new milestone (usually milestones are created only for a release containing more than one change).

Initially there are no milestones. Selecting Action – New Milestone from the main menu will show a page to allow creating a new milestone.


The milestone details are specified and Submit clicked.


One milestone now appears in the list of milestones. Over time a collection of historical milestones will be created.


Clicking the “view” action link to the right of the milestone shows that there are no incidents in the milestone,


Searching for the example incident and editing the incident allows the incident to be assigned to the milestone (by means of the Milestone dropdown at the bottom of the form, as shown above). Clicking Submit will save the changes.


Reviewing the milestone details again shows that one incident has been assigned to the milestone. The various executive summaries provide an indication of milestone readiness.


Closing a milestone’s incidents

Continuing with a slightly different example, the milestone facility also provides a “close” action that allows all incidents associated with a milestone to be closed. Typically once a release is completed and accepted by the client, the client will signal acceptance of the release by promoting the release into their production environment and closing (finishing) all of the associated incidents. Rather than searching for, and updating, each incident individually, the close milestone facility speeds this process.


Once the “close” action link is clicked, a page similar to the milestone details is shown. Each incident (that is not already finished, closed or cancelled) has a checkbox in the Select column that can be checked to indicate that that incident can be closed. Once all required incidents are selected, the “Close selected” button should be clicked, upon, which the selected incidents will be finished (effectively closed, barring any last minute administrative overheads).


Entering test information for a milestone’s incidents

The milestone area provides the facility to record test results for incidents assigned to a milestone. This is accessed by a “test” link in the Action column on the milestone details page.

A milestone with several incidents was located. None of the incidents was transferred, and the “Needs Testing” column was “no” in all cases.


After some time two of the incidents had been addressed. The second incident was transferred, but did not require testing. The third incident was transferred and did require testing.

Note that the “Needs Testing” column for the third incident indicates “yes”, the “Tested” column indicates “no” i.e. that the incident has not been tested.

Note also the “test” action link to the right of the third incident. This only appears if an incident is transferred and needs testing.


Clicking the “test” action link displays a form where test results can be entered. The top section of the page summarises the milestone. The middle section summarises the incident. The bottom section is the test results form. All fields default to blank, except “Tested by”, which defaults to your login id, and “Tested in”, which can be one of three values (and defaults to the alphabetically first).


The above image depicts the form reflecting that a test was performed and did not pass. The “Test completed” checkbox must be checked to indicate that the test was actually performed. An alternative user can be selected if you are entering test results on behalf of someone else. The date the test was performed is recorded.

“Tested in” indicates the environment where the test was undertaken, and serves as a double-check that the correct release was being tested. The ”Tested release” serves as a triple check.

If the “Test passed” checkbox is checked, it indicates that the test has passed, and no further input is required. A comment can be entered into the textarea below, and will be treated simply as a comment. It is optional.

If the “Test passed” checkbox is not checked, it indicates that the test did not pass. In this case a “Reason test did not pass” comment must be entered into the textarea, and should briefly describe why the test did not pass (although following this up with a more detailed email is a good idea).

Finally click the “Submit Query” button (, which might be renamed at some stage) to submit the test results.

Note that if the “Test passed” checkbox is not checked (as in this example) indicating that the test did not pass, the incident status will automatically be changed back to “P” (programming). In either case any text entered into the textarea will be added as a comment, and the business analyst to whom the incident is allocated will receive a notification email.


The above image depicts the milestone detail page after the form was submitted indicating that the test did not pass. Note that the incident status has changed (automatically) back to “Programming”, and that “Tested” indicates “yes” and “Test Passed” indicates “no”.


In this example sequence, further changes are done and the incident is transferred again. In a real life scenario a test build will be placed into the testing environment for your review. The above image shows the state of the incident in the milestone – i.e. that the status is again “Transferred”, and the “Needs Testing” flag is “yes”. A visual clue that this incident needs retesting (as opposed to testing) is that the other test fields are already populated, and the “Test Passed” column indicates “no” – that the previous test did not pass.


Continuing the example, the “test” action link was clicked. Note that a detailed indication of the previous test results is included in the line “This incident was last tested on …”.

The form was filled in to indicate that the test had passed. In this scenario the “Test passed” checkbox is checked and, as the comment is optional, nothing else was entered. The form was again submitted.


This time the milestone summary shows that the test has passed.


Clicking the “test” action link allows the detailed test information to be reviewed. In this case the “This incident was last tested on …” line clearly indicates that the test passed.


Incident list

Under the Incident menu are a number of sub-menu entries, such as “All finished”, “My finished” and so on. Each of these opens the incident list page with a pre-configured selection criteria in place. In the above example Incidents – All Finished was selected, and a list of all finished incidents appears.

This list can be used to priorities incidents, plan milestones, perform routine reviews of outstanding incidents, see where bottlenecks are, and summarise the number of incidents reported by user (to find the keenest users) and request type (to find particular problem areas that might benefit from operational review or training).


User-defined saved searches

The facility exists to save a set of selection criteria for later recall.

Search criteria are saved by visiting the incident status page with any existing selection. The above example uses the “My Active” selection, showing active incidents created by the logged in user.


The selection criteria can be altered to suit the requirements (in this example the “Repeat col headings” checkbox was checked, although a more complex selection could be made if there was a greater variety of incidents).

Most importantly, a description was entered into the “Save as” field. This description must be between 1 and 32 characters in length, and should briefly describe the selection criteria in a way that will be meaningful to you later on. The relatively short description is to avoid polluting the Incidents menu, where the saved searches later appear, with excessively verbose descriptions.

Clicking the Refresh button will execute the query with the specified selection criteria, display the resulting set of incidents, and save the selection criteria with the name specified.

Due to the way in, which the menu is generated before the query is processed, the new saved search will not immediately appear on the Incidents menu. However visiting any other page, or even just refreshing the query again, will regenerate the Incidents menu including the new saved search.


User-defined saved searches appear at the bottom of the Incidents menu, and are sorted in ascending ASCII order (i.e. sorted in a case-sensitive manner). Thus it is a good idea to always start the descriptions with an uppercase character, or always start the descriptions with a lowercase character.

A previously saved selection can be rerun at any future time by simply selecting it from the Incidents dropdown menu.

Note that if there are too many saved searches to fit on the screen, behaviour may be browser-dependant but tests with some leading web browsers has shown that the Incidents dropdown menu extends past the bottom of the page, a scrollbar appears to the right of the page (if not already there), and saved searches lower in the list can be accessed simply by scrolling the page with the mouse wheel.


Selecting Incidents – Saved Searches from the menu displays the above page, where your previously saved searches can be reviewed. This page shows a summary of the selection criteria saved for each search.


Clicking the edit action next to a saved search displays the above page, where the description can be changed, or the “Check to delete” checkbox can be checked (and the change Submitted) to delete the saved search.

See below for information on how to edit the selection criteria associated with a saved search.


To change the selection criteria associated with a saved search, simply select the saved search from the Incidents menu, which will execute the query once with the original selection criteria and display the name of the selected saved search in the “Save as” field.

Then change the selection criteria to match the new requirements, but leave the “Save as” name the same as it was before.

Finally refresh the query.

This will run the revised query and save the altered selection criteria, overwriting the previous saved search.

If you do this but specify a new “Save as” name, a new saved search will be created with the revised selection criteria, and the old original saved search will still exist with its original selection criteria. In this situation the old one can be deleted from the Incidents – Saved Searches page if it is no longer required.

When changing the selection parameters of a saved search, care must be taken to blank the “Save as” field if the revised selection criteria are not to be saved.


Reports

At the time of writing one report, the Client List, is available for user review.

The user Roger has access to two project, 1-888 and R-148. The number of incidents at each status is shown, and the project code is a link to the incident list page, which will be pre-filtered by project code to show active incidents.


Wiki

WeBaCC2 includes a wiki facility. A wiki is a series of potentially connected pages that can be created and edited by anyone with sufficient permission to access the pages. Links between pages are handled in a semi-automatic manner, and the formatting of text within each page is controlled by a series of codes (known as markmin).

Creating and editing pages

Upon first visiting the Wiki page (by clicking the Wiki menu entry), there may be no pages listed (depending on what access you have to any existing pages).

To create a new page, select “New Page” from the Action menu.


The above image depicts creation of a new wiki page. The following fields should be populated:

Title The title of the page. This is used to sort pages in the Wiki page list.Uri A uniform resource identifier – used to uniquely identify this page. A URI consists of only lower case

alphabetic characters and minus signs ‘-‘. WeBaCC2 will translate whatever is entered into the equivalent URI, and it is common practice to copy/paste the title into the URI field. URIs are also used to link pages together, so a short but meaningful URI is best.

Content The content of the page. As much content can be specified as required.Readers A broadly defined set of users who can view the page. Everyone means everyone. “FMS only” means only

FMS users. “Only me” means only you. “Only me” can be used for draft pages or your own private pages.Writers A broadly defined set of users who can edit the page (with the same classifications as for readers).

Clicking Submit will submit the new page and, if it passed validation (e.g. unique URI) the page will be saved.


The above image depicts the new page appearing in the list of pages. Note the URI as constructed from the title. If a user has permission to read the page, it will appear in this list and can be viewed. If a user has permission to a the page, the Action column will include an “edit” link.


Viewing a page will render the page in all its formatted colourful glory, as the example above, which includes a heading, some blue text and an unordered list. As the user has permission to edit the page, an “edit this page” link appears near the bottom of the page. Also near the bottom of the page is a revision history, where any historical revision of the page van be viewed by clicking the “view” link next to the required historical revision.


Either clicking the “edit” action in the page list, or clicking the “edit this page” link near the bottom of the page view will allow the page contents and all attributes except URI (the URI is used to link pages, and changing the URI could break page links).

Note in the above image that the “help with markmin syntax” link has been clicked to expand a quick summary of markmin syntax.


The above image shows the complete markmin summary (the markmin syntax is explained in a little more detail below).


The above page is edited, the “Wikis are fun!” text is made bold, and a link is added to a new wiki page. Upon saving, the page is automatically viewed, as shown above. The new link “our second page” can be seen in the content, and the revision history now indicates the recent change as well as the page creation.


Clicking the “our second page” link results in the above page, indicating that the specified page could not be found and providing a form to allow creation of the page.


In order to satisfy the link, a dummy page is created. Note that the URI cannot be specified as it was passed from the higher level page. Note also that the page title is defaulted based on the specified URI. Thus there is generally a correlation between page title and URI (although this is not required).

As this is a private dummy place-holder page, the readers and writers are set to “Only me” so that other users will not be able to provide their own page content until we have finalised the original draft of this page.


The above image depicts the wiki page list showing both pages. Another user would see only the first page.


Incident-related wiki pages

A wiki page can optionally be cross-referenced to an incident. This is achieved by creating the wiki page from the incident details page, via the insert action in the Wiki Pages section.

Initially an incident will have no wiki pages cross-referenced to it.


Clicking the insert link (shown near the bottom of the previous image) will allow creation of a new wiki page cross-referenced to the incident. Note that the incident number and descriptions are displayed in the above image.


The above image depicts the expanded Wiki Pages section of the incident details page with the newly created wiki page evident. Note that the readers and writers settings for the wiki page also work here – if “only you” can read the wiki page then no-one else will see that wiki page listed in the incident details.


Viewing a wiki page that is cross-referenced to an incident will display the incident number and descriptions above the wiki page contents. Note that the incident number is a link to return to the incident details page.


Markmin markup syntax

Markmin syntax is simple, but allows creation of reasonably content-rich pages. The following elements are provided:

# title Displays a title in a large bold font.## subtitle Displays a title in a slightly smaller bold font.### subsubtitle Displays a title in an even slightly smaller bold font.**bold** Placing two asterisks around text will render the text as bold.‘’italic’’ Placing two single quotes (‘) (not a double-quote) around text will

render the text in an italic font.``code`` Surrounding text with two grave accents will render the text as a code

i.e. the text will be rendered in a fixed pitch font in green on a black background.

[[a link to an external site http://example.com]]

You can link to an external page by placing a URL in double square brackets and preceding the URL with the text of the link.

[[a_anchor]] This defines an anchor in the current page i.e. marks a place in the text so allow a link to jump directly to this section of the text e.g. from a table of contents within this page).

[[a link to #a_anchor]] Links to an anchor in the current page (perhaps you would have a series of these links in a table of contents at the top of a page, and the anchors defined lower in the document).

[[a link to another wiki page page:uri-of-page]]

Allows linking to another page. As with the external links above, use square brackets and link text, but instead of a conventional URL, specify “page:” followed immediately by the URI of an existing page, or of a new page. If someone clicks on such a link and the page does not exist, they will have the opportunity to create the page.

- an- ordered- list

An unordered list – basically just a bullet point list of items.

+ an+ ordered+ list

An ordered list i.e. a numbered list of items,.

-----blockquote-----

Quotes a block of text, introducing margins and renders it on a gray background.

-----green text-----:colour_green

Renders the specified text “green text” in green. Replace :colour_green” with “:colour_blue”, “:colour_orange” or “:colour_fuchsia” (being the standard colours that are used in FMS query documents).

-----1 | 23 | 4-----

Defines a table, in this case with two rows and two columns. Each vertical bar should have a space on either side. A table will render unusually if it is the last element on a page, so ensure that a line with some content, even just a full stop, follows a table.


http://example.com/

SLA – Service Level Agreements

SLA (Service Level Agreement) is facilitated within WeBaCC2 by the recording of the time to respond and the time to repair for each incident. These are summarised and reviewed on a regular basis at a management level by an SLA Report.

Upon an incident being created, there is initially no basis upon, which to calculate the time to respond and time to repair.


Once business analysis has begun on an incident, the incident status is changed by an FMS business analyst to “P” (programming). This automatically calculates the time to respond as the difference between when the incident was reported and when the business analysis commenced. This figure is displayed on the incident details page.


Once the matter reported in the incident (be it an enhancement request, data adjustment or other) is resolved, the incident is transferred by the business analyst (the status is changed to “T”), and the time to repair is calculated as the difference between when the business analysis commenced, and when the incident was transferred. This is also displayed on the incident details page.


Documents

Fielden Management Services Web viewEnhancement requests and queries can ... The above image depicts the expanded Wiki Pages section of the incident ... Replace :colour_green” with