Setting Due Date Field

[jcsmith]

I am attempting to set the due_date field on the catalog requested item form to pull from a user created field (u_planned_completion_date) on the sc_task table.   Preferably, if the item has multiple tasks, it would use the last Planned Completion Date available.   For some background, I'm doing this to override the auto-calculated "Expected Delivery Date of Completed Order" that the user sees when a request is submitted.   I would like this to be blank until the work is planned and the Planned Completion Date field is filled.

I, honestly, don't even know where to start on this one.   I'm not technically inclined, as I usually work on front-end, user experience with SNOW.   Any and all help would be appreciated.

The closes thing I can think of would be something like:

task.due_date = current.variables.u_planned_completion_date;

But, I'm fairly certain that's not even close.   I'm thinking it's going to have to be a more complicated client script.

Thanks!

[kristenankeny]

Can you provide a screenshot of the two records you want to update with the fields highlighted? Perhaps I'm not understanding the need.

[jcsmith]

I would like this field:

to populate this field:

So the user sees the Planned Completion Date - or the latest Planned Completion Date from all tasks included in the request - here:

[Chuck Tomasi]

Hi Justin,

The estimated deliver date of the completed order on that final screenshot is created from the workflow, if I remember right. It is "estimated". Users only see that when they do the final checkout (someone may correct me on that.)

Normally the tasks come along later in the process, so I am confused on the timing. If someone ordered something on Tuesday and you don't create tasks until later in the workflow (say Thursday), then how can you show them a different number on the checkout screen based on tasks that don't exist yet.

I get the idea of moving the latest task to the RITM. The scripts above should get you in that direction.

[jcsmith]

Chuck,

The requester can always check the status of the request.   You are correct in that the estimated completion date of the request is calculated from the stages/tasks in the workflow.   However, we're just starting to implement our Service Catalog.   We're starting with a very general service request option where the user basically just fills out a free form box with a description of the work they would like to have completed.  

With this general use, there's no way to estimate or have a general schedule for the work that is to be completed since it could be something as small as requesting access to a system or as complex as upgrading a software across multiple data centers.   This particular route only has a single item and a single task (fulfill the request), which is generated immediately after the request is submitted.

[kristenankeny]

Chuck - isn't that view of the request the "self service" - no matter if it's upon submission or you open your request later? I think you're right though, it originates from the workflows - though this is at the request level - so is that trickling up from each requested item? We removed this from our layouts to prevent false expectations with our end users.

Justin - can you explain what you mean by strange things happening with the due date on the task? There may already be some business rules in place, either on the sc_req_item table or on the sc_task table that are causing some sort of recursive issue.