Skip to main content

Hi Team,

When we resource lock a task to the ISP bucket (resource lock and date&time lock), and afterwards we try to commit it. We see that this task then gets committed to today (ie sysdate), and not to the day that it was originally planned (and date&time locked). This creates issues and great risk and impacts ISP bucket implementation deployment.

Steps to replicate issue :
1. Task is unallocated.
2. Try to allocate task to ISP bucket by resource lock and date&time lock to ISP bucket resource.
3. Commit the task.
4. Task gets committed to today instead of actual date when it was planned.

Can some one please help on this urgently?

@Sajith Anushan  @Bhanuka Abeygoonawardana  @Paul Smith  

Hi Shamika,

I’ve tested few things related to this with @Dayan Wijesinghe.

Turning to @Paul Smith 

Seeing some odd behaviors related to this.

  1. When an activity is already committed to a Direct resource and then we try to commit it to a Bucket, fix to datetime option is enabled. If the activity is already committed to a Bucket resource, fix to datetime option is not enabled. 
  2. In first scenario when the task is committed to a bucket resource with fixed datetime, further changes to the task will move the commitment to the current shift.

What we need to understand is,

  1. It is expected that the bucket tasks can be fixed to a datetime? If yes, I think we have a issue which should be further looked at (i.e. task moving to current shift).
  2. If not, how a requirement like this can be handled i.e. say a certain task should be committed on 30th April for a bucket resources?

Hi,

Please raise a bug for this.

It looks like the workbench doesn’t currently support setting a fixed time for bucket resources, but I can’t think of any reason why we shouldn’t be allowing this. This is causing the fixed time to be lost when making the commit change.

The CommitToAllocatedShift parameter would ensure that activities are committed into their scheduled shifts, so this could be used as a workaround until the bug is fixed.

Thanks,

Sam

Thanks Sam. @Dayan Wijesinghe  FYI.

Hi @Sajith Anushan @sarugb 

Thank you for the input. But one thing I want to double check that the impact of this workaround will be only on manually committed tasks and will the behavior of AllowPartiallyCommittedBucketRoutes parameter still remains same ie if we try to commit the task on a bucket shift which is already having some committed tasks will it still work or not?

 

Regards,

Shamika

Hi Shamika,

The CommitToAllocatedShift parameter only affects manual commits that are made via the workbench and the behaviour of the AllowPartiallyCommittedBucketRoutes parameter is not impacted by this.

Thanks,

Sam

Hi @Sajith Anushan @sarugb @Dayan Wijesinghe Even after updating the parameter  CommitToAllocatedShift, the issue still persists. I have updated the case with a task_id where we tried to allocate a task to ISP bucket which was previously allocated to Direct technician for future date ie 28th April, 2023. It got allocated without an issue. But then when we commit it, it is again getting committed to current shift. 

Can you please look into this urgently and provide your comments? 

 

Regards,

Shamika

Reply


Terms & ConditionsCookie settings