Skip to main content
Mitratech Success Center

Client Support Center

Need help? Click a product group below to select your application and get access to knowledge articles, webinars, training content, and release notes or to contact our support team.

Authorized users - log in to create a ticket, view tickets status and check your success plan details.

 

Automated Qualifiers

You can use the following examples of automated qualifiers written in Java with any rule type.

Depending on whether you need the old object or the current object, different methods are necessary for getting values of an object. In these examples, the values in the current object are used unless otherwise stated.

You can find the following automated qualifier samples in this section:

Checking System Field Values 

Both the total amount and activity item are system fields in task records (instances of Task). Therefore, the interface Task has specific methods to get their values.

The activity items in task records are system lookup table items. For more details, see Lookup Tables and List Fields.

Business Rule

No tasks that are over $10,000 with the activity item Printing can be posted without approval.

Qualifier

Checks whether:

  • The total task amount is over $10,000.
  • The task's activity item is Printing.

Sample Values

Object Definition:
TASK (system object Task) 

Task Activity Item: 
ACTI_PRNT (Printing) 

Categories:
None

Custom Fields:
None

Java Qualifier: Checking System Field Values 

public class VerifyingSystemFieldValues extends CustomCondition<Task> {
@Override
public boolean condition(Task task) {
// Check whether the activity item of the task is Printing and the total amount of the task is greater than or equal to 10,000
return task.getActivityItem().equals("ACTI_PRNT") && task.getTotalAmount().doubleValue() >= 10000;
}
}

Comparing Custom Field Values 

Automated qualifiers are frequently used to compare field values. You can compare the values of any fields as long as the values are of the same data type. This example demonstrates how to compare the values from two custom fields of type Date. 

Business Rule

Served company records do not save if the values in the Service Date and Received Date custom fields are not the same.

Qualifier

Checks whether the date values are in two custom fields of the same type.

Sample Sample

Object Definition:
LITI (custom object Litigation)

Categories:
LITI (root category of Litigation)

Custom Fields:
ServiceDate (Date)
ReceivedDate (Date)

Java Qualifier: Comparing Custom Field Values 

public class ComparingTwoCustomFieldValues extends CustomCondition<Project> {
@Override
public boolean condition(Project project) {
// Getting the value of the service date field
Date serviceDate = project.getDateFieldValue("LITI", "serviceDate");
// Getting the value of the received date field
Date receivedDate = project.getDateFieldValue("LITI", "receivedDate");
// Return true if they are not equal return !serviceDate.equals(receivedDate);
}
}

Checking Whether Custom Field Values Changed 

This sample demonstrates how to check whether the value in a custom field changed. Notice that the method of getting the database value and the value entered during the current session is done in the same as in the previous sample.

Business Rule

Main policy holder cannot change in policy records without approval.

Qualifier

Checks the value on the screen in the Policy Holder custom field against the value in the database.

Sample Values

Object Definition:
PLCY (custom object Policy)

Categories:
PLCY (root category of Policy)

Custom Fields:
PolicyHolder (Involved)

Java Qualifier: Checking Whether Custom Field Values Changed 

public class CheckingWhetherCustomFieldValuesWereChanged extends
CustomCondition<Project> {
@Override
public boolean condition(Project project) {
// Getting the object as it currently exists in the database - that is, the 'old' object
Project initialProject = platform.getProjectService().readLastSaved(project);
// Getting new policy holder
Involved currentPolicyHolder = project.getInvolvedFieldValue("PLCY", "PolicyHolder");
// Getting old policy holder Involved initialPolicyHolder =
initialProject.getInvolvedFieldValue("PLCY", "PolicyHolder");
// Return true if the policy holder has been changed
return currentPolicyHolder.getPrimaryKey() != initialPolicyHolder.getPrimaryKey();
}
}

Checking Roles in Related Records 

You can use automated qualifiers to check the values in related records of the current object.

Business Rule

No claim records can update if they do not have an involved record with the role Claimant.

Qualifier

Checks if an involved record has the specified role.

Sample Values

Object Definition:
Policy or any custom object definition 

Related Object of Current Object: 
CLIN (Involved)

Category in Related Object: 
CLIN_CLMT (Involved role Claimant) 

Custom Fields:
None

In the following sample, after getting the list of Involved records related to the current project object, the rule checks the list of categories (involved roles) added to each involved record. If a role does not exists, the qualifier returns true.

Java Qualifier: Checking Roles in Related Involved Records 

