> Departments, Roles, Policies, Permissions, Users I do something similar, although the terms I use for them are a bit cattywampus.
Profiles contain collections of individual roles (which I suppose are analogous to what most people call 'permissions'... old and bad habit on my part using that nomenclature). These in turn cover all sorts of things. To control access to the template membereditor.cfm, I might have a 'role' called 'membereditor' that would be tested for at the start of the code in that template. No role=sayonara. Then to control the individual 'edit' and 'delete' buttons (or whether form fields showed up at all in the first place) I might have roles like 'membereditor_edit' and 'membereditor_delete' and test for those everywhere a form field might be shown, or perhaps just cover the submit button and the data save code for a little less tedious coding. Default profiles (like Sales_Admin and Marketing_Wonk) containing collections of roles can be applied to anyone. And then the individual can be customized to any degree, provided the user has the permission to do that. As Micha said the interface is key as you wind up with a lot of permissions to manage over time. Especially true if your system is live and growing, and you have to add new permissions and retrofit existing user profiles. -- --Matt Robertson-- President, Janitor MSB Designs, Inc. mysecretbase.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - RUWebby http://www.ruwebby.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188333 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
