In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   Cloud ERP  |   Home  |   qad.com



  •     QAD Glossary

  • QAD .NET UI 2.9.6.11 Application Changes
    The following summarizes application changes for QAD .NET UI 2.9.6.11.
    Note: This release, QAD .NET UI 2.9.6.17, is a maintenance release of the QAD .NET UI for QAD Enterprise Applications — Standard Edition 2012 and 2013. Previously, QAD .NET UI 2.9.6 (2.9.6.11) was released for QAD Enterprise Applications — Standard Edition 2012 and 2013. This release, QAD .NET UI 2.9.6.17, includes the application changes originally included in QAD .NET UI 2.9.6.11.
    Copying Links to Clipboard
    You can now copy (and paste) QAD Shell URL (qadsh://) links to Desktop programs and browses by choosing Actions | Copy Link To Clipboard. You can then paste the URL into a browser to run the Desktop program or browse.
    E-mail Action Options
    The Action/E-mail feature in programs running in Desktop mode allows you to create an e-mail with a QAD Shell URI (qadsh://) to a Desktop program. There has been an inconsistency in this feature because different e-mail clients handle the QAD Shell URI differently, some recognizing it and allowing the e-mail recipient to launch the link and some not recognizing it and instead requiring the recipient to copy the link and paste it into a Web browser.
    New options are now available to:
    Allow an administrator to set (using client-session.xml) whether they want the QAD Shell URI to be used directly (which is and has been the default) or if they want to wrap this QAD Shell URI in an HTTP URI (http://), which is more widely recognized by e-mail clients.
    Provide an option to turn on or off the inclusion of the full URI in the e-mail. (By default two links are put in the e-mail—the first is the program label that links to the URI and the second is the full URI. This option controls the second link.)
    Provide an option to create the link as text instead of HTML (for e-mail clients or settings that are text based).
    These options are controlled by the following settings, which can be added to client-session.xml:
    <EmailAction.UseHTTP>true</EmailAction.UseHTTP>
    When set to true, the HTTP URI is used in the e-mail. When false, the direct QAD Shell URI is used.
    <EmailAction.IncludeURI>true</EmailAction.IncludeURI>
    When set to true, the full URI is added as a link in the e-mail. When set to false, it is not included.
    <EmailAction.UseText>true</EmailAction.UseText>
    When set to true, the link will be text. When set to false, the link will be HTML.
    Parameters in Terminal Script in User Option Telnet Maintenance
    You can now specify the following parameters in the Script Value field in User Option Telnet Maintenance:
    ${d} – Domain
    ${u} – User ID
    ${e} – Entity
    ${c} – Code Page
    Any number of these can be included in Script Value, with each separated by a space. For example:
    /dr01/scripts/telnet.ksh ${d} ${u} ${e} ${c}
    These will then be available in the telnet script as standard parameters (${1} ${2} ${3} ${4}).
    Lookups Not Limited to Starting Point of Field Value
    By default, the initial item on a field’s lookup browse is the current value in the field. For example, on the Sales Order Maintenance program’s Credit Terms field, if the current value is 30D (for thirty days after invoice date), the lookup browse for the field will list the terms codes for the field starting with 30D, the current value. Although this is the list that many would like to see, in some cases you might want the lookup to list all the possible options for the field rather than just the ones starting at the current value. For example, for the Credit Terms field, you might want to have all the term codes listed, not just the ones starting at 30D.
    You can now have the lookup browses for specified fields list all the options for the field rather than just the ones starting at the current value. The configuration steps must be done by a system administrator with access to the QAD system files.
    Note: The ability to change the lookup browse listing only applies to programs that run in Desktop mode.
    Changing the Lookup Browse Listing
    To change a field’s lookup browse to list all the options for a field, do the following:
    1
    Identify the program name (for example, for Sales Order Maintenance, the program name is sosomt.p).
    2
    Identify the field name (for example, for the Credit Terms field, the field name is so_cr_terms).
    3
    In your QAD installation, locate the com/mfgpro/setting.dat file and com/qad/mfgpro/setting.dat file.
    4
    Add the following line to the end of both setting.dat files:
    bl: program_name :b: field_name =true
    where:
    bl indicates “blank lookup”.
    program_name specifies the program, but with no dot (“.”) before the p. For instance, sosomtp rather than sosomt.p.
    b indicates the current frame.
    field_name specifies the field. For instance, so_cr_terms specifies Sales Order Maintenance’s Credit Terms field.
    For example, for Sales Order Maintenance’s Credit Terms field, you add the following line to the end of both setting.dat files and make sure to leave an extra blank line below it:
    bl:sosomtp:b:so_cr_terms=true
    5
    Restart the Connection Manager.
    Output to Text Lines Now Configurable
    You can now configure the maximum number of lines displayed to the user when running a legacy report with output to text. To do so, use the <QView> ... <TextReportLines> setting in the client-session.xml file. The default is 100,000 lines:
    <TextReportLines>100000</TextReportLines>
    Browse Performance Checking
    The system can now do a performance check on the index use of a new browse definition when you save it from Browse Maintenance. The performance check, Show Index Information, will help to avoid the creation of poorly performing browses with non-indexed fields in joins, filters, and sorts.
    When a browse definition is saved from Browse Maintenance, the Progress Query Parser's INDEX-INFORMATION is examined. Checks are made to determine whether indexes can be used. Improperly defined query definitions are indicated as whole index scans and are displayed in red in the Index Information tab. For instance, the browse definition could result in a table scan that could cause performance issues and you might need to modify the definition so that no whole index scans occur. Tables with large numbers of records might negatively impact performance, so you might need to analyze the query string to identify possible causes. To do so, open the Query String tab to view the dynamically generated query string as determined by the Browse Engine.
    The performance check is on by default, but can be changed from the Show Index Information setting Tools | Options or from the config-session.xml file, which now includes the following:
    <DotNetBrowseMaintenanceShowIndexInformation>true</DotNetBrowseMaintenanceShowIndexInformation>
    The setting specifies whether the output of the Progress INDEX-INFORMATION attribute for a query is displayed when there is an issue.
    Note: The ability to examine what the Progress Query Parser determines as the indexes for a query is limited. The Browse Engine currently only exposes the dynamic query string prior to appending sorts, local variables, pre and post processor commands, and so on. This performance check will help eliminate most poorly performing browses that have been built from improperly constructed definitions. However, this check will not cover situations where users apply search conditions and sorts after the browse has been displayed in the user interface.
    Browse Export and Import Identifies Language Mismatches
    Previously, when a browse was exported using Browse Maintenance, the labels used in the browse were included for all the supported languages. However, when imported, the only the labels for the user importing the browse were included with the imported browse. Now, an imported browse will include all the labels for languages supported by the system, not just the ones for the user’s current language. If the browse includes labels for languages that are not defined in the system, a warning message will be included in the system log file (“WARNING: The Language language for the Label Term label term does not exist in the target language. Label not imported for this language”).
    Find Feature for Legacy Reports Output as Text
    Any legacy report that is output to text now includes a Find box on the toolbar for searching the report. You can also activate the Find feature by entering Ctrl+F.
    Active Directory Enhancements
    The QAD .NET UI supports Microsoft’s Active Directory authentication. With this release, Active Directory support has been enhanced so that the QAD .NET UI:
    Allows any domain to be specified at login.
    Allows the default domain to be specified on the home server.
    Enables a list of valid domains to be specified on the home server.
    Removes OS user ID restriction. Allows any domain and user ID combination to be entered, except local domain.
    Enables user ID mapping between Active Directory and QAD, which eliminates the eight-character user ID limitation.
    Eliminates blank QAD password vulnerability.
    Eliminates domain spoofing.
    With these Active Directory enhancements, users will be required to do the following:
    Enter a QAD user ID and password the first time they use Active Directory authentication.
    Re-encrypt the credentials store whenever their Active Directory password changes. They will be prompted to enter the Active Directory password used during the original encryption.
    Re-enter their QAD credentials whenever they are unable to remember the Active Directory password used during the original encryption.
    With Active Directory, QAD passwords are encrypted in a credentials file named <domain> - <user> -credentials.xml, located on the home server in a / <environment> /storage/user-data/ <user> directory. Passwords are encrypted using AES with a 256-bit key generated at runtime using the password base key deriviation algorithm (RFC 2898).
    Active Directory Configuration Settings
    The following settings in client-session.xml: configure Active Directory:
    <QAD.Authentication.ActiveDirectory.Enabled>
    This setting enables or disables Active Directory authentication, with true enabling Active Directory and false disabling Active Directory.
    <QAD.Authentication.ActiveDirectory.Domain>
    This setting specifies the default Active Directory domain. If a domain is not specified, the current PC domain is used. Domains are resolved in the following order:
    1
    Login form: users can specify a domain using the syntax {domain}\(username).
    2
    Configuration setting in <QAD.Authentication.ActiveDirectory.Domain>
    3
    Current active PC domain.
    <QAD.Authentication.ActiveDirectory.ValidDomains>
    This setting specifies a comma-delimited list of valid domains used during Active Directory authentication.
    Note: In client-session.xml, the <QAD.Authentication.ActiveDirectory> setting has now been replaced by the <QAD.Authentication.ActiveDirectory.Enabled> setting.
    Enabling Active Directory Authentication
    To enable Active Directory authentication:
    1
    Define users so that the user IDs match the Windows user IDs. Assign temporary QAD passwords to new user IDs.
    2
    Locate the client-session.xml file on the home server. (By default, the file is located in the TomcatInstallDir /webapps/qadhome/configurations/default directory.)
    3
    In the client-session.xml file, set <QAD.Authentication.ActiveDirectory.Enabled> to true.
    When a user first logs in to the QAD .NET UI, the system prompts the user to enter the temporary QAD password that was assigned to the user ID. Entering the temporary password then completes the Active Directory setup. The next time that the user logs in to the QAD .NET UI, the user must use their Windows user ID and password.
    Note: In previous releases, when setting up Active Directory, you had to enable the Enforce OS User ID option in Security Control (mgurpmmt.p). Additionally, the passwords for user IDs had to be sent to blank. These steps are no longer necessary.
    QAD Shell URL (qadsh://) Protocol Enhancements
    The qadsh:// protocol has been enhanced as follows:
    The qadsh:// protocol is now registered on a user basis, allowing different users to access different versions of the QAD .NET UI client on the same machine.
    The qadsh:// protocol is now registered during the launch of the QAD .NET UI, ensuring that the protocol is defined correctly.
    The qadsh:// protocol is only registered if the registry setting for the currently running QAD .NET UI client is different than the one already registered.
    The qadsh:// protocol always points to the the last QAD .NET UI version that was launched rather than the version most recently installed.
    The user registry settings do not require administrative permissions, enabling XCOPY installations.
    Legacy Report Output and HTML Syntax
    You can now configure specific legacy reports to display HTML syntax in output to “page”. The current default displays the HTML code instead of rendering the HTML itself. This default exists to overcome the problem in which the report data had special HTML characters such as < or >. If the data has such characters and output to “page” is used, then an error results and the report does not render. However, there are situations in which HTML (such as a link or a button) in the report output is useful, so you can now specify which report programs will be allowed to display HTML.
    Requirements
    The report program specified to display HTML must not have the possibility of data in it that has special HTML characters that are not proper HTML syntax. For example, the item number abc<1000> has HTML brackets in it but is not proper HTML syntax and will cause the report not to render.
    The report cannot be on the list of reports in the enhanced format (beautifyReports.lst).
    Setting Report Programs to Display HTML
    1
    Edit com/mfgpro/setting.dat and add a comma-delimited list of report programs to the htmlReports setting.
    2
    Make the same change to com/qad/mfgpro/setting.dat.
    3
    Restart the Connection Manager.
    Note: QAD does not provide support for HTML customizations of reports.
    Allowing Changing of Legacy Report Output
    Legacy reports can now be configured to output their report files to a directory other than the default working directory of the common Connection Manager user.
    This feature is turned off by default but can be enabled as follows:
    1
    Locate com/mfgpro/setting.dat.
    2
    Follow the instructions in that file to set the reportPath setting.
    3
    Make the same change to com/qad/mfgpro/setting.dat.
    4
    Restart the Connection Manager.
    5
    Restart the QAD .NET UI client.
    This only applies to Desktop reports run from the QAD .NET UI. It does not apply to:
    Terminal or CHUI mode.
    Reports that have two output fields (such as Invoice Post and Print).
    Batch reports (in any mode).
    File system permissions must be taken into account when using this mechanism. Keep in mind that even though the report file can be redirected to a different location, it is still being written by the common Connection Manager user. As a result, that user will need to have the access to write the report files to whatever location is specified here.