Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "ticket tracking"
-
Admin work, because its all manual:
- Each new project has to fill out an Excel tab in a workbook, with a list of all the major tasks and who is responsible. This then needs to be used to create a Gantt chart, manually, in the same tab, showing in what month a task starts and ends.
- Every month we have to manually enter status updates into a powerpoint slide on a shared deck. Which has a collision at least once per month.
- Once a quarter we need to do something similar as the powerpoint slides, but into a word doc instead.
- Once a week we need to track our time on projects in a tool that can't be integrated with (no API or anything). Meaning we can't link up a ticket tracking system to it, so again, all manual.
- Once every 6 months a new round of research funding opens up and we write proposals. The status for which are tracked in another Excel spreadsheet, manually, once a week until the deadline.
- The instructions for what to do with the proposals are so vague and badly documented that there is an unwritten rule, that for the first time you will have to ask a bunch of questions to the project manager. This is accepted by everyone and its just the done thing.
- Everything is stored in a dropbox style system, which has become so cluttered I can only find resources by saving the links sent out previously.
- Some of these updates / reports also get a 1 hour meeting for everyone to stand up and read out what they've entered.
- From time to time random things will need to be reported on to the higher ups (how many publications, research papers, patents, times and dates etc.). Again rather than a tool, a new Excel spreadsheet is whipped up and emailed to everyone on the team. Whoever sent it out, then has to merge the 20+ copies into 1 doc.
- Some of the staff (mostly the devs), use a ticket tracking system to keep track of everything. Management refuse to use it to track the things they need. Instead we have to copy paste from it into the word docs, powerpoint, excel etc.
- By far the most annoying. Management force all the above as they need the info for finance, accounting, legal etc etc. So we have to do it, but whenever there is a question from legal, management send the question to us. So despite having documented every facet of everything imaginable, it all gets ignored in favour of endless emails.
I once tried to to put an end to all of this madness by proposing the use of a ticket tracking system, and then building reporting tools on top of it.
... I was told that it "wasn't appropriate". Still don't know what that means.9 -
I have been gone a while. Sorry. Workplace no longer allows phones on the lab and I work exclusively in the lab. Anyway here is a thing that pissed me off:
Systems Engineer (SE) 1 : 😐 So we have this file from the customer.
Me: 😑 Neat.
SE1: 😐 It passes on our system.
Me: 😑 *see prior*
Inner Me (IM): 🙄 is it taught in systems engineer school to talk one sentence at a time? It sounds exhausting.
SE1: but when we test it on your system, it fails. And we share the same algorithms.
Me: 😮 neat.
IM: 😮neat, 😥 wait what the fuck?
Me: 😎 I will totally look into that . . .
IM: 😨 . . . Thing that is absolutely not supposed to happen.
*Le me tracking down the thing and fixing it. Total work time 30 hours*
Me: 😃 So I found the problem and fixed it. All that needs to happen is for review board to approve the issue ticket.
SE1: 😀 cool. What was the problem?
Me: 😌 simple. See, if the user kicked off a rerun of the algorithm, we took your inputs, processed them, and put them in the algorithm. However, we erroneously subtracted 1 twice, where you only subtract 1 once.
SE1: 🙂 makes sense to me, since an erroneous minus 1 only effects 0.0001% of cases.
*le into review board*
Me: 😐 . . . so in conclusion this only happens in 0.0001% of cases. It has never affected a field test and if this user had followed the user training this would never have been revealed.
SE2: 🤨 So you're saying this has been in the software for how long?
Me: 😐 6 years. Literally the lifespan of this product.
SE2: 🤨 How do you know it's not fielded?
Me: 😐 It is fielded.
SE2: 🤨 how do you know that this problem hasn't been seen in the field?
Me: 😐 it hasn't been seen in 6 years?
IM: 😡 see literally all of the goddamn words I have said this entire fucking meeting!!!
SE2: 😐 I would like to see an analysis of this to see if it is getting sent to the final files.
Me: 🙄 it is if they rerun the algorithm from our product. It's a total rerun, output included. It's just never been a problem til this one super edge case that should have been thrown out anyway.
SE2: 🤨 I would still like to have SE3 run an analysis.
Me: 🙄 k.
IM: 😡 FUUUUUUUUUCK YOOOOOU
*SE3 run analysis*
SE3: 😐 getting the same results that Me is seeing.
Me: 😒 see? I do my due diligence.
SE2: 😐 Can you run that analysis on this file again that is somehow different, plus these 5 unrelated files?
SE3: 😎 sure. What's your program's account so I can bill it?
IM: 😍 did you ever knooooow that your my heeeerooooooo.
*SE3 runs analysis*
SE3: 😐 only the case that was broken is breaking.
SE2: 😐 Good.
IM: 🤬🤬🤬🤐 . . . 🤯WHY!?!?
Me: 😠 Why?
SE2: 😑 Because it confirms my thoughts. Me, I am inviting you to this algorithm meeting we have.
Me/IM: 😑/😡 what . . . the fuck?
*in algorithm meeting*
Me: 😑 *recaps all of the above* we subtract 1 one too many times from a number that spans from 10000 to -10000.
Software people/my boss/SE1/SE3: 🤔 makes sense.
SE2:🤨 I have slides that have an analysis of what Me just said. They will only take an hour to get through.
Me: 😑 that's cool but you need to give me your program's account number, because this has been fixed in our baseline for a week and at this point you're the only program that still cares. Actually I need the account to charge for the last couple times you interrupted me for some bullshit.
*we are let go.*
And this is how I spent 40+ useless hours against a program that is currently overrunning for no reason 🤣🤣🤣
Moral: never involve math guys in arithmetic situations. And if you ever feel like you're wasting your time, at least waste someone else's money.10 -
Root gets ignored.
I've been working on this monster ticket for a week and a half now (five days plus other tickets). It involves removing all foreign keys from mass assignment (create, update, save, ...), which breaks 1780 specs.
For those of you who don't know, this is part of how rails works. If you create a Page object, you specify the book_id of its parent Book so they're linked. (If you don't, they're orphans.) Example: `Page.create(text: params[:text], book_id: params[:book_id], ...)` or more simply: `Page.create(params)`
Obviously removing the ability to do this is problematic. The "solution" is to create the object without the book_id, save it, then set the book_id and save it again. Two roundtrips. bad.
I came up with a solution early last week that, while it doesn't resolve the security warnings, it does fix the actual security issue: whitelisting what params users are allowed to send, and validating them. (StrongParams + validation). I had a 1:1 with my boss today about this ticket, and I told him about that solution. He sort of hand-waved it away and said it wouldn't work because <lots of unrelated things>. huh.
He worked through a failed spec to see what the ticket was about, and eventually (20 minutes later) ran into the same issues Idid, and said "there's no way around this" (meaning what security wants won't actually help).
I remembered that Ruby has a `taint` state tracking, and realized I could use that to write a super elegant drop-in solution: some Rack middleware or a StrongParams monkeypatch to mark all foreign keys from user-input as tainted (so devs can validate and un-taint them), and also monkeypatch ACtiveRecord's create/save/update/etc. to raise an exception when seeing tainted data. I brought this up, and he searched for it. we discovered someone had already build this (not surprising), but also that Ruby2.7 deprecates the `taint` mechanism literally "because nobody uses it." joy. Boss also somehow thought I came up with it because I saw the other person's implementation, despite us searching for it because I brought it up? 🤨
Foregoing that, we looked up more possibilities, and he saw the whitelist+validation pattern quite a few more times, which he quickly dimissed as bad, and eventually decided that we "need to noodle on it for awhile" and come up with something else.
Shortly (seriously 3-5 minutes) after the call, he said that the StrongParams (whitelist) plus validation makes the most sense and is the approach we should use.
ffs.
I came up with that last week and he said no.
I brought it up multiple times during our call and he said it was bad or simply talked over me. He saw lots of examples in the wild and said it was bad. I came up with a better, more elegant solution, and he credited someone else. then he decided after the call that the StrongParams idea he came up with (?!) was better.
jfc i'm getting pissy again.9 -
how to become a true scum master:
- formulate jira tasks for your inferiors as vague as possible, best they don't make any sense
- before sprint start, ask the subhuman being to estimate storypoints, and if they say they can't really tell with this description and choose the highest estimate, say "okay, let's estimate it to one sprint length", so they can actually work on it within one sprint (which makes total sense)
- if the scum dares to question the content of the ticket and begs for more details, be like teflon and give no useful answer at all. if they continue asking for a meeting to discuss the ticket, tell them to have a meeting with a coworker about it (who also has no clue). don't be available for them because you have more important stuff to do.
- bully them during daily standups that they didn't create clear subtasks from this task and criticize them because you have no idea what they are doing. tell them they are having performance issues and suspect them to sit on their lazy asses all day.
- criticize the team in general for bad performance, bad item tracking and never say something nice, to make sure everybody loses even the last bit of intrinsic motivation for the project.
stay tuned to learn how to make yourself a skull throne out of those filthy dev smartasses ^.^6 -
My very first rant here was about the mess of ticket submission and ticket tracking applications we use, and about how we were moving to a single unified system some day.
Well, that day is today. And, predictably, it went horribly wrong.
So the way it's supposed to work is people login to the portal, search for what they want to request, then fill in details and submit. It creates a request ticket assigned to the appropriate team. (The old way involved a bunch of nonsense that you can see in my first rant).
The thing is, I found out about this today, when I got a company-wide email saying the new system was live as of this morning. None of us knew it would happen today. Not that I could've foreseen any issues just by getting the announcement early, but still, usually people find out about these things beforehand.
So, ecstatic to finally be rid of the old ticket tracking system, I log into the new system and look for our request form, which is, of course, not there. I check the old system and see that they combined every single "general request" into a single request where you pick which team the request goes to.
So I finally find the right request, pick the right department from the drop-down, and see that the request looks much better than it did on the old system. Out of curiosity, I look at the list of people who are part of that department.
I am not on the list.
My ENTIRE TEAM is not on the list.
Because they migrated the team data to the new system a year ago, when the issue tracking/reporting portion of it went live. My current team was hired approximately six months after that and apparently updating the team data in the new system isn't part of our Onboarding process yet.
So... Bright side is I guess I will have a lot of free time soon since nobody can submit new project work to my team?
tl;dr: they took a great software product and implemented it so poorly that our team can't use it.3 -
while true; do
echo "Drop everything this $LATEST_TICKET is your highest priority now!"
sleep(3600)
done1 -
My boss had a 50 page word document where he add any bugs he has found (he likes to test before it goes to QA) we then have to read that document for any changes (hi-lighted in blue) then add them to our bug tracking system. Any updates that are made on the ticket we have to add to the word document.
We tried letting him use our bug tracking tool but he hated using it as the padding on the navigation links was too big. We would have to redesign the 3rd party tool just for him4 -
Our ticket tracking system and our IT service request system are from two different companies that are direct competitors. The source code is full of temporary hacks to just make them play nice until a better solution is worked out. Fast forward a few years and we're abandoning both systems in favor of a single, unified system that handles everything. We currently have maybe 20% of the new, unified system done, which is now hacked together with both of the legacy systems until we finally transition fully to the new system. The current plan is for next year, but the plan six months ago was for this year, and almost no progress has been made since then, so we're probably going to have two ticket trackers and two request systems for a while.
Actually, three ticket trackers and three request systems. The third ticket tracker is used to track work done on tickets that exist in the legacy tracker because the legacy tracker can't do that on its own, while the third request system is the oldest and most cumbersome legacy system of them all.1 -
Oh boy I got a few. I could tell you stories about very stupid xss vectors like tracking IDs that get properly sanitized when they come through the url but as soon as you go to the next page and the backend returns them they are trusted and put into the Dom unsanitized or an error page for a wrong token / transaction id combo that accidentally set the same auth cookie as the valid combination but I guess the title "dumbest" would go to another one, if only for the management response to it.
Without being to precise let's just say our website contained a service to send a formally correct email or fax to your provider to cancel your mobile contract, nice thing really. You put in all your personal information and then you could hit a button to send your cancelation and get redirected to a page that also allows you to download a pdf with the sent cancelation (including all your personal data). That page was secured by a cancelation id and a (totally save) 16 characters long security token.
Now, a few months ago I tested a small change on the cancelation service and noticed a rather interesting detail : The same email always results in the same (totally save) security token...
So I tried again and sure, the token seemed to be generated from the email, well so much about "totally save". Of course this was a minor problem since our cancelation ids were strong uuids that would be incredibly hard to brute force, right? Well of course they weren't, they counted up. So at that point you could take an email, send a cancelation, get the token and just count down from your id until you hit a 200 and download the pdf with all that juicy user data, nice.
Well, of course now I raised a critical ticket and the issue was fixed as soon as possible, right?
Of course not. Well I raised the ticket, I made it critical and personally went to the ceo to make sure its prioritized. The next day I get an email from jira that the issue now was minor because "its in the code since 2017 and wasn't exploited".
Well, long story short, I argued a lot and in the end it came to the point where I, as QA, wrote a fix to create a proper token because management just "didn't see the need" to secure such a "hard to find problem". Well, before that I sent them a zip file containing 84 pdfs I scrapped in a night and the message that they can be happy I signed an NDA.2 -
So I was just informed I have 40 tickets with my name on them. No big deal normally except that I had no idea and was scheduling based on the fact that I knew I had 25 on my plate and most of them were OBE. How did I find this out you ask? Well rather than updating the tickets in our ticket tracking system, my PM updated a spreadsheet that is out in no man's land. So it looks like I have been doing no work for the last 3 months when in reality I have been busting my ass to get shut done and fixed. Why even have a ticket tracking system?
-
Sometimes getting tickets from the clients feels like a Sherlock Holmes adventure. Figuring out what the hell they meant, tracking down resources that should be included in the ticket, so much fun. I need to buy a pipe and a spyglass.6
-
I haven't felt an urge to post on here in a while just because things have been going so well. But this month, is just not that kind of month anymore.
I'm upset. I'm upset by how I've been uprooted from my routine. I know I shouldn't be that bothered by it and things always change. But what the fuck is this company thinking to be using it's own fucking home baked ticketing system!
WHAT THE EVER LIVING FUCK IS THIS SHIT!
Let's go over the issues it has
1. I can't fucking email my clients through it
2. all emails are not recognized automatically. In other words each new email creates a new ticket if it does not have the tracking number attached to it.
3. I have to fucking hunt around in my inbox that is now bombarded by every email that is created for this ticketing system. Slap on a fucking tracking number. And then HOPE TO FUCKING GOD that the person on the other end doesn't erase the subject and cause the system to create a new ticket just for it.
Let's go over Zendesk which they've decided to decomission.
1. I. DON'T. HAVE. TO. DO. ANY. OF. THAT. FUCKING. SHIT.
2. That's it. It's fucking simple
Seriously. They forced me off of my original platform because this company already had a "ticketing system", if you can even fucking call it that, working.
And just if you weren't aware, all of this change happened because my company got bought out. It got bought out by this behemoth company that isn't willing to let me continue using a system; that has been very efficient, mind you, and instead make me use their system.
I. FUCKING. HATE. THIS.
Every fucking day! I have to do this stupid bullshit of emailing clients from my personal work email instead of on the direct ticketing system.
When I first started using this thing I actually thought I could use it to email the clients. For a solid two weeks I was "communicating" to clients through their ticketing system. Only to find out that the entire time those clients were not getting my actual fucking email! WHAT THE ACTUAL FUCK?
Then these guys tell me after the fact. "Oh that's strange... We never noticed that you can't send emails through it... We always just had used our work emails."
Are you fucking jerking my chain! You guys have literally been sitting in this slimy pit of hell for so long that you don't even know there are better options out there!
You don't have to fucking live this life!!
I don't think I'm going to make it. Something needs to change. And I know upper management isn't going to do it, because I fought hard to try and keep Zendesk. They are not keeping it. After this next quarter it is officially gone.
I'm trying to think of coding solutions to make my situation better... But I shouldn't have to fucking do that! There are perfectly good working solutions out there, and this company doesn't want to budge because "that's the way we've always been doing it"
I'm going to fucking rip out my hair. -
Do you think tracking work hours by ticket makes sense?
I think it's a waste of dev time. Not sure from PM pov.6 -
Docuware, oh Docuware.
Meant to be an archiving system, but the moment work flows were seen by our director the ball just went out of the court in terms of implementation.
We've gotten to a point where we don't want to use Asana for ticket tracking and task assignment, we don't want to use a tool that acts as a man in the middle to push information to dbs, we want to use workflows with set conditions to automate every single process in the company. Why? It's cheaper.
The syntax is alrightish for arithmetic expressions, but there are so many limitations that we've gotten to the point where we're absolutely circumventing the entire point of the software.
Initialise variables, Condition, condition, condition, draw data from external sheet, process based thereof.
"oh, why doesn't it display images on the populated forms? I don't want it just as an attachment I need to click next to see".
Frustration is paramount, but the light is at the end of the tunnel.
"Oh, did I mention that we need digital signitures?" you need an additional module Mr boss. "no, I bought the cloud bundle. Make it work".
Powerful tool, I'll give it that, but it's downfall is its lack of being comprehensive.
Month 3, here we go.4