Vitalware 2.2.01

Release Date: 15 June 2011

Requirements

Download

pdfDownload a document containing these release notes and associated documents.

New Features

Multiple Group Support

 

Multiple Group support allows a user to be a member of more than one group. The Vitalware Registry entry that defines the group into which a user is placed has been extended to allow a semicolon separated list of groups to be specified. For example:

User|vw|Group|Counter;Mail Room

The above entry indicates user vw is a member of two groups, Counter and Mail Room. If a user is a member of multiple groups, the Vitalware Login screen provides a drop-list with the groups that the user is a member of:

groups

The group selected becomes the active group and is used to determine permissions until another group is selected. The Security tab in the Options dialogue allows another group to be chosen:

groups2

When the active group is changed, a dialogue displays allowing the user to indicate how opened modules should be handled:

groups3

Any module left open will remain in its existing group. Hence it is possible to have two (or more) modules open, each in a different group. The permissions used for a given module are dictated by the group in which the module exists. The module's group is displayed in the status bar at the bottom of the module window.

A complete description of the support for multiple groups can be found in the pdfMulti-group Support documentation.

Encrypted connections

 

Encrypted connections support allows all data transmissions between the Vitalware client and server to be encrypted. As part of the login process, X509 based certificates are exchanged allowing Vitalware clients to ensure they are connecting to the correct Vitalware server. TLS v1.0 (Transport Layer Security) is used to provide the encryption. System Administrators may choose the encryption cipher used, allowing different levels of compression and security to be configured. The Vitalware server may be configured only to accept encrypted connections, otherwise encryption is optional.

Encrypted connections are also supported for:

  • Java connections (TexJDBC)
  • C/C++ connections (TexAPI)
  • perl connections (texapi.pm)

A complete description of the support for encrypted connections can be found in the pdfEncrypted Connections documentation.

Read-only Modes

 

A new Registry entry allows System Administrators to make part or all of Vitalware read-only. The format of the new entry at a system wide level is:

System|Setting|ReadOnly|value
Group|Default|Setting|ReadOnly|value
Group|group|Setting|ReadOnly|value
User|user|Setting|ReadOnly|value

At a table level the format is:

Group|Default|Table|Default|ReadOnly|value
Group|Default|Table|table|ReadOnly|value
Group|group|Table|Default|ReadOnly|value
Group|group|Table|table|ReadOnly|value
User|user|Table|Default|ReadOnly|value
User|user|Table|table|ReadOnly|value

where value is either:

  • true - read-only functionality is enabled.

  • false - read-only functionality is disabled.

A complete description of the support for read-only modes can be found in the pdfRead-only Modes documentation.

Field Help Display

 

A new option allows the field level help for a given field to be displayed below a module's Status bar. The help display area may be re-sized to suit:

mod_parties_show_field_help_vw

The Show Field Help in Module Window option is located on the General tab in the Options dialogue:

options2

Fields which fail validation may now have their background highlighted in a particluar colour

 

New functionality has been added which uses the following Registry setting:

System|Setting|Show Validation Errors|true

When this entry is set to true and the column ValValidationFields is prsent in a module, any column listed in this field will be highlighted with the background colour selected for Validation Errors on the Colours tab of the Vitalware options:

options

Ability to generate a sample of records from a set of records

 

A new Samples module has been added to record information about a sample of records. Users with sufficient privilege can monitor the progress and authorise the completion of each batch:

sample

The Lot Sizes Registry entry is used to configure sample options. This entry is in the format:

System|Setting|Lot Sizes|Record Type|Sample Type|sample config; sample config;...

The sample config part of the entry defines lot sizes and conditions. Using the first sample config in the example below, if the number of records to base the sample on is 25 or less, then the generated sample for these records will contain five records. In order for this sample to be successfully processed, the sample may only contain a maximum of one error:

System|Setting|Lot Sizes|Registrations|Normal|25-5-1;90-20-2;150-32-3;280-50-4;500-80-5;1200-125-7;
3200-200-10;
10000-315-13;35000-500-19

Functionality has been added to the POS and Registration modules to allow for generating and processing samples. A sample may be generated by selecting the Generate Sample menu option found under the Tools menu and processed by selecting the Sample menu option under the new Process menu.

See the latest version of the Vitalware Help for full details.

Ability to attach communications directly to Registration or POS module records

 

A new Communications module has been created to record individual communications between the registry and its clients. An additional tab has been added to the POS and Registration module to track the communications associated with a record. New communications may be added to a record by selecting the Communications menu option under the new Process menu:

communications

New Call Centre Module

