Bug Tracker Blog by Corey Trager

Sharing BugTracker.NET with your customers.

by Corey Trager 16. December 2007 03:59


A month ago I started to write about some settings where BugTracker.NET is not such a good fit.  This post covers the situation, “A consulting-type company that writes software for outside clients and wants to use BugTracker.NET as a collaboration tool, but with a distinction between internal and external users”.

In the month that has passed since I wrote the original post, I’ve released improvements to BugTracker.NET with the intent to fit this situation better.  A month ago I couldn’t say this, but now I can: BugTracker.NET is now a good fit for this situation.   You can set up your customers so that they can use the system but not see each others’ issues.   You can also mark posts as for your internal users only.   Documentation here.

These changes were hard for a few reasons.  

One is that I myself haven’t used BugTracker.NET in this situation so I had no day-to-day experience to motivate me and shape my own vision of where I wanted to go.   I wasn’t proactive.   Rather, I reacted to specific requests/complaints from users, and my motivation had to come from my desire to please as opposed to creating something that I would be using.

Another reason is that coding a permission scheme is really hard.  Not hard like doing a math proof, but just.. oh… tedious.    It both requires concentration, and yet, is boring, at the same time.  So many cases, so many permutations to test.   It’s work that had to be done, but I didn’t enjoy doing it.  

The code is especially difficult because it evolved in an unplanned way over the past five years.   BugTracker.NET has two, maybe you could even say, three permission schemes.   One is based on projects, the other is based on organizations.   But, using my “DefaultPermissionLevel” setting, you can change the project scheme from one where permissions are granted by default but can be explicitly limited to scheme where nobody can do anything until he is explicitly granted permission.   So, the project scheme, is really like two separate schemes.

For the BugTracker.NET administrator, the great thing is that he can use BugTracker.NET right out of the box without setting up any permissions.   But for me, the coder, it’s tough. 

To give you a taste of how dense and tedious the code to handle permissions can be, below is the SQL  that automatically creates subscriptions to email notifications when a bug is added, based on whether users have permissions to receive notifications for that bug or not and based on what the user wants to subscribe to.  It's hard for me to understand, and I wrote it.

insert into bug_subscriptions (bs_bug, bs_user)
select $id, us_id
from users
inner join orgs on us_org = og_id
inner join bugs on bg_id = $id
left outer join project_user_xref on pu_project = @pj and pu_user = us_id
where us_auto_subscribe = 1
and
    case
        when
            us_org <> bg_org
            and og_other_orgs_permission_level < 2
            and og_other_orgs_permission_level < isnull(pu_permission_level,$dpl)
                then og_other_orgs_permission_level
        else
            isnull(pu_permission_level,$dpl)
    end <> 0
and us_active = 1
and us_id not in
(select bs_user from bug_subscriptions
where bs_bug = $id)

insert into bug_subscriptions (bs_bug, bs_user)
select $id, pj_default_user
from projects
inner join users on pj_default_user = us_id
where pj_id = @pj
and pj_default_user <> 0
and pj_auto_subscribe_default_user = 1
and us_active = 1
and pj_default_user not in
(select bs_user from bug_subscriptions
where bs_bug = $id)

insert into bug_subscriptions (bs_bug, bs_user)
select $id, pu_user from project_user_xref
inner join users on pu_user = us_id
inner join orgs on us_org = og_id
inner join bugs on bg_id = $id
where pu_auto_subscribe = 1
and
    case
        when
            us_org <> bg_org
            and og_other_orgs_permission_level < 2
            and og_other_orgs_permission_level < isnull(pu_permission_level,$dpl)
                then og_other_orgs_permission_level
        else
            isnull(pu_permission_level,$dpl)
    end <> 0
and us_active = 1
and pu_project = @pj
and pu_user not in
(select bs_user from bug_subscriptions
where bs_bug = $id)

insert into bug_subscriptions (bs_bug, bs_user)
select $id, us_id
from users
inner join bugs on bg_id = $id
inner join orgs on us_org = og_id
left outer join project_user_xref on pu_project = @pj and pu_user = us_id
where ((us_auto_subscribe_own_bugs = 1 and bg_assigned_to_user = us_id)
    or
    (us_auto_subscribe_reported_bugs = 1 and bg_reported_user = us_id))
and
    case
        when
            us_org <> bg_org
            and og_other_orgs_permission_level < 2
            and og_other_orgs_permission_level < isnull(pu_permission_level,$dpl)
                then og_other_orgs_permission_level
        else
            isnull(pu_permission_level,$dpl)
    end <> 0
and us_active = 1
and us_id not in
(select bs_user from bug_subscriptions
where bs_bug = $id)

Tags:

Comments

12/26/2007 12:14:37 PM #

Nice!  Keep up the good work!

Damiaan |

2/25/2008 6:04:41 PM #

Hi Corey,

Now that I've gotten Bugtracker up and running and I'm learning the features and browsing your site for information about how to use your program, I came across this item in the blog, and I want to let you know that “A consulting-type company that writes software for outside clients and wants to use BugTracker.NET as a collaboration tool, but with a distinction between internal and external users” is exactly what I am looking for in an issue tracking tool.

This feature would help maintain the peak on the featuritis curve for me, and when evaluating issue tracking tools, I had not used this as a criteria because I knew it was what I wanted, but didn't know I had to specify it??  So if you didn't have this feature, I would have to try something else, so I'm glad you put it in there Smile

I need to have the capability of making the tool such that clients cannot see issues related to other clients, since that would violate non-disclosure of proprietary / confidential information......

Thanks!!

Steve |

3/1/2008 3:53:52 PM #

Steve - These past couple months I've been focusing on the weaknesses I outlined in my post ifdefined.com/.../Eating-my-own-dog-food.aspx.  So, hopefully, BugTracker.NET fits your situation now.

Corey Trager |

Comments are closed

Powered by BlogEngine.NET 1.5.0.7

RecentComments

Comment RSS