The general answer on this one is always "Don't write this one yourself". Having had more than my share of experience with this issue, I can say that this is not always the correct answer. I have written and currently am in the process of writing v2.0 of an equivalent application for work flow tracking and reporting. There are times to use an off-the-shelf product, and times when you really need to write your own (which is where these commercial packages originally come from anyway).

First, there are number of really excellent applications out there for bug tracking, time tracking, work tracking. You can assume that an open source version is going to be much better than a shrink-wrap version, for one simple reason -- feature bloat. Because every company has different needs, the shrink wrap versions NEVER fit perfectly and almost always are impossible to tweak. I happen to really like Keystone, from Stonekeep Consulting, because it is free for small departments, it is easy to set up, and it is built on PHP with a mysql database. (I like PHP almost as much as perl, for different reasons)

Second, if you test a couple of packages, and you find that they don't fit your needs, then by all means, write one yourself. This is the route I took, and my department could not be more delighted. I learned a couple of things though -- interview the users before you start writing the application, map the flows/processes out early on, work out the logic -- in short, design, design, design!! Then, make sure your boss is 100% behind you (we did our programming in secret as a surprise gift for our manager -- we're just lucky it worked out well). KISS and get yerself a frozen feature set, and your life will be made much easier.

To answer your specific question, I have a set of named permissions in my database -- Administrator, Developer, Project Manager, Client, etc.
Every time a ticket is retrieved from the database the current user's permission level is also available. If a field on the form is read-only at the user's level of permissions, then only the value in the database is printed. If the user has read-write permission (like the Administrator) then the equivalent popup box or text box or whatever is printed to the screen so that the user can modify it. The code is not the cleanest, but that's why I said design before code earlier :-) Lots of stuff got tacked on later.

Hope this extensive ramble helps you out some.