A new Call Centre module has been added to the client, containing summary information from Registration and POS module records. This can be used to provide staff in a call center with reduced record access to respond to first level enquiries.

 Improvements

 Edit Resource command

A new command has been added to the Multimedia Repository allowing a user to invoke an external editor to modify the multimedia resource (image, document, etc.). The Edit Resource command downloads the resource from the Vitalware server, invokes an editor and monitors the file for any changes. It also looks for any other files created with the same name as the resource file but with a different extension (file type). When Vitalware receives focus the user is asked whether the modified file should be re-imported into the Multimedia Repository. An affirmative response saves the resource on the Vitalware server and generates any resolutions, etc. The new command streamlines the process of modifying multimedia resources:

mod_multimedia_edit_resource_vw

XMP and IPTC upgraded

The Multimedia Repository has been upgraded to support the latest versions of the IPTC and XMP metadata standards. The standards implemented are:
  • IPTC Core Version 1.1
  • IPTC Extension Version 1.1
  • XMP July, 2010

Login details on a per client basis

The Host/User/Service/Group login values are remembered on a per client basis. If an institution runs multiple clients, the details displayed in the login dialogue are the values from the last time that particular client was run, rather than the values for the last time any client was invoked.

Change password utility uses SSH

The administration task allowing a user to change their password now uses SSH (secure shell) to effect the change. Previously TELNET was used, requiring the TELNET service to be enabled on the server for the utility to work. By using SSH, the TELNET service no longer needs to be enabled, rather the SSH service is required. Most sites enable SSH to allow secure access to the Vitalware server.

ICS support for notifications

The Vitalware notification system, used to generate email notifications and HTML pages for upcoming activities (registrations, tasks, etc.), now builds an iCalendar (.ics) file containing upcoming dates. The iCalendar file may be imported into a large number of products, including:
  • Google Calendar
  • Apple iCal
  • IBM Lotus Notes
  • Microsoft Outlook

Once imported, the upcoming dates, along with a detailed description, are incorporated into the user's calendar.

Reverse scheduling of tasks

The Task tab functionality has been extended to allow the completion and start dates of each task to be computed by specifying the overall completion date. The new functionality allows a user to set the date on which all tasks should be completed and have Vitalware calculate the start and completion dates for each task.

Modifications to vwperiodic

The vwperiodic server-side command is used to run tasks on a regular basis. In particular, it is used to generate the raw data for the Statistics module. The command has been extended to allow:
  • Individual scripts to be specified, restricting the scripts executed.
  • Execution of local scripts only, via the -l option.

Read-only records in List View

The display of read-only records in List View has been changed. Read-only records are now displayed with a grey background and black text, rather than the harder to read, grey text on a white background:

readonly

vwsecurity run automatically when required

A new Audit Trail handler has been added that monitors the Vitalware Registry for changes where a user's settings have been modified. Where settings have been changed, vwsecurity is executed to update the security settings for all Vitalware databases. The following events are handled:

  • Addition of a new user.
  • Deletion of an existing user.
  • Changing the group(s) of an existing user.
  • Altering database security via the Security Registry entry.

There should be no need to run vwsecurity manually.

Image Quality available for JPEG 2000

When generating JPEG 2000 based images, the Image Quality may now be defined. The Image Quality determines the level of sampling used when creating the image. The value is between 1 and 100, where 100 implies full sampling, that is no lose of image quality, and 1 represents the least amount of sampling, resulting in a much smaller file size, but with image degradation.

Assign Till number for invoice and zero total amount records

When records are inserted the Till is assigned to the POS, Ledger and Orders records. Two exception to this were when an invoice was created and when no payment was required for an order. In these cases the Till was not assigned until a payment was made for the record. This presented a problem for batch processing because each batch was processed by querying for all POS records on the current Till. The Till number is now assigned to all POS records at their time of creation.

The ability to continue with batch printing when an error occurs

A new Registry entry has been added to allow batch printing to continue after an error has occurred. The entry is:

Group|Default|Table|epos|Continue Batch Print After Error|true

When this is set, each error is shown and then the printing continues from the next record.

The invoice module updated to handle multiple payments entered at any one time

At times it is possible for a customer who has received an invoice to make the payment using two payments and on occasions both payments may come in at the same time. The invoice payment processing only expected one payment and so only processed one. A change was made so that each added payment would be processed in turn thus allowing either one or multiple payments onto an invoice at the same time.

POS module updated to recalulate the invoice amount as new products are added rather than waiting until the record is saved

When additional products were added to a invoice transaction that had not yet been invoiced, the total amount was updated but the invoice payment amount was not. This was confusing for the operator who would try to adjust the total. The calculation for invoice amount has been adjusted so that it is updated when products are added.

