Victor
-
Posts
5,696 -
Joined
-
Last visited
-
Days Won
169
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by Victor
-
-
@Michael Sharp the error occurs because the task expects a value for all time options (i.e. year, month, etc.). For your BP, if you like to request to be put on hold for 2 hours, then I suggest to set the time as 0 years, 0 months, 0 days, 2 hours, 0 minutes. I can see this configuration not being obvious (also not really needed to specify a zero time), so I will ask developers to look into this functionality.
-
I would also expect the path to include the current selected service when logging a request
Our developers are now looking into this. I will also log an incident on your behalf in regards to this issue.
-
@Martyn Houghton IDOX Group I completely misread your post
.. I'll have to think again then ...
-
-
@nasimg I'll make a not that you experience this as well.
-
PATCH 2.29.5
This patch addresses an issue whereby the request list failed to load and eventually crashes the browser. This does not affect all instances as it occurs in a specific circumstance and also occurs only when using Chrome browser. If you are affected by this issue please update to this patch to have this fixed.
-
Currently being fixed... We have incidents logged for this issue so we will send you an update as soon as we have more information.
-
@Martyn Houghton IDOX Group this has been recently highlighted internally and is currently being investigated...
-
@gregmarcroftorc I'll log an incident for this, to investigate this further
EDIT: incident raised, you should have received an email with confirmation.
-
5 minutes ago, gregmarcroftorc said:
I logged a test ticket and I noticed that once you have re-opened the ticket, when you go to "close" it again by selecting the tick icon and clicking the Close button, this only seems to do half the job, e.g it only sets it to resolve as you mentioned. We then need to click on close again to actually turn it from resolved to closed.
Indeed, because there is no BP any more on these ones to perform the actual closure, the BP concluded/ended first time it was resolved/closed.
6 minutes ago, gregmarcroftorc said:Funnily enough this seems to conflict with ticket 479 where you mentioned that clicking close twice actually reverts the action.
Well, kind of, as I said is a bit of interesting one... basically the BP does something (i.e. setting the status to close) but this is not picked up by the request interface, unless the request is refreshed so the UI reads the current/new request values, it won't do it automatically as it is not designed as such...
So from the request perspective (exclusively) it is not reverting a closed ticket... One of the things "resolve" action does is to set the request status to resolved...now, you can have something else (like the BP) which can set a closed status so in the end it will look like it reverts... but in fact "resolve" is acting as designed - to set the status to resolved...
I will suggest our developers to make change in the resolve action to check for the request status prior to changing it to resolved... so if the request status is currently set to close, then the resolve action will prompt a warning or info to the user saying that it could not perform the resolve action as the current status is set to closed...
-
@gregmarcroftorc apologies, #spell fail
BOP = BP = Business Process
488 has a service, but is not the service that manage the timers, is the business process... could be any number of reasons why the BP was not associated:
- service does not have a BP associated;
- if the above is correct then Service Manager will use the default process for the request configured on application settings but there is no process configured there;
- the process configured for the request or as default in application setting is not active. This could happen if someone is making changes to the request and saves the process without activating it. Saving the process will deactivate it by default so it needs to be activate either after s saved or by selecting the Activate option in BP editor (which will also save any changes made).
-
@gregmarcroftorc had a quick look at the examples you mentioned:
IN00000525, IN00000858, IN00000838, IN00000813 - reopened - so they would fall under the first scenario (reopened scenario that I described above).
IN00000561 - missing BP - would fall under the second scenario (missing BP scenario that I described above).
IN00000479 - now this is an interesting one!
This one actually followed the process, as intended and it would have been closed as any other "regular" ticket but... looking at the timeline I believe the following scenario occurred:
- call logged at 04/07 at 16:28 and progressed normally
- call resolved by analyst (like any other call) on 11/07 at 14:32:37 (second are important, you'll see why below)
The BP did its thing as you can see at 14:32:38 set the status to Closed and at 14:32:39 sent the resolution email to customer. The timeline updates and the quick sequence shows that it could only have been the BP that set the status and sent the resolution email.
The important part happened now. The analyst, Peter, still had the request open with action focus on resolution box. Because the request had not been refreshed (not to any fault from Peter by the way), the "Close" button was still "active" as resolve! Hope this part makes sense The UI did not know that the BP actually set the status to closed.... So when Peter clicked the "Close" button again, it changed the request status to resolved... as it usually does when the resolve action is performed. So basically it reverted the closing action that the BP just did!
Now I imagine you woudl want to avoid this scenario in the future so I'll have a look and see what can be done, I'll get back to you on this... Meanwhile, may I suggest to let your analysts know that is sufficient to perform the "Close" action only once as the BP will do the rest (i.e. close the ticket) regardless of the UI status...
-
When 488 was logged it did not associate the BP.... most of the time I see this is because the service is not selected during progressive capture or the service doer not have a BOP associated... 704 does have this.
Now, the BP is the one that caters for response and resolve timers. Because 488 does not have the BP the response/resolve was never started and stopped so the "SLA met" information would have never been stored... hence the missing info in the field.
-
@gregmarcroftorc I think I understand now why you have the "Resolve" button/action translated to "Close"... I am not familiar with the initial set up, but it kind of makes sense when I assume you had this translation as your BP will automatically close the ticket once it has been resolved. Therefore it would have been more meaningful for the analysts to see "Close" instead of "Resolve"...
This being said, I don't really see why some of the tickets woudl have remained in a resolved state... unless... one scenario I can think of is perhaps the ticket was reopened... in this case, because the BP finished when it was originally resolved, when it was reopened and resolved the second time it would have stayed in the resolved state - the BP would have not been there to close it automatically. So unless the analyst would have closed it manually (unlikely since your analysts are not used to it since usually is enough for them to resolve it - translated to close) ... another scenario woudl have been if for some reason the BP failed to go past the "Await Resolution" node even if a resolution exists on the ticket... this would be a defect in my view...
Sorry for the long and convoluted post, hope it makes sense
I can have a look in your instance and see if I can find out why the 10 tickets remained in the resolved state and I would need some call references to investigate this...
EDIT: following you post regarding missing rows for "SLA met/not met" report, another scenario for this issue might be that the 10 tickets do not have the BP associated. Following my above reasoning, the BP would have not been there to close the ticket so they would have remained in a resolved state....
-
@ljbrown our developers recently improved the Clean Utility tool to allow clearing down requests based on request class/type. Sill waiting to be released, they should follow up with more details soon
-
@Graham1989 we will log an incident for you and have a look at this behavior.
The workaround I was referring to is remove "request category" and "resolution category" configuration for the services. Temporarily. Then you (your analysts) should be able to select the categories but you will see the whole tree structure (i.e. Incident and Change categories) but at least you will be able to select one for the moment...
-
Something that surfaced after 2.29... is related to the way the category is saved on request, whereby it will not retain all the structure... Is currently being fixed by dev.
Had a quick look on you service configuration and it appears I can't see the same message displayed for resolution categories. Have you changed this?
-
@Graham1989 if you have a category level configured on service, for that request type, then you will experience this issue. This is something we recently found and was also reported by our customers ( @gwynne FYI). This is currently being investigated.
As a temporary workaround I would advise to remove the category level definition in service configuration. No the most elegant solution as it will require analysts to go thorough the entire category tree to select the correct category but I hope it won't be too much of an inconvenient until we have a permanent fix.
EDIT: just saw your reply now, this might be something different (for resolution category) . Above advise still applies fro "Request Category" where I can see you have "Incident" configured. I'll have a quick look to see about the resolution and get back to you shortly.
-
@Michael Sharp we have release a patch (Service Manager 2.29.4) to address the issue you experienced. We fixed your instance earlier on so this is not necessarily urgent, it can be done when you have a chance.
-
PATCH 2.29.4
This patch addresses an issue where analysts were unable to log, update or resolve/close requests if the analysts only have Incident Management User and/or Service Request User roles assigned.
If your service desk analysts are configured to only use these roles for request management please update to this release.
-
1
-
-
@Michael Sharp as discussed earlier, this should now be fixed in your instance. This occurred because the roles used by your analysts (Incident Management User and Service Request User did not have rights to a new table introduced by Service Manager release 2.29).
-
@ojenkins you can click/select on the email on top then scroll down to the bottom of the page or keep scrolling to the last email you would need to select. Then on this one SHIFT+click to select and it will select all emails between the first one selected and the second one selected. Hope this makes sense
-
Dear all
This morning we released our new version of Service Manager 2.29. This is now available for you to update in Hornbill app store. Below is a list of changes and fixes introduced by this version:
NEW: Comments can be added to an existing workspace post through the Business Process Manager
NEW: You can now specify the owner of a service
CHANGE: Clickable links to posts and requests when the business process engine posts to a workspace
CHANGE: You can create Views for requests that have a status of Cancelled
CHANGE: Improved how attachments are processed when applying emails to requests. If the same file name is detected, the email ID and 5 characters are appended to the end as a guid. Only the first 50 are processed for performance, but this can be increased by changing the application setting servicemanager.email.maxAttachmentsToProcess
CHANGE: You can now branch on catalog name in Progressive Capture
FIX: There are now more checks to make sure that the correct request type is being raised via portals
FIX: The resolve tab wasn't visible in some cases when looking at a request in the portals
FIX: Users teams and supporting teams are considered when selecting closedByTeam, resolvedByTeam and reopenedByTeam
FIX: The priority and team columns were missing in the export list
FIX: Resolved an issue with incorrect results presented on charts drilldown
FIX: Cannot unset drop down custom fields
FIX: Changes to lists on board page not reflected when editing board details
FIX: Unable to see updated resolution details in request timeline
FIX: Showing database value instead of priority name when editing existing views
FIX: Categories could not be unselected for services and the category form in Progressive Capture form was always showing an error
FIX: Resolved an issue where resolved, closed, canceled published requests would still appear in portal search results
FIX: Setting the initial priority to an existing request was not updating the timeline
FIX: When looking at the expanded details of a service, the arrow was not positioned correctly
FIX: Supporting Teams and Service Subscribers are now ordered alphabetically in the Service Details
FIX: The Favourites tab on portals home page would grow slightly when you hovered over it
FIX: Removed persistent validation error in the Schedule action
FIX: If a message was too long for the autoresponder to deal with, it would not apply the update at all. Now truncating content so that it fits, link to the original email can be found under the 'More Actions' menu
FIX: When printing a request, all of the sections are consistently formatted
FIX: Showing friendly icons for all post types in the timeline of a request
FIX: More information is given to users when there's a inactive or deleted Progressive Capture associated with a Catalog item. The Catalog item is hidden in the portals if this is the case
FIX: Favourites button in Portals is now disabled temporarily when adding / removing
FIX: When clicking on the email address of the customer raised by of a request, it will now check whether to use the built in email client or not
FIX: In some cases, the Business Process Manager could not progress on resolution of a request
FIX: When using the portals search, the list of FAQs wouldn't scroll to the correct one
FIX: Escalation action details not correctly displayed in service levels summary
FIX: Action buttons removed after copying custom filter with charts
FIX: It was sometimes not possible to export the request list for certain date time columns
FIX: If you had a service and a team in a views condition, it would only take the service into account
FIX: Recipient was shown as undefined in some cases when trying to send email notifications to teams
FIX: Business Process Manager broken for calls logged via Guest Accounts
FIX: Removed ability to sort by department in Request List as it is not possible to do so
FIX: Increased updated team ID column to 255 characters to handle longer team IDs
FIX: Better appication handling if profileCodeGetList has no results in Service details > Request Configuration tab.
FIX: Added an exception handler to handle a situation where a user does not have any groups (such as a system user like SYS:AUTORESPONDER)
FIX: Name of board in boards list not updated after editing board name
FIX: Improved the layout of the Portals Service view for mobile
FIX: When the auto responder failed to find a match it did not always end gracefully
FIX: Views were not always respecting the request types you have access to
FIX: The wrong site is shown after a request has been logged, but editing reveals the correct one
FIX: Questions are not being shown if you only have one question in a form
FIX: If you specified the same condition more than once, it was not able to filter the request list correctly
FIX: Response time list not refreshed when deleting the last entry
FIX: Through selecting a Catalog in the Portals, Progressive Capture does not branch based on Service ID
FIX: In some cases, the request type could not be selected
FIX: The request list is not ordered properly by "Reopened"
FIX: Connections customer selector is partially displayed in Internet Explorer
FIX: On hold times are now shown in your local time format
FIX: Improved how custom filters work when a user has no teams
FIX: Profile selector shows a "no categories" message instead of being hidden when no categories are defined
FIX: The site selection was not always updated if you changed it during Progressive Capture
FIX: Timers now allow you to use any calenader as your default in Service Manager
FIX: Resolved an issue with incorrect results presented on charts drilldown when services were used in the Views builder
FIX: Counters against services in the portals were not round in Firefox
FIX: Customer questions do not show for service requests in the Customer Portal
FIX: Resolve tooltip now says "Close" when a request has been resolved
FIX: Buttons in the On-Hold popup were different sizes to each other
FIX: Different sized images were shown for customers depending on if they had or didn't have a profile image
FIX: Contacts Organisation / Company is presented when applying an email to a request making it easier to distinguish between contacts with the same names
FIX: Views now handle the Services and Teams you support, including requests with no Service or Team, when they are not defined in the view filter
FIX: The Request list was too wide in the portals
FIX: Requests tab against a service not shown in the portals if there are only closed requests
FIX: Resolved issue when uploading restricted files during log request
FIX: Improved code handling when the emails list is displayed
FIX: When updating the app, if you've deleted the default asset types they will no longer be added back
FIX: The ability to share a snippet with a team is not working-
2
-
-
I did try this the other day and it did not work... I remember they (development) said something was broken in a flowcode... They must have fixed it and they did not tell me
EDIT: @Michael Sharp can you follow the steps outlined by Tina and see if it works?
Our developers are now looking into this. I will also log an incident on your behalf in regards to this issue.
.. I'll have to think again then ...
Issue with Workflow "On-Hold" Automation
in Service Manager
Posted
Also, if you like the timeline update to show this action I would suggest setting/changing "Update Timeline" from "Auto" to "Manual -> Yes".