Victor

@Will J Douglas known issue I'm afraid, is being worked on.

@Stefania Tarantino may I ask why you need to have an exported list of these? The report provided by @James Ainsworth is quite all right however, I see it does query BP instances table which is a table that is not quite designed for reporting... in addition this is one of the most heavily used tables in HB so some care should be taken when used outside it's purpose...

This should now be fixed on all affected instances.

Yes, fix in progress... we will have all affected instances sorted shortly.

@JanS2000 yes the > is the formatting for > ... So what I would say you need there is like this (so dash and >) You can have just the ">" but what you would have had (if it wasn't for the formatting) would have been "->" so, it depends on how you want to separate categories with just ">" or "->"

@JanS2000 it would be the Profiles in admin console: And in here, you would navigate to Requests. In here it could be Name or Code Separator that might have an incorrect value:

@Salma Sarwar you don't... the sub-status does that for you, no need to have the BP doing this... the email update is considered a "customer response"...

@AlexOnTheHill @Martyn Houghton @HHH @Jeremy development is now working on a fix for this defect. If you like to be notified when the fix is deployed please navigate to our customer success portal in Hornbill Support Service on Published Defects tab. Hit the "Me Too" button on the defect and you will be added as an impacted connection to it. Reference: KE00174669 @JanS2000 for the "category" timeline entry you have posted, have a look in categories configuration, it might be that it has an incorrect delimiter set up there.

@HHH Super User role... but I don't think you want anyone to have this role just for editing other people timelines...

@MichaelB more of a query for integrations/API. I have moved the thread there. This might help:

@Salma Sarwar I am not sure you need the same thing that @James Ainsworth was referring to... The idea of this post was that Will wanted to suspend a process waiting for a request update OR a request update from email (so one or the other). His thought was that it could be done using parallel processing. However in current BP engine you cannot have (any) suspend nodes (except human tasks) inside a parallel processing sequence. This (suspend nodes in parallel sequence) is being considered for the next iteration (version) of BP engine. As for take a request off hold when an email update is received, you can achieve this with request sub-statuses as I mentioned on your other post here:

@Stefania Tarantino the expression above is a standard SUBSTRING expression use in SQL syntaxes. What it means is that it will check for the value of the variable to not be its syntax. Is just one way of doing this, I have included another option further below. But you cannot use the empty modifier on ESP conditions, the variable itself in the condition will never be empty, it will always have a value. The way the variables work in templates is they correspond to a table field. For example "{{.H_summary}}" variable corresponds to the request summary for the respective requests. The way the email template variable work is that if the request summary has a value in the database for that request, the variable will translate into the summary value. If the request summary does not have a value in the database, the variable will not translate into anything and it's value will be {{.H_summary}}. Therefore for the condition to check if the request summary has a value we need to make sure the variable value is not {{.H_summary}}. Another expression you can use there (instead of SUBSTRING) is: '{{.H_summary}}' NOT LIKE '%{.H_summary}}%' We need {{.H_summary}} on the left so the engine reads the value as a variable so it translates as described above and we need the %{.H_summary}}% in the right so the engine does not read the value as a variable that it needs to translate. EDIT: to clarify, we don't specifically need %{.H_summary}}% in the right or the "NOT LIKE" or the "SUBSTRING" expressions. We would need anything or something that would make the expression validate if the value is or isn't {{.H_summary}} (depending if the expression needs to check for a value in the correspondent table record or not - meaning an empty value in the correspondent table record). The above are just two suggestions that achieve this.

@Stefania Tarantino You need to chain 2 conditions: 1. For the summary having content and the ESP condition would be: I wrote the condition here for better visibility SUBSTRING('{{.H_summary}}', 4, 10) != 'H_summary' 2. For the summary not having content and the ESP condition would be: I wrote the condition here for better visibility: SUBSTRING('{{.H_summary}}', 4, 10) = 'H_summary' This is how it would look in the template, even if they look like one block, there are 2 separate conditions there: The template source would be something like this (so it shows there are 2 conditions there): Also this is a similar discussion:

@Hiten via GIPHY

You need to look at the intelligent capture configuration used for raising requests from emails and Service Requests. This might very well be different than the capture used for same action but Incidents and might be different from the one used for "Raise New" in request list. First identify which capture initiates when using "Raise Request" when viewing an email. The capture used here is configured in app.itsm.progressiveCapture.newRequestFromEmail app setting. If this setting does not have a value then the capture used will be the one set on app.itsm.progressiveCapture.newRequest. See what capture is configured them look at its configuration and see if you can find why when raising Service Requests from emails don't give you the option to progress past services list...