Resending of failed NRS messages

If for some reason an NRS message that should have been sent was not sent (e.g. as a result of a  logic error), there was no trigger to enable the message to be sent. The vwauditdump script was modified to allow audit records to be scanned to find the appropriate audits so these could be passed back through the NRS mechanism. An additional script vwnrsreprocess was created which takes the found audit records and generates the expected XML files.

Event type correction when the barcode scanning process inserts a certificate audit record

An invalid event type error could be shown when an event was not linked to the order that generated it. A change was made to check the Products module based on the product ordered to determine the correct event type.

New Process Menu

A new Process menu has been added to the Registration and POS modules. The new Communications and Sampling functionality (see above) can be found under this menu. It was decided to move some other functionality under the Process menu: the Adoption (Births) and Image menus (Registration tables and POS) have been moved under the Process menu.

Improve efficiency of date range queries used in generation of statistics

The following statistics generation scripts were also updated to utilise the new stats method:

etc/periodic/monthly/AuditOperationTableUser.pl
etc/periodic/monthly/CertificatesPrintedByType.pl
etc/periodic/monthly/CertificatesPrintedByUser.pl
etc/periodic/monthly/CertificatesReprinted.pl|
etc/periodic/monthly/CertificatesVoidedCancelled.pl
etc/periodic/monthly/LoginsUser.pl
etc/periodic/monthly/OrdersByProduct.pl
etc/periodic/monthly/RegistrationByType.pl
etc/periodic/weekly/AuditOperationTableUser.pl
etc/periodic/weekly/CertificatesPrintedByType.pl
etc/periodic/weekly/CertificatesPrintedByUser.pl
etc/periodic/weekly/CertificatesReprinted.pl
etc/periodic/weekly/CertificatesVoidedCancelled.pl
etc/periodic/weekly/OrdersByProduct.pl
etc/periodic/weekly/RegistrationByType.pl
local/qld/etc/periodic/monthly/DeathsByReceiptMethod.pl
local/qld/etc/periodic/monthly/RegistrationByType.pl
local/qld/etc/periodic/weekly/CertificateTurnaround.pl
local/qld/etc/periodic/weekly/CONApplications.pl
local/qld/etc/periodic/weekly/CONCompleted.pl
local/qld/etc/periodic/weekly/DeathsByReceiptMethod.pl
local/qld/etc/periodic/weekly/RegistrationByType.pl

 

Issues Resolved

Issue Resolution

If a multi-term query is performed on an attachment field where the field searched in the attached module has Also Search Registry entries associated with it, the query generated may not be the most efficient one possible.

The query generated for multi-term attachment queries where the attached column has Also Search Registry entries is now efficient.

For systems running in UTF-8 mode, the Audit Trail mechanism will drop audit records containing invalid UTF-8 characters. As the audit records are not posted to the Audit Trail table a "gap" may appear in the audit trail. The issue only occurs where invalid data is stored in a record (normally as a result of bad data when importing into Vitalware).

The Audit Trail mechanism now replaces invalid UTF-8 characters with the invalid UTF-8 character (0xFFFD). The substitution allows the audit record to be processed without error.

The View>Attachments command, used to show all records attached to the current record, displays modules the user does not have permission to use. While it is useful to see whether any records in the module attach to the current record, the module cannot be invoked without displaying a permission denied error.

The View>Attachments  command has been modified to show only those modules the user has permission to access. A check box has been added to Show all modules, allowing the old behaviour to be selected.

The vwlutsupdate server-side script does not update Lookup List files in local/luts/default if it exists. Files in the luts/default directory are always updated. The issue means that localised versions of Lookup Lists may not be updated correctly by Vitalware upgrade scripts.

Local versions of Lookup List file are now updated by the vwlutsupdate server-side command.

Data in reference fields, that is fields displaying data from another module, may not contain the correct values after certain operations are performed. The affected operations are:

  • Discard Record
  • Replace (Global Edit)
  • Export Records
  • Merge Record
  • Sort
  • Delete Record

Data in reference fields now displays the correct values after the listed operations are performed.

The value in a read-only combo-box may be cleared using the backspace key the first time data is viewed. The backspace key will not clear the value when viewing subsequent records.

The backspace key is disabled when a combo-box is read-only, regardless of when the data is viewed.

Random Access Violation messages may display indicating an error has occurred in mshtml.dll. The error message may even appear when a user is not at their machine.

The error message is no longer displayed.

When performing a spell check on a RichEdit control that has multiple lines of text, the highlighting of the words spelled incorrectly may be out by a few characters.

