Victor

@SJEaton since it can't be saved, I was thinking to have a look at this ProCap in a remote session...do you have 10-15 min this morning to do this?

@SJEaton hmm... do you still have the ProCap config open in a browser tab?

@Paul Alexander defect was always there since the "Log Request" BP node was introduced... as far as I know it will be fixed in the next update. To give a brief overview why this is happening, the log request process fails when trying to send an assign notification to request owner (either the user owner or the users in the assigned team) because it can't find the ID for the request timeline which is needed to insert the "request assigned" timeline update... Thinking on how to overcome this for the time being, I looked at the log request flowcode and I think we can bypass the error (the faulty bit of code) if the child request is logged without a team and owner from the parent request... then once the child request is logged, have the BP in the child request do the request assignment...

@pproot if the report is using SQL schema designer you can join up with asset type table to get the type name... or use a CASE in SELECT statement but that needs to be maintained...

@TrishaRush we are working on a Scheduler app, however not sure when and how it will available in live instances... short answer, no, not with current functionality

@SJEaton ProCap name/ID and at what stage during ProCap you encounter this...?

@Rachel Crisp hmmm...apologies, the same logic applies to Team criteria (same logic for Service)... As previously mentioned, request visibility is determined by Team and Service (via subscription). A custom view that does not have specified on or both of these criteria will apply teh default logic, which is to filter out requests you should not normally have access to... So, to view ALL closed requests you need to following criteria in the custom view: Status: Closed; Service: add all services; Team: add all teams (you should be able to select all teams supporting all services). Apologies, although I did mention the team/service visibility logic, I forgot about the Team aspect in custom views...

@Rachel Crisp do you know by any chance the request reference?

@Dan Munns sorry, don't really think you can achieve this in a simpler way with current functionality You can have actions disabled and enabled via BP...So disable actions while the task is active... loop the task until the condition is met (category is set) then enable the the actions...

@TrishaRush no, not possible, but you should be able to copy nodes (and groups) across processes...

@Rachel Crisp based on this: Since you don't see/have access to closed calls in default request list views, I assume this "Closed Calls" is a custom view... In a custom view, if there is no service criteria, Service Manager will apply the same "subscription" criteria I mentioned above (which applies to default views such as "My Teams" or "My Services"). So, besides the role I mentioned you also need to specify which services the custom view should display... If you need to see ALL closed calls then you need to put ALL services in the service criteria... EDIT: @Ralf Peters beat me to it

@David Calder yes, you should be able to... https://api.hornbill.com/admin/?op=userProfileSet

@Rachel Crisp request visibility is restricted to teams and services that a user is configured for (i.e. user member of teams supporting the service and/or user subscribed to a service). Also a user can access/view requests where he/she is a customer on the request. This visibility restriction has been introduced for security and confidentiality reasons across teams and departments in an organisation. However there is a way to allow a user unlimited access to all requests by granting the user "Service Desk Admin" role via Hornbill Admin tool.

@Dan Munns I'm afraid the "action focus" is exactly what the word implies... a focus on an action on a request. By action I mean any available top buttons representing an action on a request. There is no "action" per se for setting category therefore there is no option set focus to it... Maybe create a manual task "Set the request category" which will only create if the BP reaches that point and if there is not category set at that time... and don't let the BP progress until the task is complete...

@Martyn Houghton maybe it is possible to (temporarily) disable "BareLinefeedRejection" on the receive connector? As far as I know you can do this on an on-premise Exchange using set-receive connector but I don't know if and how this can be done in Office 365

@Martyn Houghton on the file system I'm afraid

Just a quick update on this issue. Our investigation so far reveals the issue to be isolated to emails which are using templates (specifically the CK Editor we are using when designing email templates). All other outbound emails (such as email sent from our mail interface and email sent using default and not edited templates) are not affected. This is not caused by any change we have done recently in Hornbill. For Office 365 users it occurs because until recently, Office 365 automatically removed bare line feed characters from mail to help it get delivered to recipients using email servers that don’t support chunking and the BDAT command (such as Hornbill).To comply with RFC 2822, Office 365 no longer removes bare line feeds from messages. As a result, messages sent to users from Hornbill may be more likely to be rejected. (https://support.office.com/en-us/article/Fix-email-delivery-issues-for-error-code-5-6-11-in-Office-365-81dafee7-26af-4d79-b174-8f78980dfafb?ui=en-US&rs=en-US&ad=US) For other mail services users (e.g. MS Exchange) the issue could occur due to SMTP connector changes whereby the connector is now configured to reject bare line feeds. Currently we working to get Hornbill mail in line with RFC 2822 requirements (https://forums.hornbill.com/topic/10012-dkim-for-outbound-email/). For the time being we suggest the following possible workarounds: create an inbound transport rule on your mail server to append a disclaimer to the messages from Hornbill. The disclaimer will append the expected CR-LF combination to the message so that it can be delivered. This disclaimer may consist of a single character such as a period or a dash (https://support.microsoft.com/en-us/help/2998901/-smtpsent.barelinefeedsareillegal-ndr-received-by-exchange-online-or-eop-users-in-office-365-dedicated-itar). avoid the use of email templates which have been edited in the email template editor - CK Editor - (out of the box templates which have not been edited should not have this issue).

@chriscorcoran resolution 1 day does not necessarily mean a business day...it means 24 hours... which are business hours... you would need to set the resolution to 8 hours (or whatever the number of hours you have in a business day in your SLC) to achieve 1 business day resolution.. I have detailed the SLA days/hours calculation algorithm in this thread:

@nasimg it refers to this: It's all part of the "sub-status" functionality introduced in 963.

@Stephen Hutchinson just an FYI that there are some updates on this issue discussed here:

@Dan Munns I think this need a bit more thorough investigation...would you mind raising an incident with support desk here: https://www.hornbill.com/support/? Thanks!

@samwoo there is no support email address... We have a support page on our website: https://www.hornbill.com/support/. Please use this If you need to raise an issue with our support desk.

@samwoo was curious if there is any reason why you don't use your success plan perks, such as raising an incident with our support team?

@Paul Trenter @nasimg you could also make use of the new "sub-status" functionality... as you can now set/change a sub-status when a customer updates a request via portal...

@Stephen Hutchinson you won't be able to see the lines ending with just an LF even with a "trained" eye ... I am (we are) almost certain it is the email template editor which creates the LF and not the LF-CR. However I am certain that the issue did not occur due to recent changes made in templates. I would advise to apply the suggested workaround while our dev team investigate a possible alternative to enhance Hornbill SMTP connector (meaning that Hornbill SMTP could "normalise" the message before sending).