Suggestion for GreenFuse (MODx Core User System and Tattoo)

Easy. Expand the roles function by one, and disable all of the manager functions by default. Have the default be "view front end" or something like that. The default Admin user of course will still have all permissions, but new "web" users by default will only have the "view front end" permission. Basically, a user will be a user, what will differentiate him will be his role permissions.

That would make it easier to control users, for example you could have user who can edit existing documents through QuickEdit, but not do anything else.

That would open up a whole new world of possibilities...move the back end into the front end, with features like QuickEdit, UserEdit, SystemAdmin, Etc. And the issue of themes for the back end is history!

@Ryan, thanks for pointintg that out.

I will go with what Susan says.

@Susan, it’s almost like what you said, except I will have 1 additional field on the user tables maybe, manager (0/1). All manager user will have a check box to set the user as manager or not. If it’s set to manager, than the site role for the manager will be enabled, if not, it will be left empty.

Hi Wendy,

Sorry for not posting sooner.

This is looking great. I also like the way how you handle the various data types or user attributes. This format will also be used in ContentFields (TV2).

If you can implement something like this for GreenFuse then that would be great!

From rough specs that I have the system will create a $cms->user object for all users. This means that you can be logged into the "web" - frontend context or "Manager" backend context or both with the same userd.

Quote from: xwisdom at Feb 27, 2006, 02:47 AM

Hi Wendy,

Sorry for not posting sooner.

This is looking great. I also like the way how you handle the various data types or user attributes. This format will also be used in ContentFields (TV2).

If you can implement something like this for GreenFuse then that would be great!

From rough specs that I have the system will create a $cms->user object for all users. This means that you can be logged into the "web" - frontend context or "Manager" backend context or both with the same userd.

<?php
// logs mary into the web frontend
$cms->user->login('mary','password',CMS_WEB);
?>

I like that idea Raymond. So all I need is to create User class, which will be called GreenFuse. My concern will be the multi fields and data types though. Do you think using ALTER sql statement will be compatible with most shared hosting MySql? By using my first approach, it can be handled just fine, but the processing cost is very2 expensive, considering you need to make multiple sql calls just to list several people. It works fabulous if I need only to list 1 user with all his/her attributes in detailed view, but it’s becoming cost ineffective, when I want to list several users with their details attributes.

Let me know if you think ALTER will do just fine, then I will go that way, by having a users_attributes table to be altered in whatever way the admin wants it to be, and the code will automatically adjust to the table alteration for the user attributes.

One more thing, Raymond, you’re aiming GreenFuse to be PHP4 compatible right? I’ve been experimenting with compatibility of some my OOP concept on PHP 4 and 5, so I’ll make sure that this will be compaible with OOP concept on PHP 4.

Sincerely,

Hi Wendy,

I guess that many of the ISPs out there allow users to create DB tables so Alter should not be a problem.

The concern I have with the ALTER approach is that attributes will cannot be shared accross tables. I think It’s also less flexible when changing datatypes.

One more thing, Raymond, you’re aiming GreenFuse to be PHP4 compatible right?

Yes, it will be PHP4 compatible.

Thanks for the input, but sharing attribute is not necessarily needed, even if we need to, we can use EXPLAIN to fetch the table column for users attribute table.

Considering about data changes,, that’s one of the thing that tick me of a bit, but I’m considering that the data being add to the database will not be altered, unless if the admin decide to remove the whole data set for that specific column and replace it with a new attribute data type that will be set empty to all the users.

I’ll see what I can do, basically the way it works is almost the same with catalog inventory management that I’m building right now.

Sincerely,