@Stefania Tarantino it is definitely a template that has been changed from the standard default... it is possible the summary/description are supposed to be in an ESP condition but maybe something has broken that... for example, these conditions can easily break if the template is copied, pasted somewhere else (e.g. Word or other editor) where is reformatted and such, then pasted back... unfortunately I can't say from a screenshot, if you think the template is set up correctly but still not working properly then we can have a look via a support request.

@Stefania Tarantino we cannot troubleshoot the issue you are reporting based on the description alone, we need to look at some examples of the issue so a support request would be needed.

@Stefania Tarantino This is dictated by guest.app.requests.notification.notificationType.assignmentTeam app setting. It is enabled by default. Disabling it will stop notifications sent to the team. Assuming you are talking about email notifications then this is dictated by guest.app.requests.notification.emailTemplate.groupAssignment app setting. The default value is "TeamAssignmentNotification" and can be changed to a different value representing an email template that exists in your instance. This is a default template, it means it exists in every instance when the instance is created by Hornbill. It can be amended, reconfigured as needed. If you like to understand more about notifications in general, including the notifications for request assignment please review: https://wiki.hornbill.com/index.php?title=Service_Manager_Notification_Settings It is possible the values for summary and description have been configured to use ESP conditions for when the summary and description variables have no value. We can't say if and how without looking at how the template is configured. It can be that the email is triggered before the request has summary and description hence the variables will have no value. If the template is using ESP conditions, it can also be the condition is not configured as needed. We can't say if and how without looking at how the template is configured. If the text is configured based on ESP conditions, is not just simply deleting the "incorrect" text. The condition needs to be reviewed to understand why the text appears when it is believed it should not. What exactly you're asking when you say if something has changed?

@Dave Longley this is not currently possible in that area.

@JanS2000 yes, would help keep a better track for where we are with this. We did raise this with development and a support request should bring more attention to this.

@Paul Alexander so there are a few things here that, perhaps, could use some clarification. The asset data you have in your instance is incorrect as the database value for Used By is missing the user type part. This is due to import data which did not have this value at the time of the import. This needs to be rectified by adding this value in the import data. While the values stored in Used By filed did not cause a problem in the UI, now there are additional checks in place that validate the format and in case of an incorrect one will not display the information. In other words, this was an oversight in the system (which was now corrected) but unfortunately this affected the values you currently have which are no longer displayed. The solution here is, again, to correct the values for the respective fields. We have identified a defect whereby different letter cases in the user name will not be correctly parsed by the system leading to no values displayed in the Used By fields. This will be corrected shortly. There is also the aspect of the import mechanism allowing incorrect URN (the format we use in these fields) to be stored in the database. We are discussing this with our development team so additional checks are implemented for the import mechanism to avoid this scenario going forward (prevent incorrect values to be stored in the DB).

@AKetteringham I meant basic as in Microsoft basic (which does not work anymore), which in Hornbill would be classic. Here is some info, including troubleshooting that might be helpful: https://wiki.hornbill.com/index.php?title=How_to_configure_OAuth2_Authentication_for_Microsoft_Office_365_Mailbox_integration https://wiki.hornbill.com/index.php?title=How_would_the_Office365_administrator_approve_permission_requests https://wiki.hornbill.com/index.php?title=Troubleshooting_issues_occurring_during_the_setup_process

@AKetteringham MS Outlook is an email client so unless you have forward rules for the email accounts set in Outlook you won’t receive emails in Hornbill via Outlook. Hornbill mail service is also an email client. Unless I am missing something, what happens over there is that you could use (or so used) Outlook client to receive and send emails via the O365 account. You (also) have a Hornbill mailbox configured to receive and send emails using the O365 account. So in summary, there is nothing to revert to and almost certainly there is no “reverting to MS Outlook” in this scenario. Would be worth checking (test) the email connectors configured in Hornbill admin. Also, if you have not switched to oAuth authentication for the email connectors you would need to do so as basic authentication is no longer supported by Microsoft.

@Berto2002 at the moment the KE has been accepted and in progress. I do not have any other information on this at this time I'm afraid.

@Berto2002 the scenario you described has been identified as a product defect which is in development queue, ref: KE00174035. Any SLA re-evaluation will "reset" the response timer data (for response timers that were already marked) with incorrect values.