Jump to content

David Hall

Hornbill Developer
  • Posts

    658
  • Joined

  • Last visited

  • Days Won

    34

Posts posted by David Hall

  1. Hi @derekgreen

    Thanks for the post.  In quick summary, the priority based service levels do not initiate a change in resolution times, the reason behind this is explained by one of my colleagues here 

    However we are rolling out service based service level management which will provide the ability to change the selected service level/targets per request as needed.  You may find it useful to read the full forum thread, but details of the new SLM functionality that is coming out of beta can be read starting here

    Regards,

    Dave.

     

  2. Hi @Martyn Houghton

    Thanks for the update, we've still not been able to replicate this locally, the only time we have seen anything similar locally is where we have had a browser caching issue which caused the request list code to be out of date and hence not load the view correctly.  I know you have tried different browsers so its unlikely to be that, but perhaps its worth trying to clear the browser cache on one of the affected cases to see if it makes any difference?  In the meantime I will log a problem for this so that we can investigate further.

    Regards,

    Dave.

  3. Hi @Awalker

    Thanks for the post.  The template you downloaded contains all of the fields that are currently available to upload to for the telecoms asset type so it is not currently possible to add any further fields as you mention.  Would you be able give some examples of the types of telecoms assets you are trying to upload that require the serial number and model to be stored and we can then look to get this considered for a future change request?

    Kind Regards,

    Dave.

  4. Hi Derek,

    The SLA's and timers are all determined by your chosen workflow, as it is within that workflow that you choose to start/stop those timers, however you may have a different workflow selected for Incidents/Service Requests/Problems etc which could account for the difference.

    If you open the service view for the relevant service, select the "Request Config" tab you then have a tab for each request type.  On each request type you can then set the appropriate workflow that should be used.

    Alternatively, if you do not wish to set this per service, you are able to a default workflow for all request types via the admin tool, if you go to Home -> Service Manager -> Application Settings and search for 

    app.requests.defaultBPMProcess

    you will see a setting for each request type where you can select a default workflow.

    Regards,

    Dave.

     

  5. Hi Derek,

    When you view the details of one of the requests, is it showing the correct BPM process stages etc in the heads up display at the top of the request details view?

    If not then I would just double check the following:

    - Within the service view for the service being used against the request, check that you have the correct workflow selected for Incidents and Service Requests

    - Within the admin tool, confirm that the workflow set against the service is active

    If this all looks correct then let me know and I will see if we can find any identify any errors from log files.  

    Regards,

    Dave.

  6. Hi Kelvin,

    It looks like it should be working to me, I've tested those locally and for me they work as expected.

    Normally you would only see the placeholders when the values are not available at the point of the email being sent, when you look at the request details for the request above are the summary and description displayed correctly within the details section?

    Regards,

    Dave.

  7. Hi Samuel,

    Thanks for checking the setting, we have logged a problem to investigate if there are issues with that setting.

    As for the SQL update you are suggesting, I'm afraid I personally have no access to your instance data so I couldn't advise whether the selection was accurate or not.  In general all updates should be made via the API calls to maintain data integrity to avoid missing any possible related data so I would not want to recommend a manual SQL update.

    I appreciate that you may have a large volume of tasks to cancel, if I can find a better way to do that I will post back.

    Regards,

    Dave.

     

  8. Hi Samuel,

    With regards to the tasks not being cancelled when cancelling a request, there is a Service Manager application setting that enables or disables the cancelling of related tasks which is:

    webapp.view.ITSM.serviceDesk.requests.cancel.cancelRelatedActivities

    So you may want to check as it could be as simple as not having this option turned on.

    As for cancelling the existing tasks, yes the h_state field in h_sys_tasks relates to the task status and for cancelled status this value should be set 10.

    Hope that helps,

    Kind Regards,

    Dave.

  9. Hi Tina,

    I have just tried this again myself and it seems to be working correctly.  Can you confirm if you are testing with an email entry that has been sent from the request today after you have applied the latest update?  

    Because the issue was related to the email not being linked with the Request at the time it was sent, it has not been possible to retrospectively fix existing email entries which were missing the link, however any sent following the update today should be working and provide the "View Email" option from the ."More Actions" menu.

    Kind Regards,

    Dave

     

  10. Hi Melissa,

    Thanks for the post, I can confirm that it is not currently possible to edit the responses to questions that have been added against a request as these would normally be responses from customers that would be unlikely to change.

    Perhaps if you could give an example of when you need to edit such responses we can look to see if there is another way to currently handle it, or put editing questions forward for consideration as a future change.

    Kind regards,

    Dave.

  11. Thanks for the post.

    All of the requests, regardless of the class Incident/Problem/Change, use the same auto value counter "itsmRequestsAutoId" to increment, so it would only really be sensible to reset the counter if you were to clear down all requests otherwise you could possibly run into scenarios where requests may fail to log due to it trying to create a duplicate reference.

    Regards,

    Dave. 

  12. Thanks for post Bob320,

    Currently as you have identified the only way to perform the updates via the flowcode is to get the existing record data and then supply all populated data fields to the update even if you only want to update a single field, this is the way it is currently used within the application where we do supply all of the relevant data fields on updates.

    I would agree that the flowcode parameter validation does not make much sense when other values do need to be supplied to prevent data loss, therefore I have raised a problem for the development team (REF: PM00142915) to address the validation and also review if any improvements can be made to the flowcodes to remove the need to supply the array of extra values when only performing an update on a specific field.

    Regards,

    David.

    • Like 1
  13. Hi Dan,

    I don't believe there have been any changes made in this area.  Provided you are logging an incident or service request and you have existing templates then they should be made available on the "Request Details" form within the progressive capture.  

    When you manage the templates do you still see all of the templates that you created?

    Have you made any configuration changes around which progressive capture (PC) process is in use when logging the request?  First step would be to check which PC process is in use when logging and check that it is using the "Request Details" form where the templates should be shown.

    Regards,

    Dave.

×
×
  • Create New...