Deen

@CAllum181 Unfortunately going on the wiki article, it looks like only raise and update are possible via email at this time. https://wiki.hornbill.com/index.php/Email_Routing_Rules

@Jeremy as you have probably noted, there is the setting app.email.routing.rules.allowClosedCallUpdates.IN controls updates to closed requests. Unfortunately there doesn't appear to be a matching setting for resolved requests. We would probably need an enhancement for this. I have therefore tagged it as such.

@samwoo I take it the problem remains the same regardless of the browser used? Does the problem occur with different image types or is only one specific type affected?

@Nikolaj sorry for the delay in getting back to you. As far as I can see there is unfortunately no way to include archived users in the search. Please keep in mind also that suspended users are technically different to archived users as they are considered to be active users who have only temporarily been suspended.

@AKetteringham is everyone accessing Hornbill over the same network? In my experience network related issues can often be the cause of poor performance. It would be worth trying to access Hornbill from outside your company network to see if the problem persists.

Not that I can see sadly, perhaps copying the node before altering it to use as a quick reference when restoring any of the options that have been lost with the Task change.

@nasimg not that I can see, but it would make a useful enhancement,.

@Jeremy no problem, let me know if there are any errors in the log file that you need clarification on.

Changing the name would be a relatively simple matter however changing the ID would need to be done at the database level and would be more problematic. However if you continued reporting on the ID rather than the name that might get around the problem.

@Jeremy if you go into the Sent Items folder, select the email and click on the dual arrow icon in the email toolbar it should display the Message Delivery Status. The log should indicate if there are any errors. From looking at the log and the send time in the request timeline was it sent first time and in a timely manner, also are there are send failures listed here?

@Adambingley If you click on the arrow next to the Search icon you can filter the search by Type, Owner, Status etc which should reduce the search results to manageable levels. As you say improvements are being worked on but I find that filtering the search in the manner described helps.

@Martyn Houghton I'll make some enquires with our developers and will get back to you shortly.

@Shamaila FYI, you may find this post of interest.

@AndyGilly Internally I have seen some early work on this, but I could not say at this point when it may be released. I'll post back here when I have a further update.

I think it would be a tricky one to diagnose. We would probably need to go through the logs at the time of the assignment to see if there are any errors that might indicate the root cause. If there has been an example in the last week you could raise it with the Support team.

@Martyn Houghton @Paul Alexander this was raised as the following defect: PM00163844 - Direct Request list in the Service page displays requests raised against different services You should be able to track its progress via the portal.

There are also a number of suggestions for alternatives here:

@aw2215 I don't believe that it is possible to change the service type for a request that has already been raised. However it is being considered as an enhancement. There would be a number of complications with this however such as the BPM, pro cap, SLA etc having to also be switched.

@Dave Longley There are a couple of options, you could use the API Scheduler detailed below: https://wiki.hornbill.com/index.php/API_Scheduler Alternatively this is discussed in a number of forum posts:

@Adrian SimpkinsDifficult to say what might be causing this. When it occurs again we would probably need to look at the log files and the timeline for the affected request to try and trace the failure point.

The fix has been deployed to all instances so should no longer be an issue anyone is seeing.

@RobW as far as I am aware they should be able to login using the same link as everyone else. There is an option to allow direct login wwhich was introduced in a platform build around a year ago: When SAML is configured to authenticate against an external server(s), allow the user to optionally select to authenticate directly with Hornbill if the collaboration setting guest.anonymous.saml.[user|guest].allowhornbilllogin is set to true (these setting will be available in platform release 3135 or above)

The patch has now been deployed to all instances so this particular problem should no longer be occurring.

Our developers have completed work on a patch and this will be deployed to all instances shortly. I'll advise here when this has been done.

For anyone else who may be experiencing this problem. The patch in question will be deployed to all instances.