If a work task has a calendar and the “Planned End” or “Actual End” date-time field values are updated, the “Working Hours” are not always calculated correctly. The working hours do not seem to factor in the calendar hours.
The working hours were not being calculated correctly. The issue was that the values for the calendar fields (Year, Month, Day, etc.) were not being set correctly. The fix was to set the calendar fields exactly as we do for the other calculation methods. Moving forward, we resolved a work task record and Gantt chart issue, where the Actual Working Hours and Actual Working Days were not being correctly calculated when an Actual End date value was entered.
[Admin: To see other related posts, use the Calendar tag or Gantt tag.]
We have a problem when we open a reservation from the calendar. It seems that when the user has a primary organization and he opens a reservation from My Calendar, the reservation window is opened, but it doesn’t show any information. However, if the user doesn’t have a primary organization, the reservation window is opened and it shows the information correctly.
When dealing with an organization, geography, and project security, you should use the user’s groups, not override groups. In Reserve, My Calendar, a user with an organization or geography is unable to open a reservation that was created. The security was not using the organizations or geographies from the user’s profile (groups) when determining the user’s access. Instead, it was using the overridden Reserve security group.
[Admin: To see other related posts, use the Reservation tag.]
The “Apply Record” and “Apply Template” methods use current time stamps, instead of source-record time stamps when mapping to the created tasks.
We needed to make modifications to use a Query task to grab all associated tasks and task templates on the target record, and call two workflows against each to force updates to the Planned Start and Planned End dates within the context of their associated calendars. Moving forward, the application now correctly applies the task calendar hour restrictions to the tasks and task templates when using the “Apply Template” and “Apply Record” functionality with capital projects.
[Admin: To see other related posts, use the Templates tag or Calendar tag.]
The date entered from within the Gantt section is not correctly populated when the date-time format is set to DD/MM/YYYY hh:mm:ss.
We needed to pass the millisecond value instead of the formatted date-time value and adjusted it for the time zone offset. Moving forward, an issue is resolved where the Gantt date-time picker is not setting the correct value if the user date-time format is other than MM/dd/yyyy HH:mm:ss. The user time zone offset will depend upon where the user is accessing the application. The date-time picker will adjust the date based on the location where the user is logged in.
[Admin: The same article is also posted in the IBM Support Portal as a technote.]
In TRIRIGA 10.5.2, the Net Rent Payments for non-monthly recurring frequencies is no longer spread out across the fiscal months. Previously in 10.5.1, an annual amount would be divided across the 12 months in the Net Rent Payment column of the fiscal line item (FLI). In 10.5.2, the annual amount is only shown in the fiscal month of which it is due.
The functionality was changed between 10.3 and 10.4, but changed back to the original functionality with the release of TRIRIGA 10.5.2. Specifically, with the release of 10.5.2, we changed the default setting of the Standard Calendar check box.
This feature was introduced in TRIRIGA 10.4.2. Prior to 10.4.2, the default functionality followed the Standard Calendar functionality. Between 10.4.2 and 10.5.1, the default was that this was not checked (did not follow the Standard Calendar functionality). With TRIRIGA 10.5.2, we changed the default back to what it used to be prior to 10.4.2, to use the Standard Calendar. In 10.5.1, the Standard Calendar check box was not checked. In 10.5.2, it is checked by default…
Scheduled events are not being removed by the Cleanup Agent from the table T_SCHEDULEDEVENTS after the scheduled events are completed. This causes this table to grow immensely, especially for companies that use recurrence events in their calendar. Identifying the records can be done via SQL…
The deletion of these records are currently not automated by the Cleanup Agent.
Moving forward, the completed scheduled events older than the value specified in the property CLEANUP_AGENT_SCHEDULED_EVENT_COMPLETE_DAYS will
now be marked for deletion.
When opening any meeting in the Microsoft Outlook calendar, the TRIRIGA Reserve Outlook add-in will connect to the TRIRIGA server and send a small package.
This happens regardless of whether the meeting was created with the TRIRIGA add-in or not. When opening an appointment (which has no participants, in contrast to a meeting), there is no connection to the TRIRIGA server. It can be reproduced by opening Fiddler, opening Outlook, and then opening any item in the calendar that has participants (i.e. a meeting).
The consequence of this is that a session is opened for the user on the TRIRIGA server, taking up capacity on the server, thereby reducing the number of real users that the system can support. Has anyone else noticed this behavior? Can it be changed through configuration?