When the Operations team was changing a job plan, the wrong date was entered, and it created over 1,800 work tasks. They have since tried to retire them and they changed to Draft status. To get rid of these, can the job plan itself be retired?
[Admin: To see other related posts, use the Job Plan tag.]
I’m looking for some information on how others have addressed the tracking of activities like meetings, training, and other off-stage activities without recording this time against a standing open work task?
[Admin: To see other related posts, use the Work Tasks tag.]
In TRIRIGA, why doesn’t my dependent task go any further than the planned end date, if I move the parent task beyond the planned end date?
The task that is being moved (along with its dependent task) eventually violates the planned end constraint. The task that is in violation of the constraint is in red, and the dependent task will not be moved past the planned end. If there is no planned end, then there is no constraint and you can freely move both tasks.
[Admin: To see other related posts, use the Gantt tag or Scheduling tag.]
In a Gantt section, the section is not honoring the associated report sort order.
The issue was caused by the dynamic ordering that was implemented by the project tasks’ internal tree set. The BO query comparison was performed by using the string form of the columns. Moving forward, we resolved an issue where the default Gantt sort ordering, and the sort ordering immediately after importing an MPP project file, did not correctly order by the sequence ID based on the Gantt section query configuration.
[Admin: This post is related to the 06.14.17 post about task date issues when importing MS Project (MPP) files. To see other related posts, use the Gantt 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.]
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.]