I am about to configure and set up ats and ars for the first time. I have a new component I sm excited to be offering the opensource world and your site (how you run it) seems ideal. However we are using cloudforge.com for scm hosting and we want use it's embedded bugzilla or jira for issue tracking. My goal was to create a form in joomla to post issues the user submitted and then use a webhook for the replies into some sort of private email thing or a forum. But then I realized that I have a pro account and I already have access to ars and ats! The issue is I want my git commits and nice comments to be associated with the issues. So I was thinking how would I go about using ats for costomer facing issue reporting, sales support and so forth but when something requires coding or a new feature I would associate the ticket in ats with a bugzilla request and thus my agile process remains in focus. Ideally as work is done outside the ats system I could post messages back to the ticket holder from the backoffice geeks giving a sort of status update. I might insert a human being in this process - sort of an account manager to sanitize the output of the developer sbefore updating thre ats system. So I am I describing a new plugin oppoertunity for myself - a sort of acount-manager dashboard with backoffice project managemet support from products like assembla.com, cloudforge.com and others? Or can ats do this with acl and some sort of scm plugin? In other words customers create tickets but my account manager creates tickets in the git-aware backoffice project manager
#20152 integration
Posted in ‘Akeeba Ticket System for Joomla! 4 & 5’
This is a public ticket
Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Environment Information
Joomla! version
n/a
PHP version
n/a
Akeeba Ticket System version
n/a
Latest post by nicholas on Wednesday, 28 May 2014 00:59 CDT
Tuesday, 27 May 2014 13:37 CDT
user20522
Tuesday, 27 May 2014 16:40 CDT
nicholas
Akeeba Staff
Manager
I have completely lost the plot reading your request.
Do you want to automatically create Bugzilla issues when someone posts an ATS ticket? This is a bad idea because you'd be transmitting private tickets on a most likely public place (tracker) which is an obvious privacy and security concern.
Moreover, your issue tracker is there to help you deal with coding issues, not deal with support. God forbid if we'd open a new GitHub issue for every ticket we are receiving here! As you can see from our changelog the number of code issues per month is in the range of 2-3 whereas the number of support request is two orders of magnitude higher. If you flood your issue tracker with support requests you'll end with a situation like Joomla!'s own issue tracker: nobody will bother (or be able to bother) with anything filed more than 10 days ago. This leads to bugs being overlooked to the point that you come to your clients as incompetent. Not a happy place to be.
Having used a ticket system and a code issue tracker for several years my advice is to use a human as the gateway between your ticket system and your issue tracker. More specifically, a developer, not just any random bloke. Someone who can understand if the issue in question is a coding issue, a user error on an FAQ item (for example, something depending on server environment you can't work around in code). When an actionable issue is identified create an issue in your issue tracker and put a link to the ticket. This management method works and it scales really well.
Do you want to automatically create Bugzilla issues when someone posts an ATS ticket? This is a bad idea because you'd be transmitting private tickets on a most likely public place (tracker) which is an obvious privacy and security concern.
Moreover, your issue tracker is there to help you deal with coding issues, not deal with support. God forbid if we'd open a new GitHub issue for every ticket we are receiving here! As you can see from our changelog the number of code issues per month is in the range of 2-3 whereas the number of support request is two orders of magnitude higher. If you flood your issue tracker with support requests you'll end with a situation like Joomla!'s own issue tracker: nobody will bother (or be able to bother) with anything filed more than 10 days ago. This leads to bugs being overlooked to the point that you come to your clients as incompetent. Not a happy place to be.
Having used a ticket system and a code issue tracker for several years my advice is to use a human as the gateway between your ticket system and your issue tracker. More specifically, a developer, not just any random bloke. Someone who can understand if the issue in question is a coding issue, a user error on an FAQ item (for example, something depending on server environment you can't work around in code). When an actionable issue is identified create an issue in your issue tracker and put a link to the ticket. This management method works and it scales really well.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
Tuesday, 27 May 2014 16:48 CDT
user20522
No you followed it perfectly that was exactly my question and you answered it well. I agree that a human will and should be inserted between the two worlds. I was thinking more of a way to take a group of issues from various sources and linking them to a single request on of the developers. This way the source commits will reference the issue the account manager (bug creator) with the original causalities (issues reported by users. As I write it and speak it aloud I can see a simple component.......thanks!
Wednesday, 28 May 2014 00:59 CDT
nicholas
Akeeba Staff
Manager
I can tell you the simple way we solved this problem, from commit to ticket by means of the issue tracker. Each commit fixing a bug references the issue closed in the issue tracker, e.g. "Close gh-123 Some foo was happening when bar was expected". The issue in the bug tracker (#123) will have a descriptive title and inside its description we put a link to our ticket system, e.g. "**More info**: [ticket #20152(https://www.akeebabackup.com/support/20152)]"
Going the other way around is a bit more complicated. As soon as we provide a bug fix we publish a dev release and send a reply to the client to try it. If someone asks me when the bug in ticket XYZ was fixed I pull up the ticket, check when the dev release was published and then I can check commits closing issues which were made on that day. If there was no issue filed but a fix was made nevertheless there is also a commit. Frankly, going this way (find commit/issue based on ticket number) is extremely rare.
Going the other way around is a bit more complicated. As soon as we provide a bug fix we publish a dev release and send a reply to the client to try it. If someone asks me when the bug in ticket XYZ was fixed I pull up the ticket, check when the dev release was published and then I can check commits closing issues which were made on that day. If there was no issue filed but a fix was made nevertheless there is also a commit. Frankly, going this way (find commit/issue based on ticket number) is extremely rare.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!