View source for FS 291227 PROD Supimix Web Client

<div class="noprint">
{{#vardefine:Client|PROD}}
{{#vardefine:ClientName|OBS}}
{{#vardefine:System|''CALIDUS'' Supimix}}
{{#vardefine:Doc_Title|Supimix Web Client}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|3rd Jan 2012}}
{{#vardefine:Reference|291227}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
}} 

<!-- TOC --> 
<div class="noprint">
= Functional Overview  =

== Client Requirement  ==
The Client (being potentially all OBS clients), DHL will need access to the Supimix system allowing for easy logging of TIDs and potentially other calls.

They will require access to view log activity only.

== Solution Overview  ==
A ASP .NET solution has been developed. This has gone through several revisions, and now remains at v0.1.

== Scope  ==

<!-- NEW PAGE --> 

= Set-up  =

== Pre-requisites  ==
*IIS
*.NET Framework 4.0
*Informix SDK installer

== Menu Structure  ==

== Data  ==
This runs from the Informix database hosted on Steel.

== System Config ==

The host machine requires the following configurations:
* Installation of Informix Client SDK version 3.70 xC1
* Network access to steel
* Services adding for the Informix TCP/IP services 

 sqlexec          1528/tcp                           ---No Longer Needed
 informix1        1529/tcp                           #Informix server

* IIS
* .NET 4

<!-- NEW PAGE -->

= Functional Description  =

== System Functionality == 

The system provides the following functionality:
*User access restrictions 
** OBS users can access everything and can log/update calls for all clients.
** Client users cannot update calls and can only view log relating to their client.
*Call logging
*View and update call details
*Attach files relating to the log
*Email based on events (status updated, details updated ect)

== User Access ==

The Web Client provides user access control, limiting users access to Supimix's content based on the users account settings.

The users account must exist both as a member of staff within supimix with a client flag set and a record within the Web Support table which holds their access details and level. Internal users will require this configuration as well.

Access will initially be given to Julie Scott, Julie Ann Taylor, Peter Greer and myself for testing purposes. 

Once released to production, Peter Greer will specify the users to be given access.

Access from the application to the Steel machine and Database will be setup using a specified netowrk user account.

 To add users to the system:
 *Create a new staff record
 *Run the following sql against the Steel DB, replacing all fields marked with *, with the relevant values.
  
 "INSERT INTO websupport_users (wu_client, wu_project, wu_site, wu_product, wu_user, wu_pass, wu_name, wu_contact)
  VALUES ('*client*','*project*','*site*','*product*','*user*','*password*','*name*','*contact')";
 
 Note: Only the client field is used by the system at this time.

== Testing ==

Internal testing has been completed using the SEC client within supimix.

Testing for the Client aspects of the system will be compelted externally by Peter Greer, this will include UAC testing.

First Call testing for the purpose of internal use (helpdesk) will be preformed by Julie Ann Tayor.

== Test to Production ==

Once the current version of the system has been approved both internally (no bugs found during external texting) and externally (UAC), the system will need to be migrated from the testing environment to a production machine with external web access, ideally hosted under a OBS domain.

== Migration of Other Web Systems ==

Functionality provided in other web system will need to be identified and migrated. During this phase any additional functionality required will need to be assessed.

== Basic requirements for WEB Supimix for ease of logging for Firstcall (OBS Helpdesk) - JAT ==

Facility to;
*Add a new incident
*Update an incident
*View an incident

=== Ability to log ‘new incidents’ ===

*Populate default values where possible dependent on client code entered ie support queue and product code.
*Populate default values dependent on site code entered ie project, job codes.
*To provide drop down list for easy entry (using current supimix maintained tables).
*To have the facility to send automatic external emails for new call confirmations, with date/time stamped records written to supimix as proof.  Using standard text template from current supimix version.  Auto close any prompt windows on email delivery, ensure status text is also displayed in header section ‘Call confirmation has been sent’
*To have the facility to send automatic chase emails to the user id currently assigned the call, with date/time stamped records written to supimix as proof.   Using standard text template from current supimix version. Auto close any prompt windows on email delivery, ensure status text is also displayed in header section ‘Chase has been sent’
*To have the facility to write records to supimix on ‘passing a call’ out of hours.  Date/time stamped when the call was handed over to and accepted by the support analyst on call.  Auto close any prompt windows on update, ensure status text is also displayed in header section ‘Passed to oncall’
*On completion of logging a new call, display summarised call information for ease of entry into forwarding email subject (for copy&paste) displayed as ‘client code:priority:site:log number:reference’ eg EXL:4:COV:294250:EARS00031823587
*New call Alert emails must be automatically sent to OBS support queue once logged  triggered by default support queue in point 1 above.
*Audit History record is required  for new call status Logged and Confirmed – the audit record written is to include date, time, who, type.
*Call details should be displayed in record date/time order showing call history from earliest entry (call logging) to latest entry (call closure).
*Ability to cancel a call half way through logging.
*Ensure all display text is correctly formatted and justified.
*Ensure OBS logo and OBS Helpdesk contact details are displayed in each of the screens.

===Ability to ‘update’ incidents===

*Update action should display the same screen  familiar with during ‘new call entry’
*Record/Field updates should prompt for details (narrative) to be added by the user, thus providing a full history of the call.
*Updates of status, substatus, assigned, priority, call type must all have audit history records written along with ‘passed to oncall’ and ‘chase’ actions – this audit record should include date, time, who, type, old value, new value.  NB: Important for month end statistical reporting.
*Also requires call confirmation, chase and passed to on call facility.

===Ability to ‘view’ incidents===

*Introduce a new ‘search’ screen to allow the user to search for an incident uniquely by OBS Log number, or via reference number (with wildcard search) or client/date range.
*On selection, a list of ‘matching’ records should be displayed to the user, allowing sort action on each field value displayed.
*OBS log number should be manually selected and user taken to ‘Update Calls’ screen allowing any updates if required.


===Important points to highlight===

*Check session inactivity period settings.
*Multiple logins should be enabled for the same user account.
*Emails should be sent from the email account of the user logged on
*Ensure search boxes are not case sensitive and allow the use of * as a wildcard value.
*Date and time values should be UK formatted DD/MM/YYYY, HH:MM:SS
*Any code values should also have full text displayed (eg status 0 means nothing without the text ‘LOGGED’).
*Ensure screens are ID’d to assist with any support assistance from OBS.


{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=WCS
|Ref1=Reference1
|RefV1=0.1
|RefDate1=01/03/2012
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year=2012
|FSEST=Y
|Rev1=Julie Scott
|Rev1Title=Project Manager
}}</div> 
[[Category:{{#var:Client}} FS]]