Jump to content

Victor

Administrators
  • Posts

    5,683
  • Joined

  • Last visited

  • Days Won

    168

Posts posted by Victor

  1. 13 hours ago, will.good said:

    publish a database direct query to reports viewer

    @will.good so what is requested here is basically a report... which we have as functionality. I'll expand on this: I do understand that DB queries give far more options and flexibility in terms of filters and such but at the same time DB queries are gated behind SQL knowledge and knowledge about our data model and structure which not every user has and is certainly not something we would require from any user. Also, it is always a possibility that a specific query is poorly constructed causing issues for an instance. For these reasons, we will not expand Direct DB beyond what it is now. My advice here is that if the current reporting engine does not allow you to build a report that returns the results that a certain query returns, then request the reporting functionality to be enhanced.

  2. Based on the screenshot, the challenge here is that the workflow is not actually in a Failed state but is also not in a "true" Suspend state (the node there is not a Suspend type node) so Restart and probably Resume will not work here. I have seen this before where the workflow can get into this strange state of neither failed nor suspended and it cannot be "restarted" by normal means. If none of these suggestions here work, raise an Expert Service request and we'll have a look to see if we can resume it.

  3. 21 minutes ago, Jim said:

    do you know if there ever will be something implemented like an archive or a toggle to hide from view?

    @Jim as far as I am aware this thread (as with any thread on our forums) is posted on our internal workspaces where product managers and developers review them. As if and how it will be implemented, I cannot say. Perhaps something you can discuss with Customer Success if it is a subject of interest.

  4. 19 minutes ago, Jim said:

    I would normally expect them to be hidden by default and possibly compressed in an archive?

    @Jim I understand why/how the term Archived can be read as you did, however, in this context, Archived represents what is the asset status in your (physical) inventory not what is the asset as a record in the Hornbill database.

    14 minutes ago, Jim said:

    we would not be expected to clean up our footprint when historical data was no longer required?

    You can perform a data cleanup at any given time according to your needs. Steve advised of its primary purpose and what is mostly used for, but is not limited to just removing test data.

    16 minutes ago, Jim said:

    won't this have an impact on our allocated storage in 5 years and then the following?

    Depends on how many asset records you have in Hornbill. But I would say, storage for asset data alone only becomes noticeable when we talk of numbers in the hundreds of thousands possibly even more. Usually, most storage consumption in an instance is attachments and data for active running workflows/BPs.

    • Thanks 1
  5. @Jim it has indeed... As much as we would like to have everything fixed at once, we (by we I mean development) do need to prioritise work so they work with a priority list. Sadly, this defect did not make it high enough on the list yet...

    • Thanks 1
  6. @CraigP questions are for the values of questions and answers, questionsFieldMap is for any mappings that you have for answers (the answers mapped to request fields). If you are simply looking to have a set of questions and answers on a request then this thread can be useful:

    For example below is a payload to raise an Incident with

    Summary: Test Summary
    Description: Test Description
    No customer (if a customer is required then <customerId> and <customerType> would have to be set)
    Service: 666 (this is the ID of the service of the request, needs to be a value for a service in your instance)
    Questions:
    Field 1 (type Text): 123 
    Field 2 (type Textarea): 456

    <methodCall service="apps/com.hornbill.servicemanager/Incidents" method="logIncident">
    <params>
    <summary>Test Summary</summary>
    <description>Test Description</description>
    <requestType>Incident</requestType>
    <customerId/>
    <customerType>0</customerType>
    <serviceId>666</serviceId>
    <questions>[{"form_id":"form_1","question":"Field 1","question_id":"field_1","answer":"123","answer_value":"123","field_type":"text","entity_type":"request","hbfield":{"question":"Field 1","field":{"id":"field_1","defLabel":"Field 1","transLabel":"x","binding":"global.form_1.field_1","noInvisibleValue":false,"design":{"isVisible":true,"isMandatory":false,"isReadOnly":false,"showIfEmpty":false,"extraClass":" "},"control":{"type":"text"},"uid":""},"value":"123"}},{"form_id":"form_1","question":"Field 2","question_id":"field_2","answer":"456","answer_value":"456","field_type":"textarea","entity_type":"request","hbfield":{"question":"Field 2","field":{"id":"field_2","defLabel":"Field 2","transLabel":"x","binding":"global.form_1.field_2","noInvisibleValue":false,"design":{"isVisible":true,"isMandatory":false,"isReadOnly":false,"showIfEmpty":false,"extraClass":" "},"control":{"type":"textarea"},"uid":""},"value":"456"}}]</questions>
    </params>
    </methodCall>

    image.png

    It is a simple question capture but it should give you some guidance on how the JSON string would need to look for adding questions on requests. Please be mindful that the payload can differ if we have things like translations or some very specific capture configuration that you want to mimic in the payload (which are actually not relevant for the API, this is mostly for how the capture works when the user inputs data in UI). I will put the expert service request on hold until you have a chance to review this. If you still have any further queries and/or need assistance with this I will allocate the expert service request to one of our tech specialists and they will progress this forward.

     

  7. @Jim this is an oversight on our part. That documentation should be retired, the templates were a feature we thought of having back in the early days however, since then it was rendered obsolete by progressive and intelligent capture mechanisms. Request Templates have been deprecated and retired and no longer exist in customer instances. You can use intelligent captures to achieve what the templates would have provided.

    • Like 1
  8. Just some more information as to how that was the cause in case anyone else reads through this in the future.

    The problems that were missing the timer were not using the intended workflow, they were using a different one based on the value set on app.requests.defaultBPMProcess.problem. That workflow did not contain the Start Timer nodes or they were not in a position in the workflow that trigger the SLM evaluation. As a side note, the app setting mentioned here comes into play when the service does not have a workflow configured for Problem request types.

  9. @billster then probably there is some configuration missing somewhere... you said the SLA is set and not the SL so I would check the rules for service level if the criteria set there is matching the request data for the problem request that you are raising (e.g. if the criteria in rules is Priority = X then ensure the problem request has a priority and is the priority X when the SLM triggers, etc.)

  10. @billster do you have SLA/SL configured for Problem requests? And do have the Start Timer nodes in the workflow/BP for the Problem requests? The timers on any request type follow the standard SLM configuration. If you have timers working for other request types you would need to have the same configuration in place for Problem requests.

    https://wiki.hornbill.com/index.php?title=Service_Level_Agreements

    https://wiki.hornbill.com/index.php?title=Structure_Service_Level_Management

×
×
  • Create New...