Jump to content

Martyn Houghton

Hornbill Users
  • Posts

    4,015
  • Joined

  • Last visited

  • Days Won

    86

Everything posted by Martyn Houghton

  1. @James Ainsworth Thanks for the update. The ability to search existing/previous requests include the timeline and historic updates is quite important requirement, as in essence our request history is our raw knowledge base. Cheers Martyn
  2. @Keith Depending on what version of Service Manager you upgraded from you might be experiencing the issue/change around the BPM spawn setting. See post below. Cheers Martyn
  3. @steve_g Thanks for the quick confirmation and will await an update on timescale. Cheers Martyn
  4. Suspect the Error being displayed is a red herring and the error relates to the below which is shown in the logs. 1375141 11:08:54 09/11/2016 error perf 10536 bpm:processResume() Operation Invocation results: failure (275853312 B, 61 ms, 0 kB, 0 ms, 0 kB) 1375134 11:08:54 09/11/2016 error scripts 10996 BPM operation: BPM related error: The business process instance cannot be resumed (Process:Execute: Resuming failed process) 1375133 11:08:54 09/11/2016 error scripts 10996 BPM flowcode resume: Process:Execute: Resuming failed process 1374287 11:08:50 09/11/2016 error comms 7196 Operation[apps/com.hornbill.servicemanager/Requests/bpmOperation:assignTeamOwnerCreator] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/assignTeamOwnerCreator): At 451/45: "Uncaught SyntaxError: Unexpected token ILLEGAL" if(global["query_exec_teamMembers_results"]["rowData] != undefined) global["lastException"] = typeof global["lastException"] == "undefined"? null: global["lastException"]; Cheers Martyn
  5. @steve_g Have applied 2.36.4 but the broken requests from when 2.36.3 was applied are now failing with the error below when I attempt to restart them. Also all our new requests now seem to be failing with this error. Cheers Martyn
  6. @Ehsan We have always used the View Details form in the Services under the Request Type to setup the custom fields. Therefore setting the fields here would they be specific to the Service? Also interms of setting generic ones per request type by setting them up on a request not linked to a service, will these be applied to all services, unless overridden? Cheers Martyn
  7. @Alex8000, @James Ainsworth We too want to record the time against both BPM activities generated from requests and eventually manually created activities. In respect of the latter we want to default these categories at a service level, perhaps a bit like the profile categories in SM where you are limited to a certain part of the tree at a service level, as well as setting individual defaults at the BPM individual manual activity. As Alex points out an issue with the activities at the moment is the ability for other team members to re-assign to themselves or complete activities on the owner behalf. Which is been raised in the post below. Cheers Martyn
  8. @Alex8000 Being able to set the default at a service level would at least help to in the short term. Cheers Martyn
  9. @steve_g Just wondering if there is a revised timescale for 2.36.4? Will the fix allow the broken workflows to be restarted, as got a growing number of them, as considering restricting my users access the system until this is resolved? Cheers Martyn
  10. @Ehsan Thanks for the detailed explanation. We currently have generic custom fields across all out services, i.e. there are around 10 fields we have on each of 100+ services. so at the moment we need to re-instate the generic labels for these, which from your description I presume is the Request Type scenario rather than the Service scenario? Cheers Martyn
  11. James Placing the option to raise new in the Right hand panel would help. I think the idea of a request search in the right hand panel would be really useful if the results list remain and you could click through them. You might even want to consider implementing something to show the FAQ and when the knowledge base bit comes along automatic list based on the catergory and matching to the summary/description. Cheers Martyn
  12. We and my colleague have not located the translation tab on the field properties and are entering in values, but they are still not being displayed on screen in the user app. Also are these label translation service specific now, rather than generic? Cheers Martyn
  13. @derekgreen Can you advise what version of Service Manager you are running and have you just recently applied the new release? Cheers Martyn
  14. @steve_g Steve Thanks for the update. Do we have a timescale for v2.36.4, as this issue is having a major impact on out operation? Cheers Martyn
  15. @Mohamed Just to clarify when you refer to the latest release, is this one after SM v2.36.3 or do you mean that once we correct them in this new release, they should not get corrupted again by future release? Cheers Martyn
  16. @riz Previous post may help with your replication process. Cheers Martyn
  17. @m.vandun The workaround we used last time, was having to go into the Transalation setting and reset them, as the rest of the definitions where okay, it was just the labels that got corrupted. Cheers Martyn
  18. @m.vandun Mark This has happened to again as well. Cheers Martyn
  19. Looks like there may be a general issue with a number of BPM nodes following the application of Service Manager v2.36.3. @Ralf Peters post below. An now we are also getting further errors on now on existing workflows when attempting to out request on hold via the workflow. Wondering if there is some dependencies on the platform that has not been met for the new SM release? Cheers Martyn
  20. @Ralf Peters This might be related to a similar issue we are having another Team based BPM node, see post below. Cheers Martyn
  21. @ArmandoDM Thanks. Error thrown is logs is below. 2016-11-08 08:56:07Z [DEBUG]:[SYSTEM]:[14016] XMLMC Request Failed: queryParams validation error: The value 'Requests_bpm_assignTeamOwnerCapacity_TeamDetails' for element <queryColumns> is not an allowable value at location '/methodCall/params/queryOptions/queryColumns' 2016-11-08 08:56:07Z [INFO]:[SYSTEM]:[14016] Output message XML Schema validation ok 2016-11-08 08:56:07Z [ERROR]:[PROFILE]:[14016] data:queryExec() Operation Invocation results: failure (209305600 B, 2 ms, -4 kB, 0 ms, 0 kB) 2016-11-08 08:56:07Z [ERROR]:[COMMS]:[14016] Operation[data:queryExec] queryParams validation error: The value 'Requests_bpm_assignTeamOwnerCapacity_TeamDetails' for element <queryColumns> is not an allowable value at location '/methodCall/params/queryOptions/queryColumns' 2016-11-08 08:56:07Z [ERROR]:[COMMS]:[14016] Operation[data:queryExec] queryParams validation error: The value 'Requests_bpm_assignTeamOwnerCapacity_TeamDetails' for element <queryColumns> is not an allowable value at location '/methodCall/params/queryOptions/queryColumns' 2016-11-08 08:56:07Z [ERROR]:[SCRIPT]:[14016] nodeName: Data: queryExec: TeamDetails; nodeId: a303b282-9989-470f-aa0f-f9812afb8923; At 569/1: "Uncaught EspMethodCall:invoke: Operation[data:queryExec] queryParams validation error: The value 'Requests_bpm_assignTeamOwnerCapacity_TeamDetails' for element <queryColumns> is not an allowable value at location '/methodCall/params/queryOptions/queryColumns'" throw(e); _fc_node_exec_a303b282_9989_470f_aa0f_f9812afb8923 2016-11-08 08:56:07Z [DEBUG]:[PROFILE]:[14016] FlowCodeExec(com.hornbill.servicemanager/entities/Requests/fc_bpm/assignTeamOwnerCapacity)(3ms): Nd56579ca4-28dc-481f-b8e5-e8ff969a21cc=3ms,Nda303b282-9989-470f-aa0f-f9812afb8923=0ms 2016-11-08 08:56:07Z [DEBUG]:[SECURITY]:[5100] Session cache folder 'U2016110804836969' removed 2016-11-08 08:56:07Z [DEBUG]:[SECURITY]:[14016] Local cache item for session 'U2016110804836969' has been released 2016-11-08 08:56:07Z [DEBUG]:[SECURITY]:[5100] Local cache item for session 'U2016110804836969' has been released 2016-11-08 08:56:07Z [DEBUG]:[SYSTEM]:[14016] XMLMC Request Failed: FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/assignTeamOwnerCapacity): nodeName: Data: queryExec: TeamDetails; nodeId: a303b282-9989-470f-aa0f-f9812afb8923; At 569/1: "Uncaught EspMethodCall:invoke: Operation[data:queryExec] queryParams validation error: The value 'Requests_bpm_assignTeamOwnerCapacity_TeamDetails' for element <queryColumns> is not an allowable value at location '/methodCall/params/queryOptions/queryColumns'" throw(e); Cheers Martyn
  22. Following further investigaiton, this is affecting all our requests irrespective of their source. Cheers Martyn
  23. Our BPM process is failing since applicaiton of Service Manager v2.36.3, referencing an issue with assignTeamOwnerCapacity when incidents are logged via the selfservice. Initially I thought this was down to a change in the behavoiur of the Assign to Request Creator node, but I have bypassed this and still get the issue. Cheers Martyn
  24. @James Ainsworth Is there an update on KE00141270 as this is still causing us an additional step for every email we deal with. Cheers Martyn
  25. It would be really useful to have the 'Raise New' facility directly under the Service Manager left application icon, to allow faster direct access to raising a new request without having to open the Request List screen. This means quicker navigation for the end user and avoid unnecessary query of the database to generate a request list screen, just to then click on the Raise New button. If this then gave you the option as a submenu for the specific types like the button button does now or opens on a page allow you to select the type of request to raise. Cheers Martyn
×
×
  • Create New...