TCE 6.3.7 Release notes - Resolved Bugs
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. 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. Expected Result: Invoices with 'Approved' workflows should be pulled. Actual Result: Workflows with pending status are output instead. 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.
|
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:
Observe you get an error. |
Reported Product Version: TC 6.3.3 Workaround: Instead of Use: 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. |