Home
The Toolkit for Online Communities
17469 Community Members, 1 member online, 2510 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Integrating bugs with bug tracker package

Forum OpenACS Development: Integrating bugs with bug tracker package

Icon of envelope Request notifications

Roadmap to automatically add a bug to the bug tracker or send email

We are thinking about how to automatically submit the bugs in a oacs installation, in order to keep track of them

Design

The basic idea is to add some parameters to the bug tracker package and use them to determine if the bug has to be submitted.

We need to add an error-report page, which is called from the rp_report_error proc in the acs-tcl package.

We add some parameters, such as: notify_errors and submit_to_bt (the names may change) that we will verify in the error-report-page and if notify_errors is set to true, present a form asking the user for a description of what the user was trying to do

We add an error-report-2 page, which verifies the value of submit_to_bt, and if is set to true, then submit the bug in the bug tracker (we may need another parameter to find out the bt instance and the default user to which the bug will be assigned) and send an email to the site-owner. If the parameter submit_to_bt is set to false then we will just send the email reporting the bug.

Roadmap

1. Modify the bug tracker package and add the parameters needed.
2. Modify the rp_report_error proc to get more info about the bug (the file, the url, the user_id, etc)
3. Add the error-report* pages that will check the parameters (we need to add at least one parameter in acs-tcl to find out the instance of the bug-tracker package, since we may have more than one instance of the package) and submit the bug, send an email or just ignore it, depending on the parameters values

Comments?

Collapse
Posted by Rocael Hernández Rizzardini on
Just for clarification, the aim is to automatically track the bugs in a given openacs installation to a given bug-tracker instance, and if defined, in a per module basis based on the package-key. This will be more than useful to any major openacs / .LRN installation. When a bug is submited, automatically useful information will be added to it.

Then second stage will be to track from several installations in different places to a given central bug-tracker through webservices (i.e. all the bugs from selected installations of dotlrn can go into a central bug-tracker)

Collapse
Posted by Deds Castillo on
I guess the important question is whether it can differentiate bugs from stock and bugs introduced by custom code?
Collapse
Posted by Nima Mazloumi on
Hi,

we took a different direction here and due to usability consinderations decided not to use package keys for bug-tracker components in the first place since most users don't know what the key stands for the most cases. Instead we decided for more abstract components like "Account Management", "Notification System", "Group Administration", "File System", "Calendar System"...

Next we map these more general components to the actual package. This happens manually at present by the responsible user of the component.

Also we use bug-tracker as a support center and not as a bug-tracking system. Therefore I suggest defining a new initial setting in bug-tracker-procs.tcl proc bug_tracker::get_default_configurations. This was important because the given ones don't really make sense. Too much redundant info like severity "critical" and priority "high" or bug type "sugestion" and severity "enhancement"!

        "Support-Center" {
            categories {
                "Message Type" {
                    "Problem"
                    "Suggestion"
                    "Error"
                }
                "Priority" {
                    "1 - High"
                    "*2 - Normal"
                    "3 - Low"
                }
            }
            parameters {
                TicketPrettyName "message"
                TicketPrettyPlural "messages"
                ComponentPrettyName "area"
                ComponentPrettyPlural "areas"
                PatchesP "0"
                VersionsP "0"
            }
        }

So an automated solution would be to offer a message form in bug-tracker as soon as an error occurred, display the more general component name, map to the actual package where the error occurred, autofill the important info like referer, requested url, query, error log and switch on the notification for that user so that he receives a reply once the message was handled.

There is still a problem here. We don't want users to submit a message that was already submitted by someone else. Also beside of real bugs you have user mistakes like duplicate upload of a file. These cases should get caught and if there is a "solution" available displayed before the form is offered.

We could use Patches as solutions for user mistakes. In this case PatchesP has to be 1. So with time we would have a large solution database. A "patch" corresponds to a "solution" in this context.

Some important things that we need consideration:

- automatically turning on notification for users. most forget or don't know that this is required. Otherwise the admin will reply and it will never reach the user.

- automatically close a bug once the admin has resolved the message. Otherwise you will end up with a large list of users who simply don't close them manually. The policy here should be reopen it, if you are not satisfied. The user should also be unsubscribed once the message was closed.

- bug-tracker is awful slow

- maybe with the new AMS package it would make sense to create a new support package from scratch in the long run. AMS would also allow displaying info depending on roles. While the user entry should be displayed for instance automatically filled info like referer, requested url, error log shouldn't be visible for others but maintainers

- I also think that in the longrun it would be important to protokoll more information for forms where errors occur. Like what was the value of the input fields to reconstruct the error better.

- Change OpenACS to display request errors inside the master template.

- maybe it would make sense to define automatically error ids that map to solution ids to better with a 1:n relation since some errors can have different reason and therefore different solutions.

- and finally we shouldn't forget i18n for the solution system. Since there is a 1:1 relationship between package and solution I would use the unique solution id to create a solution message key in the corresponding catalog file with its corresponding solution the maintainer has created and display the solution i18n-ized from the very beginning. This way we can easily spread the solution database simply by committing the catalog file back to cvs. of course we need to ensure globally unique keys which is no real problem.

Greetings,
Nima

Collapse
Posted by Rocael Hernández Rizzardini on
Hi Nima,
thanks for your post and for sharing your experience, is very valuable.
Yes, this is a support center rather than a bug-tracker, some of your suggestions has been already planed while others will be added for this first version. Jose will merge this and produce a more formal document for the first version of this support center based on the bug-tracker.

We'll not ask to the user to select to which component the bug should go, it automatically be assiged based on package-key.

The release of the first approach will come soon.

Collapse
Posted by Jose Pablo Escobedo Del Cid on
Hi,

By the moment we will work on the first specification plus some of your suggestions, such as:

- automatically turning on notification for users. most forget or don't know that this is required. Otherwise the admin will reply and it will never reach the user.

- Change OpenACS to display request errors inside the master template.

May be in the long term we can think about the other ones, or, as you suggested, create a new support package from scratch.

Regards, Jose

Collapse
Posted by Nima Mazloumi on
Hi,

one thought that came to my mind. From experience I can say that workflow is not intuitive for students. Once they create a bug only few really close the bug when resolved. So we should think of a way to close bugs automatically when a student don't resolve it within a given timeframe. Also the students notification should get removed afterwards.

The reason for all that is that after dotLRN is running the support for a while you will have a large list of bugs that are not resolved and the list of users who have to close a bug on the left will become longer and longer.

What do you think?

Greetings,
Nima

Collapse
Posted by Jose Pablo Escobedo Del Cid on
Hi Nima,

You are right, may be we can schedule a proc to close the bugs that have not been modified for... 2 months? comments/suggestions?

Thanks, Jose

Collapse
Posted by Nima Mazloumi on
What about adding a package parameter that allows an admin to adjust after how many days an open bugs should be removed?
Collapse
Posted by Jose Pablo Escobedo Del Cid on
That sounds better, thanks!