My CMS approach - good or bad?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

I ask all php-freaks say how they feel this CMS approach especially from the
point of view of 1) admin usability, 2) user rights management and) database

In my approach webcontent could be seen as a content-tree, where most of the
content would be in one table called "nodes". Content types would be:
- branchwebpages and simple categories(=menuitems that have only subitems,
not content) are the branches
- leafwebpages (those that don't grow forward), galleryimages and
documents(doc, pdf, rtf)  are the leaves

Would this one nodetable with its huge datafield(s) be too heavy,
remembering that other images than imagenodes would be in an other table?

In additon top this, there would be a general image bank and user image
bank and those images could be easily added to webpages ideally through
htmlarea or at least in "normal way" where images are placed automatically

If this approach could be  combined with a clever & natural permission
system (and some template thinking), i would see that possibility to replace
webpage management, event management, news management, public docs
management,  intranet management, image gallery and discussion forum with
one application, although it should be very safe in this case. But I am
ready to drop at least discussion forum and intranet management for security
reasons and to avoid developer exhaustion..!

Do You get what I mean:
- Superadmin can manage users, publish/add/edit/delete ANY nodes everywhere
BUT NOT change the type of the node nor the original author of the node.
- Editor can do same but not manage users.
- Writers can only publish/add/edit/delete their own nodes everywhere
- "Drafters" can only add/edit/delete their own nodes everywhere but not
publish them.
- "Discussers(?)" can only publish/add/edit/delete their own nodes UNDER
discussion nodes.
- "Photographers" can only publish/add/edit/delete their own nodes UNDER

Does this make sense? Are these mentioned roles reasonable? I see some
problem with person who is photographer and discusser, but not still enough
trusted to be a writer. First tree (superadmin, editor and writer) are
working well I guess, but others seem to be "component roles" of "content
provider". Let my try look this in bitwise system that many have mentioned:

define("SUPERADMIN",  1);
define("EDITOR",   2);
define("WRITER", 4);
define("DRAFTER", 8);
define("DISCUSSER", 16);
define("PHOTOGRAPHER", 32);

But now _relevant_ options would be:
1 superadmin
2 editor
4 writer
8 drafter
16 discusser
32 photographer
24 drafter + discusser
40 drafter + photographer
48 discusser + photographer
56 drafter + discusser+ photographer

Of course it is possible to break those rights to smaller peaces (like take
user management separately) but I am thinking, would it add complexity? But
then it's possible to keep that option in code level, while in application
level I could give only relevant options. Or should I provide even role
managent for superadmin? Job is increasing in size...

Site Timeline