author | schlatterbeck <schlatterbeck@57a73879-2fb5-44c3-a270-3262357dd7e2> | |
Tue, 15 Dec 2009 15:11:27 +0000 (15:11 +0000) | ||
committer | schlatterbeck <schlatterbeck@57a73879-2fb5-44c3-a270-3262357dd7e2> | |
Tue, 15 Dec 2009 15:11:27 +0000 (15:11 +0000) | ||
commit | e4e6bd39dd9b34aad8ee06bade09376ea1683846 | |
tree | 46cb8ac006ed504e3f79ec038dc7b05cad8309fb | tree | snapshot |
parent | d80196b6ae3019bf7c78a2f70298386336648166 | commit | diff |
Clean up all the places where role processing occurs. This is now in a
central place in hyperdb.Class and is used consistently throughout.
This also means now a template can override the way role processing
occurs (e.g. for elaborate permission schemes). Thanks to intevation
for funding the change.
Note: On first glance the hyperdb.Class may not be the ideal place for
role processing. On second thought: Roles may appear in other classes,
too (e.g., a user_group or similar) which then don't need to reinvent
the wheel. And I didn't want to introduce a separate UserClass (as is
the case for the HTML classes) due to compatibility issues with existing
schema.py out there.
git-svn-id: http://svn.roundup-tracker.org/svnroot/roundup/roundup/trunk@4410 57a73879-2fb5-44c3-a270-3262357dd7e2
central place in hyperdb.Class and is used consistently throughout.
This also means now a template can override the way role processing
occurs (e.g. for elaborate permission schemes). Thanks to intevation
for funding the change.
Note: On first glance the hyperdb.Class may not be the ideal place for
role processing. On second thought: Roles may appear in other classes,
too (e.g., a user_group or similar) which then don't need to reinvent
the wheel. And I didn't want to introduce a separate UserClass (as is
the case for the HTML classes) due to compatibility issues with existing
schema.py out there.
git-svn-id: http://svn.roundup-tracker.org/svnroot/roundup/roundup/trunk@4410 57a73879-2fb5-44c3-a270-3262357dd7e2