Victor

@TonyOb perhaps the discussion below helps to explain why...

@nasimg only the BP can send out automatic emails (there are other automatic emails, but this one only BP)... you could have the BP is a suspend state "Wait for new request owner" then on BP resume, trigger the email... not sure if and how this would fit with your current BP config as maybe not always a request will get reassigned...

@DeadMeatGF I believe @DanielRi was facing the same difficulty the other day when building some internal processes. the way we/he overcome this was to create a "dummy" team. A team with no members just for this "owner reset" purpose. The BP will then be configured to assign the request to the dummy team then assign it again to the "correct" team. Passing the request via this dummy team, effectively removes the owner...

@Dan Munns @Lyonel @lee mcdermott right, so after I had a look at the internal discussion around this functionality (and looking at @David Hall comment above) the functionality to allow users which are not the assignee on a task to complete a task, only works (currently) for tasks that are assigned to an individual user, not that are assigned to a team. So, if the task is assigned to a "team", currently only that team can complete it... Now there is a change in the backlog to accommodate this as well but it requires some more work as there are other aspects to be considered, such as re-assign... this requires a bit more work as it involves some changes in the task layout too that is why it was not introduced with the latest updates. Can you guys confirm if the issue you experience falls in the above scenario? Or is something else?

@Dan Munns @lee mcdermott just a shot in the dark here, as I didn't have a chance to look at this in more detail, perhaps this (screenshot) is needed for "IT Dev Teams" to close the tasks? (I mean Yes for Allow Task Action)

@chriscorcoran please see the update here:

@chriscorcoran can you please raise a sup[port request (https://www.hornbill.com/support/) so we can investigate this? experimental.bpm.spawnAsync is now turned ON by default and is no longer an option to turn it OFF so the setting was removed. The issue you experience is not should be not caused by the async spawn of the BP...but we'll confirm this once we investigate it.

@m.vandun so, following up on the above, can you please change the "Start - Incident" progressive capture from this: ...to this: And give it another try (test)?

@m.vandun I had to create a test request (IN00006244) which I canceled to see what the issue is since I was unable to spot any error in the logs. So, what happens is that your "Add attachments" form is actually in a progressive capture that switches after selecting a service catalog item (the "parent" progressive capture). You can see when the capture switches, there is no more attachment section on the right-hand side summary. My suggestion is to have the "Add Attachments" form in the progressive capture for the catalog item(s)... the "child" progressive capture... EDIT: hold on to this, there might be some ProCap configuration which might be the underlying cause for this, please bear with me while I'm having a bit more thorough look...

@m.vandun not yet I'm afraid ... Can you tell me the request reference for the test and I'll have a look at this today...

@Dan Munns please raise a support request with us regarding this issue. We need a bit more detailed (thorough) investigation to see what's going on...

@Shamaila Yousaf If the request is logged by auto responder (you will see the timeline being created by System Autoresponder and the timeline entry mentioning it) then there is nothing it can be done. Auto responder is not currently designed to process attachments. Is something that we looking to improve in the future. If the request is logged by an analyst from an email then your progressive capture for "raise new" needs to have the "Add Attachments" form. If the progressive capture does not have this form, the email attachments will not be processed...

@AndyColeman I assume you will update to build 993 (which is the latest update available in live instances but this build was deployed for some time...). So, this build does not have this fix. I was referring to the "next" update which is incoming...(basically build 994 or greater) as @Mohamed advised as long as the feedback timer has not expired, the user can use the feedback... If the feedback timer expires then the feedback option for that request is gone. No additional options. Perhaps you want to cater for longer delays by setting a sufficient feedback expiry timer...

@AndyColeman it is a defect around feedback still being counted/displayed after it has expired. It is fixed in the next Service Manager update.

@Paul Alexander I fixed the BP, and sent it over via email... @samwoo if is the same BP as mentioned in my email to you, I can't replicate the issue...

@Stephen Hutchinson why not let them set their own password directly via the "Forgot Password" option?

@Dan Munns send me the BP config file, I'll have a look and see IF this can be somehow added until we have a permanent solution...

@samwoo send the me BP configuration as well...

I don't know... I highlighted the issue internally...

...simply returned him to the services form or... ? I never seen this...

@Dan Munns yes, the BP engine only has the concept of "full" users... I assume you mean adding "basic" users...I have seen this scenario before on the email node when you try to email a "basic" co-worker but you won't find them in the user field...

@Dan Munns yes, if this setting is turned off... (or you should be able to anyway )

@Martyn Houghton can you raise this with support so we can investigate in more detail. Thanks!

@Martyn Houghton when you reach the "Service Details" form in the "new change switch" pro cap, do you select a catalog item or just the service itself? ... Do you get to next form, the "Request Details" after "Service Details" or it jumps straight after service? Is it possible to run this pro cap in your instance? I mean if you have it active...

@Paul Alexander that specific issue you show in the screenshot whereby you have lines linking nodes that seem to go nowhere (somewhere outside to left of screen) can occur when you delete or manipulate node groups... Especially when you import a BP configuration that has groups or copy groups across... Unfortunately you can't "get it back". Re-load the BP, does it show the same? If so, download the BP config and send it to me and see if I can fix it.