public class CheckingValuesInRelatedRecords extends CustomCondition<Project> {
@Override
public boolean condition(Project project) {
List<Involved> involvedList = platform.getProjectService().getInvolved(project);
for (Involved involved : involvedList) { List<Category> roles = involved.getCategories(); for (Category role : roles) {
if (role.getTreePosition().equals("CLIN_CLMT")) {
// Return false if the project has any involved with the role of Claimant
return false;
}
}
}

Checking Default Category in Related Records 

The following sample gets the list of Involved records related to the current object and checks the default category (role) of each Involved record. If none of the Involved records have a particular category, the qualifier returns true.

Business Rule Qualifier

Claim records can only update if they have an Involved record with the role Claimant.

Qualifier

Checks if there is an Involved record with the specified role as its default role (category).

Sample Values

Object Definition:
Claim or any custom object definition

Related Object of Current Object:
CLIN (Involved)

Category in Related Object:
CLIN_CLMT (Involved role Claimant)

Custom Fields:
None

Java Qualifier: Checking the Default Role in Related Involved Records 

package com.mitratech.teamconnect.enterprise.api.model.rule; import java.util.List;
import com.mitratech.teamconnect.enterprise.api.model.Involved; import com.mitratech.teamconnect.enterprise.api.model.Project;
import com.mitratech.teamconnect.enterprise.api.service.ProjectService;
public class CheckingValuesInRelatedRecords2 extends CustomCondition<Project> {
@Override
public boolean condition(Project project) {
// Getting the project service
ProjectService projectService = platform.getProjectService();
// Getting the list of involved records related to the project List<Involved> involvedList = projectService.getInvolved(project); for (Involved involved : involvedList) {
// If the default category is Claimant, return false
if (involved.getPrimaryCategory().getTreePosition().equals("CLIN_CLMT"))
{
return false;
}
}
return true;
}
}

Checking Values in Vendor's Contact Record 

The following qualifier checks whether the vendor of an invoice has a specific checkbox selected in the contact record. The qualifier then checks whether the number of line items in the invoice is more than the number that were in the previously saved version of the invoice.

Business Rule

If the contact selected in the Vendor field of an invoice has the Volume Discount checkbox selected in the contact record, recalculate the task line item amount using the specified Discount Percentage field.

Qualifier

Checks the value in the Volume Discount checkbox in the contact record of the vendor.

Sample Values

Object Definition:
INVC (system object Invoice)

Related Object:
CONT (system object Contact) 

Categories of Related Object: 
CONT_VNDR (category of Contact)

Custom Fields of Related Object:
volumeDiscount (checkbox)

The following sample is an example of checking values in vendor's contact record.

Java Qualifier: Checking Values in Vendor's Contact Record 

public class CheckingValueInVendorContactRecord extends CustomCondition<Invoice>
{
@Override
public boolean condition(Invoice invoice) {
// Get invoice service object
InvoiceService invoiceService = platform.getInvoiceService();
// Getting old invoice object
Invoice oldInvoice = invoiceService.readLastSaved(invoice); Contact vendor = invoice.getVendor();
// Return true if the vendor has volume discount set to true and the line item count on the invoice has increased
return vendor.getBooleanFieldValue("CONT_VNDR", "volumeDiscount") && invoiceService.getLineItemCount(invoice) > invoiceService.getLineItemCount(oldInvoice);
}
}

Checking Whether Custom Field Has a Value 

The following qualifier checks whether a custom field that was previously null has a value, by comparing the value in the old object with the value in the current object.

This qualifier can be used with the action described in Creating Related Task Record.

Business Rule

When the Trial Date field in a Matter updates with a value, create a task for the main assignee to complete the executive summary, with the due date 15 days before the trial date.

Qualifier

Checks the value in the Trial Date field in a matter record.

Sample Values

Object Definition:
MATT (custom object Matter)

Categories:
MATT (root category of Matter)

Custom Fields:
trialDate (Date)

Java Qualifier: Checking Whether Custom Field Has a Value 

public class CreatingARelatedTaskRecordQualifier extends CustomCondition<Project> {
@Override
    public boolean condition(Project project) {
        // Get old object
        Project oldProject = platform.getProjectService().read(project);
        // Get current trial date
        CalendarDate trialDate = project.getCalendarDateFieldValue("MATT", "trialDate");
        // Get old trial date
        CalendarDate oldTrialDate = project.getCalendarDateFieldValue("MATT", "trialDate");
        // Return true if the current trial date is not null and the previous trial date was null
        return trialDate != null && oldTrialDate == null;
    }
}
  • Was this article helpful?