[TurboGears] Re: identity info in a config file

[Jeff Watkins]

On 31 Mar, 2006, at 4:28 pm, Jorge Godoy wrote: And if you need an extra group for a new situation you didn't have while you developed the application, you're again needing to edit code. In my experience, when you need a new group for a new situation it has almost always involved new code surrounding either the new group or new situation. Unless you dramatically failed to design the original code, it shouldn't change (or at least not change significantly) only the new code should "change". If you look at the design of many systems, functions have specific required permissions: want to mount backup media, you must have the mount-backup-media permission; want to reboot the system, you must have the power-down-system permission; want to change the disk quotas, you must have the modify-system-quotas permission; etc. These permissions get combined into groups for convenience: Admin has permission to mount-backup-media, power-down-system, modify-system-quotas, etc. You then assign users to these groups. In your straw man argument you have clearly not distinguished the permissions enough. If you assign sufficient granularity to your permissions, you'll NEVER edit code only modify group membership. Identity management is like any other complex issue: you have to take time to really think about it before writing a line of code. If you just hack it together as you go, it won't work long term. Initially, when I was designing TG's Identity framework, I considered not even allowing a check for a particular group. But the fact is for a quick and dirty project, all you need is group checks. And Kevin convinced me to target the low end of the spectrum as well as the high end. Here are some issues on which I think someone's effort could be well spent: * Collect all the permissions and groups referenced in a project (ala Admi18n Collect Strings) * Automatically create collected permissions and groups * Toolbox UI for managing Users, Groups, and Permissions (keep in mind that adding permissions isn't very useful if the code doesn't reference them) * Visitor-facing UI for managing his profile * Visitor-facing UI for registration * Email validation of visitor registration (e.g. you register, TG emails you a confirmation, you reply, your account is activated) I'd be happy to work with (or advise more likely, because I don't have a lot of time these days) someone to make these things happen. -- Jeff Watkins http://newburyportion.com/ "Computers are like Old Testament gods; lots of rules and no mercy." -- Joseph Campbell --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---