Words spelled incorrectly are now highlighted correctly.

The View Attachments button next to a read-only grid may not be enabled when a single row is displayed in the grid. The button is only disabled for grids displaying data from another module (a reverse reference column).

The View Attachment button is now enabled when a single value is in a read-only grid.

The default value for the Gender field in the Parties module is set to Female. Ideally the default values should be Unknown.

The default value for the Gender field is now Unknown.

When changing the colours for various attributes (e.g. mandatory fields, etc.) via the Options dialogue box, the new colours selected will not take effect in modules already open. New instances will display the correct colours.

Existing modules now update their colours correctly when the Options dialogue box is closed.

When switching to the Details view of a record on a tab that contains an HTML control, the input focus is set to the HTML control, rather than the first control on tab.

The input focus is set to the first control on a tab when switching from Details view, even if the tab contains an HTML control.

A List of Values failure: fail to get values message may be displayed when generating a Crystal Report that contains dynamic parameters.

The error message is no longer displayed for Crystal Reports containing dynamic parameters.

The Audit Trail facility does not flush logging information when the processing of a record has been completed. The lack of flushing means the log file contents may lag behind the processing of records.

The Audit Trail facility now flushes logging information after each records processed.

The auto filling of values for the upper levels of hierarchies may be slow where the controls that form the hierarchy appear on a number of tabs.

The speed of auto filling of values in hierarchies has been improved dramatically.

Not all of the certificates from different versions of a registration were showing in the historic tack grid.

All certificate records from the different record versions now show in the historic grid.

Trying to reprint a certificate while logged on a batched Till could result in the reprint not being sent to the printer.

The reprint is now correctly sent to the printer.

Running the special + and !+ reference queries in POS did not return the correct results.

Using the + or !+ reference queries returns the correct results.

Nightly jobs did not complete successfully because record updates are failing due to the fifo server not running.

The nightly jobs now ensure the fifo load is running so that all jobs are successfully completed.

When running logging through vwlogger, the logs disappear when the directory specified to log to does not exist.

The logging now creates the directory so that no logs are lost.

When trying to add an invoice payment on a day that was not the day a transaction was inserted, the payment type was disallowed.

Invoice payments can now be made to under transactions on days other than when the POS record was inserted.

When using undo maintenance the status of the record could sometimes be reset incorrectly.

The status of all records is now correctly set when using undo maintenance.

When a duplicate Registration number error was thrown, a duplicate Registration could be created when the record was saved.

A duplicate record is no longer created after a duplication Registration number error is shown.

The nightly matching process could generate an invalid query when running over historic records.

The nightly matching process no longer generates invalid queries.

Background loads fail if the fifo load is not running.

The fifo load is always started before any other load starts so that all other loads now correctly start.

When selecting Cancel from the Reprint Quantity box, certificates still print.

Certificates no longer print if Cancel is selected from the Reprint Quantity box.

The entire invoice payment could be assigned to the final POS transaction if the initial save of invoice payment failed.

The correct amount is now assigned to each POS transaction.

The end of month report appears to be missing data from newly added Till locations.

The cashbook now correctly shows the data from the new Till locations.

When attempting to delete a record the user may not be allowed to if a backend database does not exist (e.g. in a web environment).

The record now may be deleted provided no reference links exist.

Previous field on the Maintenance tab did not correctly show previous record version.

The previous field now correctly shows the previous record version.

Users can access Registration tables via POS searching when they do not have access to the Registration tables.

Users can no longer access the Registration tables unless they have permission to do so.

The MoneyChanged flag is not cleared on a cancelled edit, resulting in the possibility of receipts printing when they should not.

The flag is correctly cleared and so receipts only print when they should.

Work Hours is not correctly calculated when insertion and completion time is outside of business hour.

Work hours are now correctly calculated for times outside of business hours.

Upgrade Notes

The upgrade from Vitalware Version 2.1.02 to Vitalware 2.2.01 involves a number of steps. Please follow the instructions below carefully.
Do not skip any steps under any circumstances.
Before proceeding with the update please ensure that a complete backup of the Vitalware server exists and is restorable.

There are four components that require upgrading:

  • Texpress (the database engine)
  • TexAPI (web services)
  • Vitalware Server (the application)
  • Vitalware Client (the client)

The notes below detail how to upgrade all systems. Check the Releases table for Client specific notes. Upgrading comprises the following steps:

In the notes below, clientname refers to the name of the client directory for the current installation. The term ~vw is used to refer to user vw's home directory. This is normally /home/vw.

