Regarding the setup and breakdown tasks for rooms, the Start and End times of these tasks are only influenced by relevant service assignment matrix (SAM) service level agreements (SLAs), and not by the Room Setup and Breakdown times of the space. If there are no SAM records, the duration of the task is taken as 0 (i.e. the Start and End times are the same).
The Start and End date-times on the reserve work task records that were created for the Setup and Breakdown times on the space were populating the values from SAM (not the reservation). The issue has been resolved to populate the date values from the space by adding a new list value “Use Reservation” to the “Task Assignment Dates Rule” list field on the service plan record, which is used for service plan records that are created for reserve functionality. This will allow the dates to be used from the reservation and not SAM.
Also, the list values “Available Mid-Reservation” and “Available for Entire Reservation” in the “Reserve Service Type” list field on the reserve work task template have been removed, since our current structure does not support these two values for the reservation use case.
Note for upgrade customers: These list values have been removed from the as-shipped application. These values will not be removed through an object migration (OM) package. So, you have to manually remove these values from your environment if they are not being used anywhere.
[Admin: This post is related to the 11.16.16 post about searching for rooms with setup and breakdown times. To see other related posts, use the Reservation tag.]
Logged into TRIRIGA 3.5.2/10.5.2. Set the project. Navigated to the Schedule tab. Imported MS Project (MPP) file. First thing noted was that the Start and End times were set to 9AM. A time zone was set, but no calendar. After fixing dependencies and saving that to the Gantt, we noted that the schedule task and work task times were an hour off, that is, the Gantt section times and the query section times (specifically, the End times).
After saving to the Gantt, but before saving the project, the dates and duration in the Gantt didn’t match. Also after saving, we noted that the Start and End times of the schedule task were updated from 9AM to some different, seemingly arbitrary, values. After the final save, the Duration values changed from Weeks/Days/Hours to Months/Weeks/Days. We also played around with changing the Planned Start Date of the project, and noted that any change that occurs prior to the original date, or any future date, will not recalculate at all.
There is a bug in the MPXJ library where in some instances, the working days needs to be set to 0. Moving forward, we resolved an issue where sometimes, Microsoft Project files (MPP) tasks are coming in with dependencies with an invalid lag time of 95.4733 days when the lag time should be 0 days.
[Admin: To see other related posts, use the Gantt tag.]
Does anyone know how to prevent the duration field from auto-converting to weeks and years? Just keeping the days entry?
You should be able to select the type of units to display in the Properties box for the field in the form where it displays.
[Admin: To see other related posts, use the Duration tag.]
When the “Due Within” from the service level agreement (SLA) on the service assignment matrix (SAM) record contains minutes as well as hours (for example, 4 hours 30 minutes), the minutes component (30 minutes) is getting truncated when this value is being applied to the related work task. In other words, only 4 hours is considered for the total working period, instead of 4 hours 30 minutes.
The platform was only considering whole number hours, not the decimal (0.5) portion. Moving forward, we resolved an issue where the calculation for working hours from the duration ignores the minutes and seconds parts.
[Admin: To see other related posts, use the SLA tag or Agreement tag.]
Out-of-memory errors can occur as a result of a report running, but we cannot identify which report. So we need a way to identify the report that is running, who ran it, and how long it is running, so analysis can be provided.
In the TRIRIGA 3.5.1 release, a new flag was added to reports to enable them to be tracked over time. This tracking includes who ran the report, when it was run, and the total duration the report took to complete. By default, this is disabled. However, it may be a good idea to enable full tracking across all reports in the system to help trace performance issues, and usage over time…
[Admin: This post is related to the 04.19.17 post about tracking the report runtime history, and the 10.31.16 post about using the report run history to track performance.]
Using any reservation form, and the “All Day” flag, reservations are generated. Then reopen the reservation which displays an “End Date” of year 5168… We’ve repeated this on a base product configuration and multiple browsers.
The following application fix was applied to resolve the issue. In Workflow Builder, open the workflow “triReservationManager – Synchronous – OnChange – All Day”. This workflow is located in the triReservation module and triReservationManager BO. Open the “Round” Modify task. Select the “Edit Map” link and scroll down to the triDurationDU field. Select the formula picker. The formula “86400000 * div(END-START, 86400000)” needs to change to “END-START”. Click OK in the formula picker, and on the map to save changes. Publish the workflow.
This defect focuses on the Real Estate Contract form > Clauses, Options, and Terms tab. When entering a specific duration, the Must Exercise By date is calculated incorrectly. Furthermore, there are other dates in the Exercise Date Notification that are also calculated incorrectly, but they are driven from the Must Exercise By field.
[Admin: The same article is also posted in the IBM Support Portal as a technote.]