Jump to content

Victor

Administrators
  • Posts

    5,683
  • Joined

  • Last visited

  • Days Won

    168

Posts posted by Victor

  1. @CraigP I am sorry but we have never supported this approach in workflow node configurations. The node and variables are to be used as they are. Sure, with sufficient technical information, one can venture and do some advanced things like this but again, this would be outside what the functionality was designed for and thus not supported.

  2. @Osman as I explained above, based on my current understanding of how this is designed to work, the suspended workflows end up suspended indefinitely due to a workflow/request setup misconfiguration. If you believe the configuration is correct but for some (unknown) reason the workflow does not behave as designed or some other functionality does not work as intended (e.g. override locked actions), please use the advertised channels to raise a support request with our team for further investigation (https://www.hornbill.com/support/)

     

  3. @Marius thanks for the additional info however what I said above is still valid. It is very possible (I would say with certainty) that the workflow that runs for these requests is not reaching the stop timer node in this scenario, therefore the timer is not stopped. I have no idea how the workflow is configured but I would say have a look at the configuration, in the specific context that you have for these requests, and see if and how the workflow is not reaching the stop timer node(*)

    (*) this assumes that your request has a workflow that runs and this workflow has a stop response timer node

    I realised that I forgot to explain how workflows and timers interact above so I have edited my above reply.

     

  4. @Marius this is a red herring. The aspect of the customer and owner being the same person has nothing to do with request timers. Most likely either something working incorrectly in the SLM/BP engines (in which case you would see this on all requests not just that subset) and/or the workflow(*) is not set correctly to mark the timer. I would start by looking at the workflow to make sure that the relevant nodes (Mark response Timer) are in place for timer to stop.

    EDIT: (*)the workflow is solely responsible for stopping timers on requests, specifically response timers for which there is no other mechanism for this timer to be stopped 

  5. @Jim interesting and this is definitely a first :) ... While I do not want to temper the enthusiasm here, it would be good to see what APIs you make use of in this tool. Our API documentation is not really geared for this type of development (we have a new, better one being developed but this is WIP). It can be used, of course, but unless one is familiar with some underlying aspects of how HB works then is not very straightforward to make use of APIs in this way. The reason why I am asking about APIs is that we would need to ensure we don't end up with "broken" data, which would look ok on paper but in fact, is not entirely correct. For example, if your tool is making use of application APIs (e.g. com.hornbill.servicemanager::Asset/updateAsset2) then we should be ok (in theory) but if you use data APIs (e.g. data::entityUpdateRecord or data::updateRecord) then it can be a bit problematic as they work in a certain way (update one or a set of records in a specific table) and more would need to be done in terms of updating data to ensure related data, for example, are also catered for. If you use, for example, data::entityUpdateRecord for the assets table (and only this), your asset will look ok when you look at it in the asset UI but it might be broken in other areas because the asset related data is missing. On GitHub we have an asset import (and update) tool: https://github.com/hornbill/goDBAssetImport which can be used as a reference to see how we do the create and update of assets. It is possible you already looked at this but if not, it would be a good idea to have a look a the code.

  6. @Berto2002 the date/time values here need to be in ISO 8601 format. Durations in this format define the amount of intervening time in a time interval and are represented by the format P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W. In these representations, the [n] is replaced by the value for each of the date and time elements that follow the [n]. Leading zeros are not required. The capital letters P, Y, M, W, D, T, H, M, and S are designators for each of the date and time elements and are not replaced.

    • P is the duration designator (for period) placed at the start of the duration representation.
    • Y is the year designator that follows the value for the number of calendar years.
    • M is the month designator that follows the value for the number of calendar months.
    • W is the week designator that follows the value for the number of weeks.
    • D is the day designator that follows the value for the number of calendar days.
    • T is the time designator that precedes the time components of the representation.
    • H is the hour designator that follows the value for the number of hours.
    • M is the minute designator that follows the value for the number of minutes.
    • S is the second designator that follows the value for the number of seconds.

    For example, "P3Y6M4DT12H30M5S" represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds"

    • Like 1
    • Thanks 1
  7. 1 hour ago, DRiley said:

    If it is due to the image type, it would be useful to understand what image formats the image library supports. I forgot to ask, is there a wiki page with this?

    @DRiley no idea if is due to image size, could be, but based on your above comment, it might not. Afaik we don't specifically document a certain set of image types that we support which means we don't restrict any... I think perhaps we can make use of a support request to see if we can get a better understanding of how that happens (I have tried several images in my instance, to see if I can investigate this further there, but I don't encounter this issue)

×
×
  • Create New...