Stopping Vitalware services
  1. Log in as vw
  2. Enter client clientname
  3. Enter ls -l loads/*/data* local/loads/*/data*
  4. Check each data file is empty and no data.t files exist.
    If this is not the case, please wait for the loads to drain before proceeding.
  5. Enter vwload stop
  6. Enter vwweb stop
  7. Enter texlicstatus
    Make sure no one is using the system.
    The upgrade will not complete successfully if users are accessing data.
Record Session

Each step in the upgrade process produces detailed output. In most cases this output will exceed the size of the screen. It is strongly recommended that the output of the upgrade session is recorded, so if errors occur, the output can be examined.

  1. Enter script /tmp/output-2-2-01

A new shell will start and all output recorded until the shell is terminated.

Installing Texpress

Installing Texpress 8.3 is only required for the first client upgraded to Vitalware 2.2.01. Once Texpress 8.3 has been installed, this section may be skipped for subsequent upgrades.

  1. Enter cd ~vw
  2. Enter mkdir -p texpress/8.3.001/install
  3. Enter cd texpress/8.3.001/install
  4. Obtain the appropriate Texpress version for your Unix machine via the Texpress hyperlink at the top of the page.
    Save the release in ~vw/texpress/8.3.001/install, calling it texpress.sh.
  5. Enter sh texpress.sh
    The Texpress release will be extracted.
  6. Enter . ./.profile
  7. Enter bin/texinstall ~vw/texpress/8.3.001
    The Texpress installation script will commence.
  8. Enter cd ~vw/texpress/8.3.001
  9. Enter . ./.profile
  10. Enter bin/texlicinfo
    Obtain your Texpress licence code and place it in a file called .licence.
  11. Enter bin/texlicset < .licence to install the licence.
  12. Enter \rm -fr install
  13. Enter cd ~vw/texpress
  14. Enter ln -s 8.3.001 8.3
Upgrading KE TexAPI

Installing TexAPI is only required for the first client upgraded to Vitalware 2.2.01. Once TexAPI has been installed, this section may be skipped for subsequent upgrades.

  1. Enter cd ~vw/texpress
  2. Enter mkdir 6.0.003
  3. Obtain the appropriate TexAPI version for your Unix machine via the TexAPI hyperlink at the top of the page.
    Save the release in ~vw/texpress, calling it texapi.sh.
  4. Enter sh texapi.sh -i ~vw/texpress/6.0.003 (expand the ~vw).
  5. Enter \rm -f texapi
  6. Enter ln -s 6.0.003 texapi
  7. Enter \rm -f texapi.sh
Upgrading Vitalware Server
  1. Enter cd ~vw/clientname
  2. For Unicode based clients only.
    Enter vi .profile-local
    Change langcode=utf8 to langcode=utf-8 and save the change.
  3. Enter mkdir install
  4. Enter cd install
  5. Obtain the appropriate Vitalware server version bundle via the Vitalware Server hyperlink at the top of the page.
    Save the release bundle file in ~vw/clientname/install calling it vw.sh.
  6. Enter sh vw.sh
    The Vitalware release will be extracted.
  7. Enter . ./.profile
  8. Enter bin/vwinstall -u clientname
    The Vitalware installation script will commence.
  9. Enter cd ~vw/clientname
  10. Enter cp .profile.parent ../.profile
  11. Enter . ../.profile
  12. Enter client clientname
  13. Enter vwreindex
  14. Enter vwbldinstall
  15. Enter vwbldlinks
  16. Removal of the temporary directory (and its contents) is recommended:
    Enter \rm -fr install
  17. Enter upgrade-2-2-01

The client will now be upgraded to Vitalware 2.2.01. If you are upgrading from a version prior to Vitalware 2.1.02, you must run the upgrade scripts for all versions after the old version before running the Vitalware 2.2.01 upgrade.

Starting Vitalware services
  1. Enter vwload start
  2. Enter vwweb start
Record Session

The recording of the upgrade session may now be terminated.

  1. Enter exit

The session output is available in /tmp/output-2-2-01.

Upgrading Vitalware Client

When upgrading to Vitalware 2.2.01 the Windows client should be upgraded on each individual machine. The client upgrade installs new DLLs on each individual machine in order for all reports with dynamic parameters to function correctly. To upgrade the Vitalware Client follow the Installing Vitalware Client notes.

Perl Packages

If the administration utility to change a user's password is used, the perl Net::SSH::Expect package must be installed. If the password utility is not used, this step may be skipped. To install the package:

  1. Log in as root
  2. Enter perl -MCPAN -e shell
  3. Enter install Net::SSH::Expect
  4. Enter quit