Berto2002

It's a nice new look BUT it's too narrow (it's even narrower than the previous UI!). It's so narrow, not all the Action buttons fit without scrolling to a new line. Most people have landscape screens so the Request view really should be resizable by now and certainly not scrunched up into the middle like it is. Should be default scaling wo browser window width or, if fixed, then at least 50% wider than this but scale narrower if people have lower resolution. You're just making people have to scroll up and down SOOOOO much because content gets wrapped so much. At this width, our tickets are 5 screens deep. So I give 9 points for a nice look but only 2 points for missing the chance for keeping with the times and convenience from me The Hornbill forum has it right: with a wide browser window I see wide content: and with a narrow browser window, I see narrow content:

We've been asked to provide a report on what devices (assets) a given user had in the past. This is information held as a history item in some assets but it's finding those assets that's hard. Firstly, can we find this information through the UI? I.e. we can see user X had laptop1 then laptop2? Or if not, what tables and joins would I need to drill into the asset history to draw-up the asset names/IDs where the Used By was previously User X? Thanks for any pointers.

+1 Would greatly speed up finding these things. MUST launch in new window/tab! A bit like the one we've asked for for ages; direct link to the Request from the Failed Workflow window And my suggestion of the "intelligent link" to easily move from the 'customer' to the 'analyst' view of any given Request.

You will also have the issue that there may be multiple linked Requests so a call to "get linked request ID" may return multiple answers; and each could be of a different type so will not all contain the same fields. I can think of one way you can get around this but only if your starting Request 'spawns' the other Requests: use the "create new request" node in Request1 store the resulting request ID (Request2) in a custom field on Request1 then you can reference that Request2 ID specifically and do a "get details" on it later from within Request1 You can repeat the above as many times as you have custom fields to store the individual Request numbers for spawned requests You will not be able to read the timeline of Request2 from Request1 but the Request2 workflow could store whatever values Request1 needs into a custom field on Request2 which could be discovered by the "get details" query in Request1. Just an idea...

+1 for these. Both sensible. I particularly like the calendar suggestion because that will also apply for changes and all other planning in the system. The calendar should, be default, show the current day as the selected and the coming 31 days, regardless of month.

@SJEaton, @LawesD I logged this as an Incident on 09/08/23 with Premier Support. I suspect it was introduced by SYS_SYSTEM On 02-08-2023 06:32 (Release Date: (Build: 2910) I gather it's in the SM release that was delayed last week; Customer Success said it should be this week so I'm hopeful.

+1 Request this relatively simple enhancement to 2048 chars would be enough for us please. The issue is that when a user requests something, we include the variable for the description so the External Authoriser can see what is being requested. Sometimes that is a large amount of text and it overflows. We have worked around it by asking our users to "click here" to view the ticket but that's giving them more work to do which is kinda grating when we're trying to reduce clicks etc.

So "Portal Visibility" does not just refer to the service, it refers to the Tickets under that Service also. This is not intuitive because it's a config for the service and should not affect the existing tickets. I will now try to retire a service and see where that leaves us.

I will resume on the other topic

I have been undertaking a piece of surgery on my service portfolio by splitting out one service portfolio item into three. Following that, I wanted to hide the original service from the portal so customers would no longer log tickets under it. However, the moment I did that, customers lost visibility of all the tickets that have been logged under that service. I therefore had to re-enable the portal visibility but disable the configuration for each of the Request types and put a "sorry, don't use this service" text in the Description. This is not a very agreeable solution and I don't think the product should be working like this. It means my customers will continue to see the old service... forever? Even if all the currently open tickets are fully resolved and closed year, some users like to go back and look at their tickets so I will need to leave this service visible in the portal indefinitely to allow that? I request an enhancement that removing the visibility of a service from the portal does not mask all existing tickets from customers; the tickets are logged, in progress, why should a 'portal' visibility mask them? Secondly, I can see there may be a workaround in removing users from the Subscribers list so the "visibility" has no effect (we might just leave the admins or testing team in there for example); can anyone tell me if that also masks all existing tickets from their Customer?

It was on a test workflow and I needed to cancel it. I am due another test and will see if it happens again and is repeatable. I gather there are a number of issues with timers and SLA at the moment so maybe it's another one of those.

Anyone else seen this? Xmlmc method invocation failed for BPM invocation node '08c4c556-a207-8cac-2e59-65f2cb9e154a/flowcode-758d0e5a': <methodCallResult status="fail"> <state> <code>0207</code> <service>apps</service> <operation>updateReqStatus</operation> <error>/apps/com.hornbill.servicemanager/entities/Requests/fc_modules/requests_timers_helper.js(430): error X1001: Uncaught TypeError: Cannot read property &apos;elapsedWorkingTime&apos; of undefined</error> <flowcodeError> <where>Execute</where> <filename>/apps/com.hornbill.servicemanager/entities/Requests/fc_modules/requests_timers_helper.js</filename> <lineNumber>430</lineNumber> <columnPos>25</columnPos> <message>Uncaught TypeError: Cannot read property &apos;elapsedWorkingTime&apos; of undefined</message> <errorCode>1001</errorCode> </flowcodeError> </state> </methodCallResult> It's just a regular update status node:

@Andrew Parsons you could do this in the BPM. If, for these types of tickets you create and assign Human Tasks that sit and wait for an action, you can have them expire after an interval. That expiry then gets picked-up by a decision node and takes the action to move the card to the "unattended" lane while also posting a new Human Task which could be either worded more strongly or assigned to an escalation point. After that escalation task is done (e.g. manager declares they have instructed action), the BPM can cycle back to the original task for the analyst again and move the card back to the 'in progress' lane. Thus you will always know when that expiry has been reached and can get involved.

This is now also affecting us; first time I've seen this is today, 5th September. We had 3 Requests today with this issue. Worryingly, that's 100% of the Requests that have the "Update Service Level" node... Restart on the last step does progress. @Fizza

Our Premier Support ticket remains open with HB support.

I will give that a go. That gives me some hope!

Reported to Premier Support because we found the Impact value was not actually being stored so caused BPM issues further along.

Something has altered/gone wrong here for impact RE assessments. Normally, when we do an Impact Assessment or re-assessment, we get a box in the top right that gives a preliminary assessment as we go through the 5 questions. We'd expect it to start at Low and progress to Medium, High and Major if the totals tot-up. This did not appear today when I did a re-assessment. Then, in the timeline, the entry is missing the outcome: I note that the value is populated in the Impact field of the Information box: On the same CR, the original impact assessment was working as expected so this is a re-assessment issue.

I have found a 5th different help text for node "SM>Entity>Requests>Authorisation Decision>Approved" which states: "This option determines the visibility of the post to the Request. When not supplied, the setting "guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.update" is used to determine the visibility." This is in line with A1 above.

There is a lack of clarity / documentation about how Visibility works. Could I please ask HB to update Wiki or this forum to make it clearer? A. The pop-up Visibility help seems to have FOUR contradictory entries (that I have found), each giving different advice: default is customer or team or application option or not defined! SM>Entity>Requests>Update Request>Request Category. Visibility help: "The request timeline post visibility. If not specified, the application option value will be used" [BTW, great, this is what I expect]. This approach is supported by various "Visibility" entries on this Wiki age: Service Manager Business Process Workflow - Hornbill. SM>Entity>Requests>Update Request>Service: " This parameter determines the visibility of the post to the Request." (no mention of default) SM>Entity>Requests>Update Request>Custom Fields. Visibility help: "This option determines the visibility that will be applied to the update in the Request's Timeline. If not specified, 'Team' visibility will be used" (in direct contradiction to 1 above) SM>Entity>Requests>Update Request>Timeline: Visibility help: "The timeline visibility that will be applied to the request update post. If no value is specified, the visibility will be set to customer (trustedGuest)" (in direct contradiction to 1 above). I believe I have found examples of this where I set the app setting to "Public" but the node to "Ignore" and the default for Update Timeline was "Customer" (see F below) The above gives great concern that Visibility is either inaccurately documented or, worse, actually coded to have different behaviours per node which is an admins nightmare. B. Some nodes have this field as "Visibility", others as "Timeline Visibility" but it's not clear what the difference is. C. I have seen that my customers do see "Public" posts so it is not clear the difference between Public and Customer. All my IT analysts can already see posts set to Customer so what is the benefit of "Public"? I think this is partially answered here by Victor but it would be good it have it confirmed: D. It is also not clear what the setting should be for when I want "all my Full Users to see it and no-one else". Is that "team" (as in all Full Users, Co-workers) or "team" as in assignment teams (service desk, infrastructure, etc). If so, does that mean there is no setting where I can say "all my Full Users to see it" and no-one else"? Here in relation to (Buzz - Hornbill) it mentions "Public" as "All Co-workers) but not sure if that's related to Requests (but does set a precedent for what "Public" is). E. It is not clear, when the guidance says, "If not specified..." whether that applies to both "ignore" and "auto" settings. F. I have a support ticket open specifically about when I set default in the app settings for Request Updates to be "Public", they default to "Customer" in the UI. but that many be because the node is configured to not use the app setting but default to Customer as per A4 above. G. Doing a search on "Visibility" on Wiki produces no results so I've been struggling to understand this feature. I know there will be something there but I suspect it is behind a "Read More" filter which means it's not found on searches unless expanded... If a Wiki article can be please created or updated with this information I think we'll all be better off. Please help get this all bottomed-out. For reference, the application settings/options I believe should be used in the absence of a spec (ignore or auto) are: guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.schedule guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.linkDocument guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.link guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.hold guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.authorisers guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.assign guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.assets guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.escalate guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.update

@Victor. I had a ticket with Support recently and I am sure @Deen advised that Public was all the Co-workers. Since all co-workers can automatically all updates with visibility of Customer, it makes no sense for Public to do exactly the same? Please clan you clarify whether customers see Public updates and if so why/how they are different from Customer updates. Thanks

I have a Human Task that is hardcoded to assign to a Role but I want to determine the assignment according to an earlier decision in the BPM such as: If the Request is for the infrastructure team I want the Human Task assigned to Team - infra Else I want it assigned to Role - app support as per below screenshot because apps have multiple teams but share a role Question: am I right thinking that the Variable option can only contain a UserID (i.e. a single person) and not a Role or Team or Group? Implied by BPM Human Tasks - Hornbill In which case I would read the options as: Assign to Role Assign to Group Assign to User Assign to User Variable i.e. there is no way to make the assignment by ROLE, TEAM or GROUP variable?

@Nanette has this been resolved in the background now? We had a couple of requests yesterday that did alter the customer. The defect never showed-up on the list in your portal so I cannot track it. Or is this only happening under certain circumstances?

@Gareth Cantrell (edited). Found it: Authorisation Action Item - Hornbill

I get it. Sorry yes I did see something about that. Looking forward to that one.