Jump to content

Victor

Administrators
  • Content count

    1,600
  • Joined

  • Last visited

  • Days Won

    25

Victor last won the day on January 10

Victor had the most liked content!

Community Reputation

132 Excellent

2 Followers

About Victor

  • Rank
    Senior Member
  • Birthday February 22

Profile Information

  • Gender
    Male

Recent Profile Visitors

988 profile views
  1. Email Formatting

    I am looking at my statement and I must say is rubbish... because is not true! .. .well it is, in a way, but only because a particular application setting has "RequestMessage" configured as template... So, to make things clear and correct myself: on the service you can set an email template to be used when sending emails from requests raised against this service. You can choose any email template from the list however, there is an option to specify to use the "default" template for request messages: "Default (...)". This "default" template is set by this application setting: app.email.template.request.sendMessage. The default value for this application setting is "RequestMessage" template, and now you understand why I said my original statement is "sort of" true but not really... In your instance however it seems whatever value was set for app.email.template.request.sendMessage no longer exists and because of it does not exist it is automatically replaced with: undefined. EDIT: after a few tests it seems this (quote: automatically replaced with "undefined") is not true either, so all the below also becomes null... The value for the setting(s) is now "undefined" I have to find out how this happened...Need to have a more thorough look into this on Mon. So are you aware of anyone deleting any templates? Possibly the template configured in app.email.template.request.sendMessage was deleted by somebody by mistake? I'm afraid I can't tell what was the previous value for this setting... and is not the only "template" setting that has "undefined" value...
  2. Integration Call (Convert Date/Time)

    @SJEaton the date/time value in the custom field is stored as YYYY-MM-DD HH:MM:SS. This is the, let's call it, calendar date/time format,that needs to be "translated" into the integration node date/time format (PHP date formatter) for "Input format" field. So, looking at the PHP date formatter page (http://php.net/manual/en/function.date.php) we have the following: for YYYY - the format we need is: Y - a full numeric representation of a year, 4 digits for MM - the format we need is: m - numeric representation of a month, with leading zeros for DD - the format we need is: d - day of the month, 2 digits with leading zeros for HH - the format we need is: H - 24-hour format of an hour with leading zeros for MM - the format we need is: i - minutes with leading zeros for SS - the format we need is: s - seconds, with leading zeros So the input format should be (taking into consideration dashes, colons and spaces): Y-m-d H:i:s Have you tried this input format? (EDIT: the case is important here as the format is case sensitive) P.S. Apologies, I did not have chance to look at the example you posted, but I thought to confirm the input format that is being used...
  3. Email Formatting

    undefined... hmm... the default template on services is "RequestMessage" ... does this template exist in your instance? If not, any chance someone deleted it? I know you can do SQL functions in ESP variables...like using SUBSTR and like... maybe something like this? You can safely ignore this, only templates that work are "Requests". The intention was to have different template categories (the drop down list). These categories in their turn will make available specific contextual variables... like you have SLA, Team, Customer, etc. variables for "Requests" templates, you could have a different set of variables at disposal for template category, for example, "Services" or "Tasks" ... unfortunately, this was never implemented, not yet anyway, is still something on our "to do" list... however is not really nice to see the error so I'll ask internally...
  4. Error while applying an email to a request

    @Giuseppe Iannacone I understand the scenario, but team membership has nothing to do with the error... You are affected by the highlighted defect on our portal: https://success.hornbill.com/hornbill/servicemanager/service/2/known-issues/ Sometimes the workaround described in the forum thread I mentioned above (trimming down the email) allows the user to successfully apply the email. However, if the workaround fails, then you would need the fix (probably will be in next Service manager update)
  5. Email Formatting

    @Dan Munns seems the service does not have a template to be used when sending email from requests... check the service configuration for this request type and see if is using an existing template...
  6. Error while applying an email to a request

    @Giuseppe Iannacone It's not what you think it is... The issue has been raised before have a look below. We also suggested a solution there, let me know if it works for you.
  7. Integration Call (Convert Date/Time)

    @SJEaton no, sorry, didn't have a chance to look yet, will try and have a look later today...
  8. form data not populating requests table

    @Gary@ADL can you have a look at the questions section, the answer that did not make it into the custom field, is the character count greater than 255? If yes, then this is the reason why the custom field was not populated. The max size of the text that can be stored in a custom field (currently) is 255 characters. Anything greater than this, will not be stored in the custom field. I said "currently" because the next SM update there are some changes around this functionality, e.g. additional custom fields that allow an unlimited number of characters to be stored.
  9. Auto-Chase Requests

    @Keith @DeadMeatGF yes, anytime now... should be deployed, I think, early next week...
  10. BPM process error

    @J_Tamburrini ah... I think if the stage gets deleted then the "Nest Stage" node referencing the (now deleted) stage will throw this error... So my advice would be if you delete a stage then update any "Next Stage" node from the previous stage (delete and recreate the node so it refreshes)... I'll ask internally with our dev team and see if we can cater for this scenario more gracefully (e.g. perhaps update the stage IDs upon saving or validating the process). Let us know how you get on with the process and if there is anything we can help with
  11. Auto-Chase Requests

    @Keith it seems I was talking rubbish ... ... The fix is not yet in live instances, it will be on the next Service manager update... I have no idea why I thought it was already available... I am sorry *sniff...
  12. BPM process error

    @J_Tamburrini I had a suspicion the first error might have something to do with the team, this is why I asked: "does the request where the error occurs have a team assigned" ... but I haven't received any reply from you so I thought the issue no longer occurs However, I am happy to hear that issue was resolved! The other error you encounter suggest is something to do with stages configuration... did you at some point delete and recreate the "Admin Tasks" stage by any chance?
  13. 2 stage closure inconsistency

    @ShalilK ok, thanks for the update. I will have a look at these examples tomorrow morning.
  14. Auto-Chase Requests

    @dwalby @nasimg @Dan Munns @samwoo @Keith I know you thought I forgot about this thread, I didn't ... I did manage to create a "self-sustained" chasing mechanism not using multi "wait for status change" nodes but is it quite convoluted making use of statuses and sub-statuses and I didn't like it... ... However, now the fix for multi "wait for status change" nodes is available so the auto chasing mechanism should be easy to build
  15. Updates on closed requests

    @m.vandun for updates on closed requests, we have two application settings that will decide what happens with the update. ON = the update will be applied to the closer requests. OFF = the update will be rejected and the email will be moved to the "Failure" folder for the routing rule that processed the email. So yes, it is: Not in current functionality...
×