Designing permission names

I'm looking for sources of information on designing permission names for our web-based application.

For example, if I want a permission for creating a new member of staff, this might be called create_staff, new_employee, add_worker or any number of different names for the same thing.

This new staff member permission might require multiple开发者_如何转开发 'parent' permissions to work; edit_employee_name, update_date_of_birth etc. At the moment, looing at the names of these 'parent' permissions they can't be distinguished from the child permissions.

1. Can you recommend a strategy for designing names in a consistent manner across the application?
2. Perhaps more importantly, do any tools exist to manage a central 'list' of permission names, perhaps with permission groups or nests, so that developers, database designers and HR staff know what to call something, what to store and what it does?

We're coding in php and MySQL, (and currently using phpGACL) but approaches from any other language would be welcome. Thanks!

You could find inspiration from linux where the rights are "read", "write" and "execute" and prepend these or similar verbs to your own nouns. (I think you are on the right track.)

The term you're searching for is most probably ACL (access control list). Zend_Acl is a PHP implementation of this pattern which supports pretty fine grained solutions like inheritance. This article is hopefully a good guide for using Zend_Acl even if you are not already familiar with the Zend Framework. MySQL fits very nicely as a storage for the design of Zend_Acl.

I think your examples look fine but keep in mind to be consistent in your wordings. Solutions to this could include to issue a small guide or have one person naming all of the rules.

Answer to comment:

You really should be talking to those involved (both designers and users) with the ACL, to see what they like. The starting point could be verb_noun(s). Make sure every rule can be answered with true or false, otherwise the rule is not clear. Make sure the designers & users know what each noun and verb means in your context, this includes domain/business logic. Also make sure that possible business terms are not used, for example if your business are using made up names which can mean something different in "dev-speak" - do not use it. Another rule that could help: avoid stop words.

designers & users = devs and those who ever read the name of the rule :)