Re: [fossil-users] ticket assignment
On 05/12/2010 10:37 PM, zachtodd wrote: Jeremy, a per project security attribute that allows all developers to assign to each other is an interesting idea. That's not what's being asked for. In fossil there are a set of available capabilities. For each user, admin can check a box whether that user has a given capability. There are some convenient groupings of capabilities to make it easy to assign common sets to users, and admin can change what capabilities are contained in each grouping. So if there's a capability to be added that doesn't wholly belong to any existing capability, to be consistent with the rest of fossil it should be its own capability that can be assigned or not to any actual user or capability group. E.g., On some of my projects, the repos are private. I've disabled all public and anonymous access, and I've added those capabilities to Reader. Who are Readers for me? They're the several other stakeholders who work with the software I'm developing but aren't developers. I give them source reading access so they can see the timeline, and they can create tickets to document issues they find. I also create tickets for them sometimes when there's some related information gathering, etc.. that needs to be done. In my case, I would give ticket re-assign capability to Readers (them) as well as to Developers (me), since if I create a ticket for the wrong person or someone else has the free time first, I want them to be able to reassign tickets as needed. But this brings up the issue that apparently to use your new ticket assignment system--which lists developers only as possible assignees--I would have to make all my other users developers, even though they shouldn't have write access to the source. I think may be assigned tickets should be one capability belonging to developers by default, and may reassign tickets should be another capability belonging to admins or developers by default. In the small-team proprietary projects I've worked on and the larger open source ones I've observed, reassigning would have been a capability of any developer, limited by group expectations, but if you work with the existing capability system, who gets the capability is easily changed, so I have no strong opinion on whether reassign should be admins-only by default. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
Joshua, thank you for the feedback. Having may be assigned to and may assign/re-assign capabilities may give people the granularity they're looking for. It seems sensible to default developers/admins so that they possess both may be assigned to and assign/re-assign capabilities, but as it would be a separate capability, users can grant these permissions however they want. My only reservation with may be assigned to is that it complicates matters a little. Interface wise, I originally had just a textbox in which a username could be typed, and if it didn't match anyone, nothing catastrophic would happen, and it could just be re-assigned. The may be assigned to capability introduces a subset of users, which would suggest having a drop down instead of a plain textbox. I'll have to play around with this to see what feels right. If anyone has further suggestions on the look/feel, or implementation, please let me know. -Original Message- From: Joshua Paine jos...@letterblock.com Sent: Thursday, May 13, 2010 11:11am To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] ticket assignment On 05/12/2010 10:37 PM, zachtodd wrote: Jeremy, a per project security attribute that allows all developers to assign to each other is an interesting idea. That's not what's being asked for. In fossil there are a set of available capabilities. For each user, admin can check a box whether that user has a given capability. There are some convenient groupings of capabilities to make it easy to assign common sets to users, and admin can change what capabilities are contained in each grouping. So if there's a capability to be added that doesn't wholly belong to any existing capability, to be consistent with the rest of fossil it should be its own capability that can be assigned or not to any actual user or capability group. E.g., On some of my projects, the repos are private. I've disabled all public and anonymous access, and I've added those capabilities to Reader. Who are Readers for me? They're the several other stakeholders who work with the software I'm developing but aren't developers. I give them source reading access so they can see the timeline, and they can create tickets to document issues they find. I also create tickets for them sometimes when there's some related information gathering, etc.. that needs to be done. In my case, I would give ticket re-assign capability to Readers (them) as well as to Developers (me), since if I create a ticket for the wrong person or someone else has the free time first, I want them to be able to reassign tickets as needed. But this brings up the issue that apparently to use your new ticket assignment system--which lists developers only as possible assignees--I would have to make all my other users developers, even though they shouldn't have write access to the source. I think may be assigned tickets should be one capability belonging to developers by default, and may reassign tickets should be another capability belonging to admins or developers by default. In the small-team proprietary projects I've worked on and the larger open source ones I've observed, reassigning would have been a capability of any developer, limited by group expectations, but if you work with the existing capability system, who gets the capability is easily changed, so I have no strong opinion on whether reassign should be admins-only by default. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
I have added some additional features to ticket assignment. Administrators may
assign on ticket creation/editing. Normal developers may now assign and
unassign themselves without any special privileges. Viewing who has what
ticket and self assigning/unassigning is done right in the all tickets
listing.
Jeremy, a per project security attribute that allows all developers to assign
to each other is an interesting idea. That may be where I head next, but I
wanted to see if anyone had any comments about the design and implementation of
what I have done so far.
diff -rupN fossil_src_orig/src/report.c fossil/src/report.c
--- fossil_src_orig/src/report.c2010-03-18 10:20:53.0 -0400
+++ fossil/src/report.c 2010-05-12 22:08:36.372518961 -0400
@@ -646,13 +646,14 @@ static int generate_html(
int i;
const char *zTid; /* Ticket UUID. (value of column named '#') */
int rn;/* Report number */
+ char zrn[4];
char *zBg = 0; /* Use this background color */
char zPage[30];/* Text version of the ticket number */
/* Get the report number
*/
rn = pState-rn;
-
+ sprintf(zrn, %d, rn);
/* Do initialization
*/
if( pState-nCount==0 ){
@@ -759,6 +760,13 @@ static int generate_html(
}else{
@ td valign=top%h(zData)/td
}
+}else if ( strcmp(azName[i], assignedto) == 0 ){
+ if ( zData[0]==0 )
+@ td valign=topa
href=/tktassign?name=%h(zTid)rn=%h(zrn)unassigned/a/td
+ else if ( strcmp(zData, g.zLogin) == 0 )
+@ td valign=top%h(zData) a
href=/tktunassign?name=%h(zTid)rn=%h(zrn)(unassign)/a/td
+ else
+@ td valign=top%h(zData)/td
}else if( zData[0]==0 ){
@ td valign=topnbsp;/td
}else{
diff -rupN fossil_src_orig/src/schema.c fossil/src/schema.c
--- fossil_src_orig/src/schema.c2010-03-18 10:20:53.0 -0400
+++ fossil/src/schema.c 2010-05-09 11:15:12.108214371 -0400
@@ -171,10 +171,33 @@ const char zRepositorySchema1[] =
@ datetime(tkt_mtime) AS ''mtime'',
@ type,
@ status,
+@ assignedto,
@ subsystem,
@ title
@ FROM ticket');
@
+@ INSERT INTO reportfmt(title,cols,sqlcode) VALUES('My Tickets','#ff Key:
+@ #f2dcdc Active
+@ #e8e8e8 Review
+@ #cfe8bd Fixed
+@ #bde5d6 Tested
+@ #cacae5 Deferred
+@ #c8c8c8 Closed','SELECT
+@ CASE WHEN status IN (''Open'',''Verified'') THEN ''#f2dcdc''
+@WHEN status=''Review'' THEN ''#e8e8e8''
+@WHEN status=''Fixed'' THEN ''#cfe8bd''
+@WHEN status=''Tested'' THEN ''#bde5d6''
+@WHEN status=''Deferred'' THEN ''#cacae5''
+@ELSE ''#c8c8c8'' END AS ''bgcolor'',
+@ substr(tkt_uuid,1,10) AS ''#'',
+@ datetime(tkt_mtime) AS ''mtime'',
+@ type,
+@ status,
+@ assignedto,
+@ subsystem,
+@ title
+@ FROM ticket WHERE assignedto=user()');
+@
@ -- Some ticket content (such as the originators email address or contact
@ -- information) needs to be obscured to protect privacy. This is achieved
@ -- by storing an SHA1 hash of the content. For display, the hash is
@@ -358,6 +381,7 @@ const char zRepositorySchema2[] =
@ priority TEXT,
@ severity TEXT,
@ foundin TEXT,
+@ assignedto TEXT,
@ private_contact TEXT,
@ resolution TEXT,
@ title TEXT,
diff -rupN fossil_src_orig/src/tkt.c fossil/src/tkt.c
--- fossil_src_orig/src/tkt.c 2010-03-18 10:20:53.0 -0400
+++ fossil/src/tkt.c2010-05-12 21:52:11.766531533 -0400
@@ -291,6 +291,74 @@ void ticket_rebuild(void){
}
/*
+** WEBPAGE: tktassign
+** URL: tktassign?name=UUID
+**
+** Assign current user to ticket.
+*/
+void tktassign(void){
+ const char *zUuid;
+ const char *zFrom;
+ const char *zFullName;
+
+ Stmt q;
+ zUuid = PD(name, );
+ zFrom = PD(rn, );
+
+ login_check_credentials();
+
+ zFullName = db_text(0,
+ SELECT tkt_uuid FROM ticket
+ WHERE tkt_uuid GLOB '%q*', zUuid);
+
+ db_prepare(q, UPDATE ticket SET assignedto=:user WHERE tkt_uuid=:ticket);
+ db_bind_text(q, :user, g.zLogin);
+ db_bind_text(q, :ticket, zFullName);
+
+ db_step(q);
+ db_finalize(q);
+ cgi_redirectf(rptview?rn=%T, zFrom);
+}
+
+/*
+** WEBPAGE: tktunassign
+** URL: tktunassign?name=UUID
+**
+** Unassign from a ticket.
+*/
+void tktunassign(void){
+ const char *zUuid;
+ const char *zFrom;
+ const char *zFullName;
+ const char *zAssignedto;
+
+ Stmt q;
+ zUuid = PD(name, );
+ zFrom = PD(rn, );
+
+ login_check_credentials();
+
+ zFullName = db_text(0,
+ SELECT tkt_uuid FROM ticket
+ WHERE tkt_uuid GLOB '%q*', zUuid);
+
+ db_prepare(q, SELECT assignedto FROM ticket WHERE tkt_uuid=%Q, zFullName);
+ db_step(q);
+
+ zAssignedto = db_column_text(q, 0);
+
+ if (strcmp(g.zLogin, zAssignedto) != 0){
+ cgi_redirect(home);
+ }
+
+ db_prepare(q, UPDATE ticket SET assignedto='' WHERE tkt_uuid=%Q,
zFullName);
+
+ db_step(q);
+ db_finalize(q);
+ cgi_redirectf(rptview?rn=%T, zFrom);
+}
+
+/*
** WEBPAGE: tktview
** URL: tktview?name=UUID
**
diff
Re: [fossil-users] ticket assignment
I have continued work on ticket assignment. Tickets can now be assigned by
administrators. Users have a My Tickets report, and an Assigned column now
exists in the ticket listings. I would like to give users the ability to assign
and unassign themselves. What does everybody think?
diff -rupN fossil_src_orig/src/schema.c fossil/src/schema.c
--- fossil_src_orig/src/schema.c2010-03-18 10:20:53.0 -0400
+++ fossil/src/schema.c 2010-05-09 11:15:12.108214371 -0400
@@ -171,10 +171,33 @@ const char zRepositorySchema1[] =
@ datetime(tkt_mtime) AS ''mtime'',
@ type,
@ status,
+@ assignedto,
@ subsystem,
@ title
@ FROM ticket');
@
+@ INSERT INTO reportfmt(title,cols,sqlcode) VALUES('My Tickets','#ff Key:
+@ #f2dcdc Active
+@ #e8e8e8 Review
+@ #cfe8bd Fixed
+@ #bde5d6 Tested
+@ #cacae5 Deferred
+@ #c8c8c8 Closed','SELECT
+@ CASE WHEN status IN (''Open'',''Verified'') THEN ''#f2dcdc''
+@WHEN status=''Review'' THEN ''#e8e8e8''
+@WHEN status=''Fixed'' THEN ''#cfe8bd''
+@WHEN status=''Tested'' THEN ''#bde5d6''
+@WHEN status=''Deferred'' THEN ''#cacae5''
+@ELSE ''#c8c8c8'' END AS ''bgcolor'',
+@ substr(tkt_uuid,1,10) AS ''#'',
+@ datetime(tkt_mtime) AS ''mtime'',
+@ type,
+@ status,
+@ assignedto,
+@ subsystem,
+@ title
+@ FROM ticket WHERE assignedto=user()');
+@
@ -- Some ticket content (such as the originators email address or contact
@ -- information) needs to be obscured to protect privacy. This is achieved
@ -- by storing an SHA1 hash of the content. For display, the hash is
@@ -358,6 +381,7 @@ const char zRepositorySchema2[] =
@ priority TEXT,
@ severity TEXT,
@ foundin TEXT,
+@ assignedto TEXT,
@ private_contact TEXT,
@ resolution TEXT,
@ title TEXT,
diff -rupN fossil_src_orig/src/tktsetup.c fossil/src/tktsetup.c
--- fossil_src_orig/src/tktsetup.c 2010-03-18 10:20:53.0 -0400
+++ fossil/src/tktsetup.c 2010-05-09 10:56:31.412964471 -0400
@@ -289,6 +289,17 @@ static const char zDefaultNew[] =
@ affect the operation of the product?/td
@ /tr
@
+@ th1
+@ if {[hascap a]} {
+@ html tr
+@ html td align='right'Assigned To:
+@ html input type='text' name='assignedto' value=''
+@ html /td
+@ html tdShould this issue be assigned to a particular developer?/td
+@ html /tr
+@ }
+@ /th1
+@
@ tr
@ td align=rightEMail:
@ input type=text name=private_contact value=$private_contact
size=30
@@ -377,8 +388,11 @@ static const char zDefaultView[] =
@ /td/tr
@ trtd align=rightSeverity:/tdtd bgcolor=#d0d0d0
@ $severity
-@ /td
-@ td align=rightPriority:/tdtd bgcolor=#d0d0d0
+@ /td/tr
+@ trtd align=rightAssigned:/tdtd bgcolor=#d0d0d0
+@ $assignedto
+@ /td/tr
+@ trtd align=rightPriority:/tdtd bgcolor=#d0d0d0
@ $priority
@ /td/tr
@ trtd align=rightSubsystem:/tdtd bgcolor=#d0d0d0
-Original Message-
From: Gour g...@gour-nitai.com
Sent: Thursday, May 6, 2010 11:41am
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] ticket assignment
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Thu, 6 May 2010 11:30:05 -0400
Erik == Erik Lechak wrote:
Erik Thumbs up from me. I would like to see an assigned-to feature
Erik added to Fossil. It would be great if it was available right out
Erik of the box.
+1
Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: F96FF5F6
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
On 5/9/2010 11:27 AM, zacht...@cis-partners.com wrote: I have continued work on ticket assignment. Tickets can now be assigned by administrators. Users have a My Tickets report, and an Assigned column now exists in the ticket listings. I would like to give users the ability to assign and unassign themselves. What does everybody think? I would make it a simple security attribute that can be controlled per project. i.e. in many projects, I'd allow any developer to assign to any other developer. Maybe John is stuck and wants to give this bug to Jane. I, as the administrator, do not want to have to deal with these changes. Now, on other projects this may not be the case. I may want to handle these type of changes as the admin. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
On Sun, 09 May 2010 11:46:39 -0400 Jeremy == Jeremy Cowgar wrote: Jeremy I would make it a simple security attribute that can be Jeremy controlled per project. i.e. in many projects, I'd allow any Jeremy developer to assign to any other developer. Maybe John is stuck Jeremy and wants to give this bug to Jane. I, as the administrator, do Jeremy not want to have to deal with these changes. +1 Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
On 5/6/2010 11:30 AM, Erik Lechak wrote: Hello, Thumbs up from me. I would like to see an assigned-to feature added to Fossil. It would be great if it was available right out of the box. Some interesting features might be: * Only admins can assign tasks to others * Non admins can assign tasks to themselves * Non admins can un-assign themselves from a task * For admins the list of people that can be assigned a task comes from the list of users not a separate list that needs to be maintained If something like this were to be created, I think a new security attribute should be created, can assign or something. Therefore, you could give the can-assign attribute to an admin or to anonymous if you wish. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
On Thu, 6 May 2010 11:30:05 -0400 Erik == Erik Lechak wrote: Erik Thumbs up from me. I would like to see an assigned-to feature Erik added to Fossil. It would be great if it was available right out Erik of the box. +1 Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ticket assignment
I have developed a simple patch to introduce ticket assignment. I have yet to
add an assigned to column in all places that may be necessary. Is this
something people would be interested in seeing included with the standard
fossil distribution?
diff -rupN fossil_src_orig/src/schema.c fossil_new/src/schema.c
--- fossil_src_orig/src/schema.c2010-03-18 10:20:53.0 -0400
+++ fossil_new/src/schema.c 2010-05-05 21:00:11.762884455 -0400
@@ -175,6 +175,27 @@ const char zRepositorySchema1[] =
@ title
@ FROM ticket');
@
+@ INSERT INTO reportfmt(title,cols,sqlcode) VALUES('My Tickets','#ff Key:
+@ #f2dcdc Active
+@ #e8e8e8 Review
+@ #cfe8bd Fixed
+@ #bde5d6 Tested
+@ #cacae5 Deferred
+@ #c8c8c8 Closed','SELECT
+@ CASE WHEN status IN (''Open'',''Verified'') THEN ''#f2dcdc''
+@WHEN status=''Review'' THEN ''#e8e8e8''
+@WHEN status=''Fixed'' THEN ''#cfe8bd''
+@WHEN status=''Tested'' THEN ''#bde5d6''
+@WHEN status=''Deferred'' THEN ''#cacae5''
+@ELSE ''#c8c8c8'' END AS ''bgcolor'',
+@ substr(tkt_uuid,1,10) AS ''#'',
+@ datetime(tkt_mtime) AS ''mtime'',
+@ type,
+@ status,
+@ subsystem,
+@ title
+@ FROM ticket WHERE assignedto=user()');
+@
@ -- Some ticket content (such as the originators email address or contact
@ -- information) needs to be obscured to protect privacy. This is achieved
@ -- by storing an SHA1 hash of the content. For display, the hash is
@@ -359,6 +380,7 @@ const char zRepositorySchema2[] =
@ severity TEXT,
@ foundin TEXT,
@ private_contact TEXT,
+@ assignedto TEXT,
@ resolution TEXT,
@ title TEXT,
@ comment TEXT
diff -rupN fossil_src_orig/src/tktsetup.c fossil_new/src/tktsetup.c
--- fossil_src_orig/src/tktsetup.c 2010-03-18 10:20:53.0 -0400
+++ fossil_new/src/tktsetup.c 2010-05-05 21:11:33.683636050 -0400
@@ -290,6 +290,13 @@ static const char zDefaultNew[] =
@ /tr
@
@ tr
+@ td align=rightAssigned To:
+@ input type='text' name='assignedto' size='20' value=$assignedto
+@ /td
+@ tdShould this issue be assigned to a particular developer?/td
+@ /tr
+@
+@ tr
@ td align=rightEMail:
@ input type=text name=private_contact value=$private_contact
size=30
@ /td
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
On Wed, 05 May 2010 21:25:51 -0400 Joshua == Joshua Paine wrote: Joshua Put me down as a big don't care one way or the other. It wasn't Joshua hard to add it on the repos where I needed it. May I suggest to add it to the wiki's Cookbook section? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
On Thursday 06 May 2010 04:18:20 zacht...@cis-partners.com wrote: I have developed a simple patch to introduce ticket assignment. I have yet to add an assigned to column in all places that may be necessary. Is this something people would be interested in seeing included with the standard fossil distribution? Did you look at this link (which is on the Fossil main page)? http://www.fossil-scm.org/index.html/doc/tip/www/custom_ticket.wiki -- Sending me something private? Use my GPG public key: AD29415D signature.asc Description: This is a digitally signed message part. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ticket assignment
On Thu, 6 May 2010 06:44:21 +0300 Ron == Ron Aaron wrote: Ron Did you look at this link (which is on the Fossil main page)? Ron Ron http://www.fossil-scm.org/index.html/doc/tip/www/custom_ticket.wiki Heh, as it usually happens, I've discovered it 15mins after posting. :- I had to read some other docs which were open on the earlier tabs in FF... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
