Jump to content

Ehsan

Hornbill Developer
  • Content Count

    635
  • Joined

  • Last visited

  • Days Won

    24

Ehsan last won the day on January 14

Ehsan had the most liked content!

Community Reputation

110 Excellent

1 Follower

About Ehsan

  • Rank
    Senior Member

Profile Information

  • Gender
    Male
  • Location
    South Ruislip, London

Recent Profile Visitors

1,587 profile views
  1. @Charlie Jones, @Steven Cotterell, @PeterL, Your instance has been patched. Ehsan
  2. Hi @Jamie Talbot, This is related to the reported issue below. Your instance has been patched automatically. Ehsan
  3. Hi @Paul Alexander, I've looked into it and adding and updating an FAQ works as expected. Could you provide us with a breakdown of how they were able to replicate this issue? Is more than one FAQ affected? Which field(s) are they updating, that result in this error? If they were to clear their cache/cookie and login again, are they still able to replicate the issue? Ehsan
  4. @Steven Cotterell, @PeterL, Did you restart the Request's process for the affected Requests or are these new Requests? The patch has definitely taken affect.
  5. @Alberto M, All Hornbill instances have been patched, including yours. For the Requests that were effected by this failure, a restart may automatically resume the Request's progress. Please refer to "How to restart a failed workflow" section in the Wiki document below for instructions: https://wiki.hornbill.com/index.php/Business_Process_Designer
  6. @Neil Smith, We've been closely monitoring performance related issues and a restriction was added to prevent an UPDATE statement from being routed to the database server if the values that are being updated hadn't changed. The operation that updates a Request's status through the Business Process, contained a process to reset Request's sub-status in the event that a Request's status has changed. The code didn't include logic to prevent resetting the Request's sub-status if the value hasn't changed. This was not caught by the application's automated tests in this area, as the tests in place validated that a Request's status and sub-status are changed accordingly. We've now added an automated test to validate the scenario where the Request's status is changed through a Business Process without changing the sub-status. The restriction that was added by platform tests did not include a scenario where the primary key of the database table in question had a customised "autoVal". We've also added a platform test to now test this scenario. Apologies for the inconvenience that this has caused. As we've added more tests around this scenario, we aim to eliminate the occurrence of this issue in the future and we hope that the restriction added will improve the traffic on the database server. Ehsan
  7. @Shamaila.Yousaf @PeterL, This has been applied to your instances. For the Requests that were effected by this failure, a restart may automatically resume the Request's progress. Please refer to "How to restart a failed workflow" section in the Wiki document below for instructions: https://wiki.hornbill.com/index.php/Business_Process_Designer Ehsan
  8. @Paul Alexander, Your instance has now been patched.
  9. @Michael Sharp, @Julie McClelland, @Paul Welby, @nasimg, @AndyHill, Your instances have been patched now. Please do remember... For the Requests that were effected by this failure, a restart may automatically resume the Request's progress. Please refer to "How to restart a failed workflow" section in the Wiki document below for instructions: https://wiki.hornbill.com/index.php/Business_Process_Designer Ehsan
  10. Hi @HGrigsby, This should be addressed on your instance now. Ehsan
  11. @Neil Smith, @Charlie Jones, @Vikki Cameron, @Blowerl, @Philip Walker, We have identified the cause of this issue. This will be patched directly to your instance very shortly. Apologies for the inconvenience that this has caused. For the Requests that were effected by this failure, a restart may automatically resume the Request's progress. Please refer to "How to restart a failed workflow" section in the Wiki document below for instructions: https://wiki.hornbill.com/index.php/Business_Process_Designer Thanks, Ehsan
  12. @Gareth Watkins, Could you provide me with a screenshot of the Hornbill Automation that you're using to archive a user?
  13. Hi @Gareth Watkins, In your Progressive Capture, the field within the Customised Form should use the data query option below. In your Business Process, use the Hornbill Automation below (Requests > Get Request Information > Progressive Capture Answers) to load in the form that was submitted via the Progressive Capture. Using the Variable Picker, locate the Progressive Capture form in question and select the field that you had configured to select a Co-worker. At this point, click on the Inject drop-down button and select Raw Value. This injected value would contain the user's Id (h_user_id column in h_sys_accounts table). I hope this helps? Ehsan
  14. @Adrian Simpkins At the moment it's not possible to provide a reason when adding a Member so your suggestion is spot on.
  15. Hi @Adrian Simpkins, You'll need to add an analyst as a Request member in order to grant them access to view and action on the Request. By enabling "guest.app.requests.notification.notificationType.membersRecipient" application setting, members who are added to the Request will receive a notification. Tagging an analyst in a Timeline update does not grant them access to the said Request. Hope this helps. Ehsan
×
×
  • Create New...