Jump to content

Victor

Administrators
  • Posts

    5,688
  • Joined

  • Last visited

  • Days Won

    168

Everything posted by Victor

  1. @yelyah.nodrog you can manage this behavior via these settings:
  2. @derekgreen yeah the original is bril!! ... but you need to see the series too, is amazingly written...acted as well... Hopkins in Dr. Ford's role...omg!! ... Looking at his speeches I'm like a teenager drooling for Justin Bieber...
  3. @derekgreen your words mean nothing to me! ... or to quote from one of my favourite series, Westworld, "What door?"
  4. @lee mcdermott if you men having a different "customer" on the request than the user which is logged in, then no... not currently possible...
  5. @derekgreen I assume you have SLA(s) with Service Levels and have defined rules to what Service Level to be associated to a request based on certain criteria... Is it possible that on the request missing the Service Level, the rules criteria did not find a positive match? This would explain why you have an SLA but no Service Level.... (I know that I am risking a life of a kitten by stating "I assume" but I am fairly confident it won't be the case )
  6. @Ralf Peters First of all I would really not advise to play around with SQL updates and inserts. I understand that you have knowledge in this area however, things can break so easily... I've seen tables wiped out, for example, by an incorrect statement or forgetting to add a correct filter and so on... But you are right, the user profile settings are stored in this table and a record is created once a user changes any of these settings...You could create a record for each user ID however I am unable to advise further. If something breaks or not working right we would be unable to assist you in fixing it. I hope you understand this and the reasons behind this... What I can advise is to at least try with one or two users then, after a thorough testing, do this for any other...
  7. @Steven Boardman you should know by now, Victor is always right
  8. @Joyce I was lying... It has nothing to do with percentage or count measures when using measures.. measures are built to show data using certain frequency - i.e. weekly, monthly, etc. (which is not something you actually need for this particular widget)... From what I understand you need a widget displaying active incidents... So, ignore the rubbish post I made previously... Did a bit more digging and played with widgets a bit and came up with this: This displays/counts only active incidents (status is new, open and on hold). The sample period is actually specified in the widget and in this example is set to pull all data from the start of calendar year (this can be changed as required). The widget is not using a measure, is actually using a custom SQL with multiple series added (a separate series for each priority)... You can also change the looks do display the series as stacked but I don't really like how it looks...
  9. @Ralf Peters there were a few changes around profile visibility but nothing recent (meaning nothing changes since last year)... The default visibility for profiles is "Followers". This is hard coded. If a user changes the visibility of a certain section then we have a record of this in the database... Therefore: won't matter since you can't change something is if not there (hope this makes sense). There is no easy way to bulk changes this, actually there is no way to change this by any other than the user changing them himself... I had a look and see if I can build a quick tool to call the set profile visibility API for a list of users but that won't work either...because the API takes the user information from the session variable, it is not passed as a parameter... there is a way to build a tool but is not quite simple... I can have a look and see if-how-when can be done... I'll also ask our dev team to see if they can expose the default visibility configuration in the admin UI so an admin can change the default values for these which are used when a user is created...
  10. @Joyce I think is easier to show you... Is it ok if I create a test measure and a test widget in your instance?
  11. @Joyce maybe you could have the measure to use "Percentage" as value aggregate rather than "Count" (it still does the count, but allows multiple counts... so to speak) So, try and amend your measure (one of them, since I assume you have two) to have "Percentage" as value aggregate. This type of aggregate also requires a value column. Set this to be the priority. Then, refresh one of the widgets and see what it gives you... it should give you now a breakdown for teams on each priority...
  12. @Ralf Peters depends how the coworkers set this information (contact details) in their profiles... if this section is not set to public then not everyone will see this... ( @Ehsan thanks for the tip )
  13. @Gary@ADL : as @alextumber suggested, you can view the full error by inspecting the logs in the admin tool (System -> Monitoring -> Log Files). You would need to look at ESPServerService.log file. Filter out to display errors so you can find it faster. However, many times the error will not tell you exactly what went wrong, unless you have some coding/development understanding. Without looking at this issue, I bet is an "Input parameter validation" error which does not tell you exactly why it didn't work...
  14. @Rohit Govind the fix (for this issue) is included in the next Service Manager update. However we have not yet deployed this update in live instances. It is scheduled for mid-end of this week (look for SM build > 956). The deployment is posted in the "Announcements" section of the forum as well.
  15. @Sonali Not really, what I was saying is that the "Assign to Request Creator" node needs to have a team. It's a mandatory parameter. EDIT: Actually, whilst I did not say this specifically in my above post, as per my last paragraph, you statement is correct A request can't have an owner without a team. The "Assign to Request Creator" node will assign a request to a team and an owner, the owner being the analyst that raised the request. So, the node knows the owner, what the node does not know is what team? This is why I said the node must get this info from somewhere, whether is set manually in the node or it can be passed by a previous "Get Request Details" node IF the request has a team assigned when the BP reaches this node. There is also a specific scenario where the request will not be assigned to the analyst that raises the request: If the analyst raising the request is not part of the team specified in the node or passed from a previous "Get Request Details" node (e.g. when the request was raised it was assigned a team of which the analyst is not a member of). In this case the request will be assigned to the team, without having an owner.
  16. @Sonali right, I think I found why you getting the error. The "Assign to Request Creator" node needs to have a team. The team can be either specified manually in the node or it can be passed by a previous "Get Request Details" node IF the request has a team assigned when the BP reaches this node. Suggestions: A. Have a decision node before to check if there is a team on the request. If there is no team on the request, have a "Assign to Request Creator" node with a team configured (set "Team" parameter to "Manual" and specify a team). If there is a team on the request you can have the "Assign to Request Creator" node with all parameters on "Auto". B. Amend the current "Assign to Request Creator" node to always have a team configured (set "Team" parameter to "Manual" and specify a team) for all scenarios (request having or not having a team).
  17. @DeadMeatGF I think @Sonali has one (Get Request Details)... the "Get info on whether incident is assigned..." ... it could be something else failing... need to have a look to get more info on this...
  18. @Tina.Lapere ye,s they will fix it... however the answer to the next question is "we don't know"...
  19. @cchalmers after further investigation, it turns out that is not what I assumed initially (the orphaned records)... this should teach me once more not to make assumptions as I make an a** out of myself What actually happened is that the user clicked on "It's Working" button, on a resolved request. When a user does this, the close request procedure initiates and part of this is to create a feedback timer (feedback timers are created for closed requests or when a request is being closed). Due to a defect, the close request procedure fails somewhere throughout (it fails silently, there is no error feedback displayed in the UI). Because it fails, the buttons are still displayed on the screen giving the false impression to the user that the button wasn't clicked or the click was not performed. So, the user clicks again...this is where the error you reported pops up... because before the close request process reaches the silent failing point it sets the feedback timer... which was already set when the close request was initiated first time... hope this makes sense The defect I mentioned above has been fixed and the fix is included in the next Service Manager update.
  20. @cchalmers did you run the Hornbill Cleaner tool some time ago (I mean not recently in the past couple of months)? I suspect the feedback record for this request was/is an orphaned record from a previous cleaner tool version... If this is the case (cleaner tool was run a awhile back) then I can have a look and identify these orphaned records and fix them
  21. @SJEaton indeed, the wiki is not very explicit when it comes to expression configuration for variable empty value. So, for example, to cater for empty values of {{.H_custom_a}}, your expression needs the be like this: '{{.H_custom_a}}' NOT LIKE '%{.H_custom_a}%' Technical explanation: This is because if the {{.H_custom_a}} variable does not have a value, it does not actually evaluates to empty or NILL, it evaluates to the variable name as string. Hope this make sense
  22. @samwoo map fields from ProCap questions to custom fields in request details which you can edit later?
  23. @samwoo it is very raw, is a tool we used ourselves for such scenarios and decided to make it available for everyone to use, after we gave it just a bit of polish... Therefore it doesn't know how to do complex stuff... it only knows to close requests if a list of such references is given... So, in your scenario, you would need to pull the references list from a report perhaps, put this list in the config file for the tool and run it...
  24. @DougA sorry about this. While we fixing the issue, we can run a bulk close if you send us a list of references which would need to be closed. We can also provide a (or the) program which you can run yourself to bulk closed a list of requests.
×
×
  • Create New...