Forum OpenACS Q&A: A Customer's Self-Service Interface to Bug Tracker!?!
This is to announce that we have plans to implement a customer's interface to the bug-tracker module. Here is the reasoning:
Bug-tracker (as the one used at http://www.openacs.org/) is a nice and mature tools that is very useful for an open-source developer community. It allows all members of a "bug-tracker" group to see all bugs and to post new bugs.
However, the requirements are different if you are an IT or advertizing company and if you want to allow your customers to post the bugs for their projects. The customer shouldn't become aware about the presence of other customers, and you want to invoice the customer for the time spent to fix the issues.
Here is our preliminary marketing blurb describing this situation (a kind of requirement specs, just with a slightly different tone...):
So here is how we plan to implement this. Please let me know what you think:
- We'd create a link from a "Project Tasks" to a bug tracker "Bug".
- When entering a new bug, the customer would create both a new Bug and a new Project Task.
- The Task is used by the Timesheet management system to allow developers to log their hours fixing the bug.
- The Task is also used to determine the customer's access permissions for the bug: Customers are allowed to see only their own bugs (developers would just go straight to the original bug-tracker).
- The information from the Timesheet is used to create customer invoices automatically. This is particularly useful for "maintenance projects", such as web site maintenance, where there is a continuous stream of update to be made.
We plan to leave the current "bug-tracker" package untouched (restricting read/write permissions to the developer team), and to create a new GPLed package probably called "intrant-bug-tracker" that would define the same index/ add-bug pages as "bug-tracker", but with additional security checks to honour the customer's project permissions.
]po[ already includes the timesheet and "invoice wizard" functionality to generate invoices based on timesheet hours and a price list, so that's easy.
I've checked dotProject, PHProject and several other free bug tracking tools, but none has that type of permissions and the integration with finance/invoicing. What do you think? Would this be useful for you? Where would you promote this stuff (obviously including the underlying OpenACS-platfrom...)?
Please let me know. All(!) feedback welcome.
Promotion is a good question. Probably the usual channels you are using for ]po[ (gosh, the previous name was much easier to type) anyway?
Malte: how does your "Automatic OpenOffice invoicing" with pm work?
Why don't you use a subsite for each customer and a bug
tracker instance on each?
Good point, we've been thinking about that. This makes definitely sense if the customer's bug trackers are independent from each other. Like when you're developing custom functionality for each customer.
However, atleast in our case we've got a single "Product" (]project-open[) that is shared amongst several hundered customers. And we've got a single development team that deals with all of the bugs. So we'd either need a "unified view" to all the different bug trackers or we'd need the above mentioned permission scheme.
But it's a good question: Do our target customers develop only a single product (product companies), or do they develop independent custom projects (service companies)? I guess that the majority are service companies...
Still, we don't work with "subsites" (]po[ consists of ~50 singleton packages), so that option wouldn't work for us.
However, we're planning to support multiple bug trackers for companies that are maintaining more then one "product". Then we'd assign the correct prodcut to each customer.
Yes, that would be interesting to learn about...
Probably the usual channels you are using for ]po[
Yeah, that's the easy one. But I was thinking about all of these PHP and Ruby guys that are looking for BugZilla, phProject etc. How to get the message through to them that there is a "superior" system around (OpenACS, naturally...)? Just getting an idea: What about posting on _their_ community pages and asking them to take a survey to inquire about their opinions or to compare the systems? Would be a pretty bold move, I guess...
Thanks for the feedback Malte!
- Use .LRN, then you have one community per customer. The unified looks work well through the portlets
- Use individual subsites. Then you are missing the unified view (at the moment), but don't have to deal with .LRN
Each project has an offer with offer_items. Once a task is closed, a callback inserts the logged hours as new offer_item with the unit = logged hours and the price per unit taken from the price list. As you can have default logger descriptions you can link them to the pricelist in the callback.
Once a project is closed, it is marked billable and
1) A new invoice is generated automatically by inserting the offer information into the invoice tables and calling iv_invoice::parse_data with some contacts::oo::import_pdf magic to generate the invoice
2) The billing department manually takes a look at all closed projects from a customer and generates an invoice across multiple projects (this is the reason why you have both "offers" and "invoices").
iv_invoice::parse_data sets the invoice variables and uses a special OO template (content.xml) which contains ADP commands (e.g. multiple) to generate a table with the invoice. The resulting content.xml is saved with zip in the invoice.odt file which is stored in /tmp.
contacts::oo::import_pdf then runs your OO Pdf converter of choice and stores the generated PDF in the invoice folder of the client.
All invoices can be sent via direct e-mail to the customer. Alternatively you can get a joined PDF with all invoices to you inbox if you want to print the invoices and mail them by snail mail.
Electronic signature for invoice PDFs is also on the "todo" list for the mediate term. Again there are a couple of approaches for this.
Hope this helps.
- it would be nice if each user in a subsite were to be able to view their own tickets, unless given permission to view other users tickets in that group.
- there should be the capability of having many master bt views that can pull in all of the tickets from all the subsites and their users into those views. the reason i say many is because you might have project managers responsible for different divisions where each would pull in tickets from their respective areas.
frank your description of the implementation is exactly what we were thinking about, the thought is that the implementation that you are describing is a subset of the 'subsite' hierarchical idea - that is to say your current idea seems to apply only to a single subsite view.
torben is porting sql ledger and if you REALLY WANT TO DO THIS RIGHT, you guys might want to talk to him and help him out.
as for the reporting tool, it is hard to say whether or not looking at integrating something like jasper reports would be of any use. it is basically a java library which has a good number of frontends and functions like crystal reports. on the outside its a great open source idea, but oacs already does a lot of this from an architectural standpoint and it might make more sense to take jasper reports and port the 'idea' to this platform with a web based interface to give us the freeform reporting capabilities of crystal should torbens port for example be overkill for a particular client.
- courtesy: we shouldn't be spamming other communities with our product because the default reaction will be defensive and automatically turn the discussion into a negative.
- ownership: let's not forget that open source is for a lot of people about ownership. a lot of projects aren't too open about discussing alternative projects and the default response tends to be defensive as well.
i think the whole community, and i mean all of us should talk about a few things that need to happen in order for us to more strategically promote the toolkit, and of course our own consultancies. i personally would like to see a slow, deliberate and co-ordinated effort where we track results versus a haphazzard approach where we throw stuff at the wall and see what sticks. i have a few ideas but because they over-arch the whole toolkit this may not be the best thread to follow up on this.
Thanks for your comments concerning promotion. I agree very much with you concerning possible negative reactions. However, it's important to think about "channels" and to branch away from "current OpenACS habits": Biggest OSS toolkit on earth? Least known toolkit on earth? I firmly believe that you have to experiment (I like your "see what sticks at the wall") and even to accept some negative feedback in order to "get your message through".
you REALLY WANT TO DO THIS RIGHT
Sorry, but I don't agree with that. SQL-Ledger focuses on "double-entry accounting", while ]po[ focuses on "project controlling". There is no right or wrong, just a focus on physical product (with inventory, inventory valoration, depreciation etc.) vs. service enterprises (project profit & loss, employee productivity, cash-flow, etc.). Accounting for service companies is like OpenACS for a static web site - possible, but it requires experts and loads of free time... But btw., the announcement of the SQL-Ledger port is about a year old, are there any news?
Reporting is "lame" anyway. Data-warehousing is a more flexible and powerful alternative. Checkout Mondrian + JPivot or OpenI for a complete OSS stack.
Btw., we've got our own TCL reporting engine (including groupings and sub-totals per group), but it's not GPLed and it's probably going to stay proprietary. Writing reports is so _incredibly_boring_ ...
Obviously we could just add the invoice to the internal accounting system based on SQL ledger, but as long as such a solution is not certified by the german tax authorities none of our clients would use it :).
Frank has written a reporting module (non GPL if not mistaken) based on Jasper, so he does have quite some experience in that field.
Just a brief update about our current advances:
We've got the first version of self-service interface for bug-tracker running on our own intranet. It's basicly working as described in the initial posting. We'll release the GPLed code probably with ]po[ V3.3 (after V3.2).
However, we had to fork the OpenACS bug-tracker package because most pages required customization:
- Permissions are different: Permissions now depend on the underlying project, not on the APM-package.
- Integration in the ]po[ GUI
- Integration with the ]po[ timesheet package
- Integration with the ]po[ finance module
So I fear that this is another example how fine but notable differences between "collaboration" and "ERP" processes require quite a different application architecture.
pull in all of the tickets from all the subsites
]po[ doesn't support the concept of subsites, so we won't offer bug reports cutting 'cross subsites. Instead, we might actually convert "components" into fully-fledged OpenACS objects representing a software package. So a single bug-tracker is sufficient.
it would be nice if each user in a subsite were to be
able to view their own tickets, unless given permission
to view other users tickets in that group.
Invoicing should be handled properly by an
Also working already. We even have a wizard to select invoicable hours and aggregate them into an invoice, multiplying them with prices pulled out of a per-customer price list based on "materials" (type of service).
We've got two main reports right now plus a pivot-table (data-warehouse light) for analysis of hours per customer, user, project and their respective DynFields (dynamic fields as of acs_attributes).
We've got even a module for business indicators (Kaplan's Balanced Scorecard) with the "diagram" package in our pipeline.