From 11945a73c631bedbcf8daaba531964c3fc2d6333 Mon Sep 17 00:00:00 2001 From: "justdave%syndicomm.com" <> Date: Thu, 5 Feb 2004 12:49:08 +0000 Subject: - Remove html, txt, and pdf directories from CVS - makedocs.pl now creates said directories when building the docs The idea here is that it's useless to have compiled stuff in CVS. The website will now auto-build the docs upon changes to the xml directory. --- docs/html/cust-change-permissions.html | 309 --------------------------------- 1 file changed, 309 deletions(-) delete mode 100644 docs/html/cust-change-permissions.html (limited to 'docs/html/cust-change-permissions.html') diff --git a/docs/html/cust-change-permissions.html b/docs/html/cust-change-permissions.html deleted file mode 100644 index aa28072ea..000000000 --- a/docs/html/cust-change-permissions.html +++ /dev/null @@ -1,309 +0,0 @@ -
This feature should be considered experimental; the Bugzilla code you - will be changing is not stable, and could change or move between - versions. Be aware that if you make modifications as outlined here, - you may have - to re-make them or port them if Bugzilla changes internally between - versions, and you upgrade. - |
Companies often have rules about which employees, or classes of employees, - are allowed to change certain things in the bug system. For example, - only the bug's designated QA Contact may be allowed to VERIFY the bug. - Bugzilla has been - designed to make it easy for you to write your own custom rules to define - who is allowed to make what sorts of value transition. -
For maximum flexibility, customizing this means editing Bugzilla's Perl - code. This gives the administrator complete control over exactly who is - allowed to do what. The relevant function is called - CheckCanChangeField(), - and is found in process_bug.cgi in your - Bugzilla directory. If you open that file and grep for - "sub CheckCanChangeField", you'll find it. -
This function has been carefully commented to allow you to see exactly - how it works, and give you an idea of how to make changes to it. Certain - marked sections should not be changed - these are the "plumbing" which - makes the rest of the function work. In between those sections, you'll - find snippets of code like: -
# Allow the owner to change anything. - if ($ownerid eq $whoid) { - return 1; - } |
So, how does one go about changing this function? Well, simple changes - can be made just be removing pieces - for example, if you wanted to - prevent any user adding a comment to a bug, just remove the lines marked - "Allow anyone to change comments." And if you want the reporter to have - no special rights on bugs they have filed, just remove the entire section - which refers to him. -
More complex customizations are not much harder. Basically, you add - a check in the right place in the function, i.e. after all the variables - you are using have been set up. So, don't look at $ownerid before - $ownerid has been obtained from the database. You can either add a - positive check, which returns 1 (allow) if certain conditions are true, - or a negative check, which returns 0 (deny.) E.g.: -
if ($field eq "qacontact") { - if (Bugzilla->user->groups("quality_assurance")) { - return 1; - } - else { - return 0; - } - } |
if (($field eq "priority") && - (Bugzilla->user->email =~ /.*\@example\.com$/)) - { - if ($oldvalue eq "P1") { - return 1; - } - else { - return 0; - } - } |
For a list of possible field names, look in - data/versioncache for the list called - @::log_columns. If you need help writing custom - rules for your organization, ask in the newsgroup. -