Bug fixes in this release
- The user authentication Integrated page stores the details to connect to the outside world. This page was creating duplicate records.
- This release fix has removed the creation of duplicate records.
- Additionally, now the records will be checked for successful connection prior to saving the record. Only if userid/password are valid with a successful connection will the details be SAVED. If not a warning message is displayed.
- ADD button to this screen was NOT approved by Management & Still a PCR needs to be done for this
- This bug was found when testing MSIC-281. The employer (organisation) details were not working uniformly on ALL the MSIC Screens. It was noticed that when replacements requests (Lost/Stolen) were "approved" by the MSIC admin, a new record was created unlike all other replacement scenarios (eg:Change of name, visa renewal, etc) due to which the new record did not carry forward the organisation details. This could be treated as loss of data and customer gets upset to refill the data.
- Additionally, ALL other screens should display the same organisation's details. Eg: ChangeApplicantdetails.aspx (Employer Details tab), ChangeEmployer screens, etc).
- This is more an RFC but also a bug.
- RFC 1: This reduces the "Application Lodgement" Exceptions : Line2 should not contain the same value as Line1. A validation is now in place so that Line2 and Line1 in the ADDRESSES can never be the same.
- Fix 2: On an application with status:"Card Collected", when the ADDRESS tab is clicked and a NEW address is attempted to be inserted, however did not Fill in the address details and then navigated away from that page, then NULL values are saved which cause the Auscheck Exception: The value for column 'Date To' in table 'Address' is DBNull. This has now been fixed.
- RFC 3: Secondary Phone number is NOT mandatory. This has now been fixed.
- When a Site/Stevedore Admin terminate an employee from their profile this does not convert the applicant from a Site/Stevedore applicant to a Single Application and places the record in the queue with the message "Pending Conversion to Single Applicant". This is happening because the applicant's record does not have "Company Details". However, per developer MSIC-16 request is blocking this to be fully converted and restricting it from happening. So, this could not be fully rectified. However, instead the record will be removed from the Site/Stevedore Admin's profile which is why this was originally requested.
- The Site/Stevedore "Pending Review" screen forces the admin to review ALL the applicants - New, renewal, 2nd renewal, and so on.
- This feature will allow the admin to review 'only' the applicants he chooses to review. This was working for some records and was not working for some. This should accommodate ALL applicants.
- If a card replacement request was submitted for an applicant on a bridging visa with the return reason as Visa Renewal, the VisaExpiryDate was set as null. On approving the replacement request Null was then converted to '1/1/1900' and as a result used as the Expiry date for the card. When the card was printed, the new expiry date will be '01/01/1900'.
- This error happened if DimaVisaExpiryDate was Null when the replacement request was placed.
- To resolve this an additional condition to verify if chkIsBridgingVisa is checked before updating the new expiry date to the value for BackgroundCheckEndDate.
- dateNewExpireDate date control is now mandatory (unless chkIsBridgingVisa is checked) if the value of ddlReplacementCardStatus is "Approved"
- There were two bugs on the RequireDocument page if "Certificate of Proficiency" was selected as a Secondary Document:
The Document Number field did not have an asterisk even though it was mandatory.
When "State of Issue" was selected the "Date of Issue" control became null and disabled and so application could not proceed.
- Applications lodged with AusCheck were failing if the application contained invalid characters.
- AusCheck valid characters are printable characters in the Unicode "Basic Latin" character set
- All cards that are not 4 year MSIC Cards missing the BackgroundCheckEndDate were not getting processed for replacement, which affected Access Cards.
Changes in this release
- Card Registrations & modifications once failed to update in AUSCHECK could be rectified but there was no feature to update this to Auscheck automatically except via raising a PCR to reset the flag. This NEW feature is now in MSIC where once the record is rectified, it could be reset to update Auscheck automatically.
- This feature will assist to reduce ALL Card Registrations in the exception report once data/xml (issue) is fixed via the web interface.
Resurrection of the Replacement Screen: The replacement screen and notifications sent to the clients was not professional.
EMAIL FORMAT: When an applicant request for a replacement, they receive an email. The email sent to them is very unprofessional as shown below without the company signatures,etc.
Sent: Monday, 29 April 2013 4:24 PM To: Shekinah Sample Samson Subject: Replacement Card Request received
Applicant 'Sample Samson' has requested a replacement card. User Comment =
This RFC has inserted more instructions to the requesting replacement application to advice about each replacement request and the required documents for each kind.
- A Statutory Declaration Link to help support to print out a Stat Decl as and when required: https://msic.1-stop.biz/1stopportal/index.aspx
- An additional notification via email detailing point by point ALL the instructions the applicant needs to follow.
- If its a Site/Stevedore/Company applicant and no admin's email id stored in DB, then helpdesk receives an EMAIL to be forwarded to the admin by calling and updating the admin's email address otherwise NOT which used to generate emails for 'every' replacement request. This reduces unnecessary emails to helpdesk.
- This is Phase II of the Follow Up BackgroundCheck Process.
- Changes made to this process at the "FBC Adviced" stage triggered by the "Card Query" windows service to provide a 2 month grace period (For CARD EXPIRY only - The REDO inductions has NO grace period) for ALL 4 yr applicants undergoing the FBC.
- Changes made to process the FBC AUSCHECK decision via the New Windows Service "Follow Up Service" should now process the Auscheck FBC outcomes - Eligible or Not Eligible.
Manual procedures can be found here:
A detailed automated flow chart describes the whole process: