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.

 

TCE 6.3.7 Release notes - Resolved Bugs

This page provides the detailed information about the bugs resolved in TCE 6.3.7 release.

Resolved Bugs

Tracking code/Case Number Issue Additional Information
SUPPORTPRI-64652

Issue: System Error is displayed while navigating to Global Search Page for a user with rights to only few objects.

Pre-Requisites: Create a user and associate to a group which only has access to documents, contact, and preferences.

Steps to reproduce:

1. Login to the Teamconnect with precondition user.

2. Click on Enter some text (at least 3 characters) in the global search text field.

3. Click on Go button.

Reported Product Version: TC 6.3.6

Workaround: None

Expected Result: The search results page should be displayed.

Actual Result: Instead of a search results page, a System error message is displaying.

Root Cause Analysis: While accessing the search page, UUID for elastic search is fetched and in that method, it is trying to access the system settings information (UUID data is in there). If the user doesn't have right it will throw an error which is handled as part of this ticket.

 

SUPPORTPRI-64067

Case#: 2022-0404-912877

Issue: Workflow enumeration not filtering workflow status correctly in API.

Pre-Requisites: The example in the attached code should pull approved invoices with workflows having Approved Status, but pulls pending instead.

Changes to the code can be made to test other configurations but Support has found similar inconsistencies that should be investigated.

Steps to reproduce:

1. Go to Setup > Invoices > Rules.

2. Create a Custom Action Rule called 'Invoice Not Sorting on Approved Workflow Status'.

3. Trigger on 'User Invoke'.

4. In the action tab, upload the attached 'InvoiceSearching.class' file to the Automated Actions Folder.

5. Select 'InvoiceSearching.class' as the automated action.

6. Enable the rule.

7. Save.

8. Go to the UI.

9. Set Rule Logger to DEBUG and clear logs.

10. Do a custom search in invoices.

11. Search should filter on 'Workflow Status'.

12. For results, include Workflow Status and Invoice Number.

13. Run the Search.

14. Observe the results of the search.

15. Click on one of the approved invoices.

16. Click 'More Actions' at the top and then 'Invoice Not Sorting on Approved Workflow Status'.

17. After the action is run, view the logs.

Observe the output shows 'Pending', not 'Approved' invoices.

Reported Product Version: TC 6.3.3

Workaround: User advises using number criterion instead of enumeration criterion.
This has not been confirmed by Support.

Expected Result: Invoices with 'Approved' workflows should be pulled.

Actual Result: Workflows with pending status are output instead.

It should be noted that a similar behavior was observed when workflows were sorted by 'Rejected',  where invoices with workflows other than rejected were returned.

Root Cause Analysis: Incorrect enumeration used to represent workflow status in model.

 

SUPPORTPRI-63865

Issue: REST GET on object with user missing rights throwing PDE, causing 500 responses.

Pre-Requisites: TCE 6.2.1+

Steps to reproduce:

1. Custom object (ex: MATT) with either invoice relation or project relation.
User with all object view rights except the relations.

2. Navigate to the record, click the Share button to find the primary key.


3. Enter the REST endpoint for this project using the primary key into the browser.

4. Observe that the user gets a 500 error response from the server and there is no error in the logs.

Reported Product Version: None

Workaround: None

Expected Result: Project is returned without an error, while not returning any secured relations.

Actual Result: Results in 500 errors.

Root Cause Analysis: Serializers do not expect SecuredList instances and send those into the gson serializer.

SUPPORTPRI-63770

Case#: 2022-0308-901582

Issue: SystemSearchField("approvalStatus", ApprovalStatus.class, EnterpriseEntity.class) not correct - approvalStatus is not correct.

Pre-Requisites: Several invoices - there should be some with 'Approved', 'Rejected', and 'Pending' workflow status. Additionally, it may be necessary to test this on a system without Legal and FMR, on a bare bones install. You can create a custom object for matters with involved parties. Then create a matter in the custom object, and then an invoice for it. This cannot be reproduced on systems that have those modules installed, though the output is still incorrect but not necessarily an error.

Steps to reproduce:

1. Go to Setup.

2. Go to Invoice Object.

3. Go to Search View > Custom Search.

4. Add a system field called "Workflow Action" and set the field to "approvalStatus_StatusIID" (this may already exist).

5. Save.

6. Create a Custom Action / User Invoke Rule.

7. Upload the attached class file to the automated actions folder and used the class file as the automated action for the rule.

8. Enable the rule and save.

In the application:

  • Open an invoice
  • Click on 'More Actions'
  • Click on the Rule.

Observe you get an error.

Reported Product Version: TC 6.3.3

Workaround: 

Instead of
"SystemSearchField APPROVAL_STATUS = new SystemSearchField("approvalStatus", ApprovalStatus.class,
EnterpriseEntity.class);"

Use:
"SystemSearchField APPROVAL_STATUS = new SystemSearchField("approvalStatus_statusIID", ApprovalStatus.class,
EnterpriseEntity.class);"

Expected Result: The invoices with approved status should show in the logs.

Actual Result: The action fails.

Root Cause Analysis: Incorrect search field path in com.mitratech.teamconnect.enterprise.api.model.EnterpriseEntity.java. It should be "approvalStatus_statusIID" and not "approvalStatus".

SUPPORTPRI-63699

Issue: No API Class in 4.x API for CustomBlocks to call a method in Java without refreshing the Page.

Pre-Requisites: None.

Steps to reproduce: None.

Reported Product Version: TC 6.3.5

Workaround: None

Expected Result: None

Actual Result: None

Root Cause Analysis: New Feature

SUPPORTPRI-63698

Issue: No Method to get phase name for a custom object record in 4.x API.

Pre-Requisites: None.

Steps to reproduce: None.

Reported Product Version: TC 6.3.5

Workaround: None

Expected Result: None

Actual Result: None

Root Cause Analysis: New API

SUPPORTPRI-63695

Issue: No Method to remove User from a group in 4.x API.

Pre-Requisites: None

Steps to reproduce: None

Reported Product Version: 

Workaround: None

Expected Result: None

Actual Result: None

Root Cause Analysis: Enhancement

SUPPORTPRI-63460

Case#: 2021-0302-748660

Issue: Unable to GET/PUT time independent date fields value using REST API.

Pre-Requisites: 

1. TeamConnect 6.2.5.

2. Timezone independent date field on any custom object(I tested with Dispute).

Steps to reproduce:

1. Make a GET request using the Postman tool for the record created as per pre-requisite. 

2. JSON returned doesn't contain any value for that custom field. 

3. Make a PUT request for same record to update the timezone independent date field. 

4. It results in an error.

Reported Product Version: TC 6.2.5

Workaround: Changing the timezone independent field to timezone dependent field but need to check if this will impact any existing data.

Expected Result: GET request should return value of date field and with PUT request you should be able to update.

Actual Result: Not able to get or set the value of timezone independent date field via REST API.

Root Cause Analysis: CalendarDateFields serialization/deserialization not configured for Projects

SUPPORTPRI-63083

Case#: 2021-1203-865205

Issue: System error when trying to login using a bookmarked URL.

Pre-Requisites: N/A

Steps to reproduce:

For URL other than the login URL, the user get a system error and a giant errors in the system log -- this makes debugging the system very difficult using logs.

Step 1: log in to Teamconnect and navigate to any page in TC and bookmark that page.

Step 2: Log out from TeamConnect.

Step3: Login to TC using the bookmarked URL.

Step 4: Once you log in using bookmarked URL you will get a system error saying "go back to Team Connect/ Go back to Homepage"

Step 5: If you check the system logs you could find an error.

Reported Product Version: TC 6.3.3

Workaround: Asked the user to go to the bookmark option and to edit the saved URL as given bellow: 

Expected Result: The user wants to log in with bookmarked URL other than login URL without any error in UI and in the system logs.

Actual Result: 

In UI it shows an error message that "An error has occurred that prevents continuing your session. If the error persists, please have your system administrator check the system logs for additional details." Request has no context ID.

Root Cause Analysis: Instead of error page, Home page will be shown on null context.

SUPPORTPRI-62570

Issue: "Error During Evaluation of the Route. Null" when an Accrual Invoice is Posted.

Pre-Requisites: None.

Steps to reproduce:

1. Create a Matter with the budget.

2. Create an accrual Invoice and Click on Save and View.

3. Click on Post.

Reported Product Version: TCE 6.3.3 with EAB 6.3.1

Workaround: None

Expected Result: The invoices should be posted and no error should be thrown.

Actual Result: Getting the following error while posting an accrual "Error During Evaluation of the Route. Null".

Root Cause Analysis: Enhancement.

SUPPORTPRI-51885

Case#: 2019-0823-549141

Issue: Issue with getting Adjustment reason in custom block.

Pre-Requisites: 

1. TeamConnect Instance version TCE 6.1.2.

2. Create a custom block on the Invoice object to get the adjustment reason from line item. Use attached source files "INVC_Demo_CJB.class" and "CaseSummary.xml".

3. Add the block in Invoice default object view.

4. Create an invoice record and add an adjustment with adjustment reason.

5. Set "Custom Blocks" logger on Debug.

Steps to reproduce:

1. Open the invoice on which adjustment reason is added.

2. Navigate to the tab on which block is added.

3. Observe the error in logs.

Reported Product Version: TCE 6.1.1

Workaround: N/A

Expected Result: "getAdjustmentReason()" method should return adjustment reason detail as per functionality.

Actual Result: This method throws an error and do not return adjustment reason while using it in custom blocks

Root Cause Analysis: ClassCastException caused by model value not being converted to 4.x equivalent.

SUPPORTPRI-49783

Case#: 2018-1228-497797

Issue: Second adjustment made via code not reflecting on UI.

Pre-Requisites: 

1. TeamConnect 5.0 Update 8.

2. Create a custom action rule to make adjustment on lineitem. Rule should be on create trigger with order 20.

3. Create second custom action rule to make second adjustment on lineitem. Rule should be on create trigger with order 30.

Steps to reproduce:

1. Create an invoice in TeamConnect and it will trigger both the rules.

2. On lineitem, observe that second adjustment didn't update under 'Adj' column.

Reported Product Version: TCE 5.0.8

Workaround: N/A

Expected Result: Second adjustment is not reflecting on the lineitem.

Actual Result: Both the adjustments should be reflected on lineitem.

Root Cause Analysis: User code is calling "lineItem.setAdjustedRate(BigDecimal)" via a 4.x API rule which implicitly performs a line item adjustment. If a rule calls the method twice, only the first call creates an adjustment. The implicit adjustment involves a flag which prevents code going into a cycle. The flag is not reset timely which prevents consecutive adjustments.

SUPPORTPRI-46615

Case#: 2019-0213-507216

Issue: getGroupRights() method for GroupAccount throwing null pointer exception.

Pre-Requisites: 

1. TeamConnect 5.2.4.

2. Custom Java code which uses "getGroupRights()" method.

3. Attached code uses the "All Rights" group, so create a group with name "All Rights" or update the code.

Steps to reproduce:

1. Create a custom action rule on any custom object on user invoke trigger.

2. Use class file which calls the "getGroupRights()" in the rule.

3. Trigger the rule and check the logs.

Reported Product Version: TCE 4.0 U15

Workaround: N/A

Expected Result: "getGroupRights()" method should not give null pointer exception.

Actual Result: "getGroupRights()" method results in null pointer exception.

Root Cause Analysis: Not supporting it.

SUPPORTPRI-45905

Case#: 2018-1218-496477

Issue: Unable to get previous state of user via 4.X APIs.

Pre-Requisites: A development environment (IDE) with all TeamConnect 4.X external libraries imported.

Steps to reproduce:

1. Create a custom action rule on user object with an automated action which should log number of groups before updating the user and number of groups after updating the user using TC 4.X API.

2. User uses code to get previous state of user.

Reported Product Version: TCE 6.0.0

Workaround: To use 3.X API code

Expected Result: The number of groups after updating (adding a new group) the user should be greater when compared to previous state of user.

Actual Result: The number of groups after updating (adding a new group) the user remains same when compared to previous state of user.

Root Cause Analysis: UserServiceLegacyImpl always returns the user in the active uow even if the UserAccount is not in the uow.

SUPPORTPRI-45591

Case#: 2018-1130-493062

Issue: Error retrieving project assignee role using 4.x APIs.

Pre-Requisites: 

1. TeamConnect instance of version 5.2

2. Create a scheduled action rule to get the assignee roles in 4.x APIs using below method:

"platform.getLookupItemService().getProjectAssigneeRoles("DISP");"

Note: Object with DISP unique code must exist

3. Upload this file at location: Top Level/System/Scheduled Actions.

4. Navigate to Tools > Scheduled Actions.

5. Select the file from Action drop down and select start date in future.

6. Click on Add button.

Steps to reproduce:

1. Run the schedule action rule by clicking on 'Run Now' button.

2. Job will be failed and you will get the error in the logs.

Reported Product Version: TCE 5.2.1

Workaround: Use 3.x APIs to get assignee roles.

Expected Result: You should be able to get the assignee roles added for a matter in setup side.

Actual Result: Error is given in the logs that "No LookupTable for name: LProjAssigneeType".

Root Cause Analysis: Wrong API method called by "LookupItemServiceLegacyImpl".

SUPPORTPRI-45356

Case#: 2018-1211-495014

Issue: REST API for custom fields not returning all fields.

Pre-Requisites: N/A

Steps to reproduce:

1. Create a custom object. Name: Test Object Unique Code: TEOB

2. Create two custom fields on the object. Give both the same value for the label.

3. Try and retrieve all the custom fields for the object using the REST API.

Reported Product Version: TCE 5.3.0

Workaround: Ensure that all the custom field labels are unique.

Expected Result: Data for all custom fields on the object is returned.

Actual Result: Only data for one of the custom fields is returned.

Root Cause Analysis: The list of fields is returned as a Map keyed by label.

SUPPORTPRI-45216

Case#: 2018-1129-492659

Issue: The user is not able to get the document parent object for history record through TeamConnect API code.

Pre-Requisites: TeamConnect instance should be there and the user should be able to upload the block files.

Steps to reproduce:

1. Login to TeamConnect application.

2. Go to Document object from Setup side.

3. Under blocks tab, click on 'Go to Screens Folder'.

4. Upload the attached class and xml files for block.

5. Add this block by choosing the file and Save it.

6. Add this block under your Default customized object view.

7. Now go to TeamConnect User Interface and go to 'Document' object under 'All' tab.

8. Click on tab where you had added the block in the object view.

9. You will observe that user is facing the error while fetching the Document parent object.

Reported Product Version: TCE 5.2.0

Workaround: N/A

Expected Result: User should be able to get the parent object of History record if parent object is Document.

Actual Result: The user is not able to get the parent object of History record if parent object is Document.

Root Cause Analysis: Document parent type not handled in HistoryModelImpl.

SUPPORTPRI-44841

Case#: 2018-1121-491541

Issue: Issue getting category Involved custom field.

Pre-Requisites: 

1. TeamConnect Instance version 5.2

2. A custom Involved field on a category of custom object (say DISP_BANK)

3. A custom block to get the involved field value by using the code.

Steps to reproduce:

1. Navigate to dispute record in UI.

2. Observed that there were errors displaying the custom block and get the error in the logs.

Reported Product Version: TCE 5.2.0

Workaround: You can use 3.x APIs to get the value of Involved field from custom object's category.

4. Upload the code's .xml and .class files in below folder of the object on setup side. Root/System/Object Definitions/Dispute/Screens

5. Open the Blocks tab of object and select 'CustomBlock.xml' in 'File Name' and add a Friendly Name for it.

6. Add this block in Object View.

Expected Result: User should be able to retrieve the value of involved field from a custom object's category.

Actual Result: User is not able to retrieve a category Involved custom field value through CJB.

Root Cause Analysis: Incorrect ProjectEntityType lookup in ProjectModelImpl.

SUPPORTPRI-44797

Case#: 2018-1119-491050

Issue: Unable to get history records for the documents using a Custom Block in 4.x API.

Pre-Requisites: 

1. TeamConnect 5.2.3

2. A Custom Block should be created in the Dispute object to get history records for Documents attached to the Dispute.

3. A dispute record should exist with some Documents in it and the History records should be present in the Documents.

4. Add the above Custom block in the default object view of the user.

Steps to reproduce:

1. Login to application.

2. Go to pre-requisite Custom block and you will be able to view the block as the exception is handled in the code.

3. Analyze the logs and you will find the exception.

Reported Product Version: TCE 5.2.0

Workaround: N/A

Expected Result: Exception should not occur and you should be able to fetch History records for documents.

Actual Result: An exception is thrown for the below line used in the code: "List<History> histories = platform.getHistoryService().getHistories(doc);".

Root Cause Analysis: HistoryServiceModelImpl error reading system setting for max search results

SUPPORTPRI-37722

Case#: 2018-0406-443298

Issue: Not able to set the Adjustment type in 4.x API.

Pre-Requisites: 

1. An invoice, having atleast one line item of fee type.

2. Create a 'User invoke' rule with the complied class file for the attached java file.

Steps to reproduce:

1. Trigger the rule.

2. Observation : In 3X API, there was a method to set the adjustment type to 'Auto'.

Reported Product Version: TCE 5.1.0

Workaround: N/A

Expected Result: There should have been methods in 4x API providing similar functionality.

Actual Result: Currently no methods are there providing functionality to add the information on adjustment, if the adjustment is done manually or by system.

Root Cause Analysis: 4.x API enhancement

SUPPORTPRI-31711

Case#: 2017-0905-395972

Issue: TC 4+ System Error - Setting User Account Expire Date through the API breaks.

Pre-Requisites: 

1. TC 4.0 Update 11.

2. Make sure, "Account Expires On" field should not be populated on the User for which you need to populate the same field using TC 4.X API.

3. The user should have rights to update the "Account Expires On" field through TC 4.X API.

Steps to reproduce:

1. Create a custom action class file to update the User 'Account Expires On' field using 'setAccountExpiresOn' method.

Moreover, there is no special method available in TC 4.X API to activate the "Account Expires On".

Reported Product Version: TCE 4.0 U11

Workaround: None

Expected Result: The user should be able to populate the "Account Expires On" field on the user using TC 4.X API.

Actual Result: The user unable to populate the "Account Expires On" field on the user using TC 4.X API.

Root Cause Analysis: The expiration date must be set along with a internal flag.

SUPPORTPRI-27826

Case#: 2016-1213-293555

Issue: 4.x API ProjectService search by searchView not working.

Pre-Requisites: 

1. TeamConnect 4.2 Update 1.

2. Create a custom tool and below method should be used to search for the projects: 

Steps to reproduce:

1. Login to TeamConnect 4.2 Update 1 instance.

2. Navigate to 'Tools' in 'All services'.

3. Select the pre-requisite custom tool.

4. Perform the action used in the tool and look for the projects in the logs.

Observations: This issue is occurring only while using the custom tool, search results not only contains the records for the specified object in the method, but also records from other objects. The method works as per functionality in custom rules.

Reported Product Version: TCE 4.2.1

Workaround: None

Expected Result: In logs only records for specified object should be displayed for the search view used.

Actual Result: In logs the result obtained is not object specific.

Root Cause Analysis:HLSO not set up correctly when using a search view.

  • Was this article helpful?