Built in roles

This is an open forum for any mojoPortal topics that don't fall into the other categories.

This thread is closed to new posts. You must sign in to post in the forums.
6/14/2007 7:01:37 AM
Gravatar
Total Posts 488

Built in roles

Initial data created during setup also contain some roles:

Admins
Role Admins
Content Administrators
Authenticated Users
Content Publishers
Content Authors

Which of them are built into the portal code and should not be deleted, and which ones can be deleted without any harm?

6/14/2007 1:43:44 PM
Gravatar
Total Posts 18439

Re: Built in roles

Admins, Content Administrators, and Authenticated Users are currently not allowed to be deleted. I might should add Role Admins to that group.

No error occurs if the user tries to delete them but they don't get deleted.

6/15/2007 4:18:49 AM
Gravatar
Total Posts 488

Re: Built in roles

1. According to Visual Studio search, "Content Authors" role is hard-coded in \Web\ClientScript\FCKeditor\editor\filemanager\browser\default\connectors\aspx\connector.aspx.cs (line 62). It is also used in dbPortal.cs, but commented out.

If this is not a system role, it would be nice to remove it from code (except setup, of course).

 

2. "Authenticated Users" is also a very strange role. According to search, except setup and commented out setup code in dbPortal.cs it is used:

    - in dbPortal.Role_Delete to prevent its deletion (but only in 2 data layers of 4!)

    - in Role.AddUserToDefaultRoles (used only from SiteUser.Create)

Is that just a technical role that all users should be in and exists only for the opportunity to set page permissions?

In this case it would be very nice either to hide it from all the "edit roles" interfaces (so that nooone can remove a user from this role) or delete this role and process "Authenticated Users" permissions in some other way.

 

3. As "Role Admins" has hard-coded logic depending on it, it would be nice to add it to "non-deletable roles" list.

 

P.S. Speaking about the coding solution, I think there are 2 ways to implement "non-deletable roles" in a way that their list is the same everywhere and easy to change in future:

    - add colum "issystem" to mp_roles table.

    - hardcode a list somewhere in mojoPortal.Business and add a check to the code calling dbPortal.Role_Delete so that it is not called for these roles.

6/15/2007 7:19:27 AM
Gravatar
Total Posts 18439

Re: Built in roles

The Authenticated Users role is so that it is easy to make pages in the content system that are only visible to authenticated users. Since pages already show or hide based on role membership this was more simple than adding another check for isAuthenticated. When new users are created they are automatically added to the authenticated users role.

I will consider these ideas for role implementation. If you would like to implement a new IsSystemRole column let me know. Otherwise, for the moment I will add the Role Admins to the non-deleteable role and make sure all data layers are consistent. In my view the current role sytem is decent and I would rather work on new features that will make mojoportal more popular then spend all my time polishing little things to perfection when they are already working well enough.

My time is my most precious resource and I must choose carefully how I spend it. If I fail in making mojoPortal popular then I will also fail in making a consulting business around it that can sustain me. If that happens then I will be back working in the corporate world with no time to work on mojoportal. I think at some point the popularity of mojoPortal will reach critical mass and I will no longer have to worry about the possibility of my new business failing but until we reach that point I have to be very strategic in what I spend my time on to advance the success of this project and my business. If I spin my wheels too much on little things I won't accomplish the big things.

Joe

6/15/2007 7:54:12 AM
Gravatar
Total Posts 18439

Re: Built in roles

Authenticated Users role is already prevented from being deleted and is consistent in all data layers. The only difference is 2 data layers use stored procs and 2 do not. Of course at he moment the SQLite data layer is completely broken so we really only have 3 working data layers.

Joe

6/18/2007 9:34:09 AM
Gravatar
Total Posts 68

Re: Built in roles

It would be better if all admin roles has the same name standard, preferably Administrators, Role Administrators, Content Administrators, especially for "DisplayName".

Christian

 

6/18/2007 11:56:13 AM
Gravatar
Total Posts 18439

Re: Built in roles

I will change the displayname, for backward compatibility I cannot change the RoleName.

Thanks,

Joe

6/19/2007 2:49:41 AM
Gravatar
Total Posts 68

Re: Built in roles

Thanks!

Christian

6/26/2007 11:45:17 PM
Gravatar
Total Posts 180
Thomas F. Heringer

Re: FCKeditor vs. TinyMCE

I am now using the most recent update and have found it to be a little easier to use, but at first I was a little confused when the top navigation moved over under my logo. After a little work I managed to get it straightened out. To me this is a good improvement and has helped. Following are some of the things I experience with the TinyMCE editor vs. FCKeditor. I have found that there are advantages to the FCKeditor that are superior to the TinyMCE but the visability of the TinyMCE is a lot better. For instance the font size selection in the FCKeditor is a lot better then in the TinyMCE. The FCKeditor on the skin I am using is black font on blue background and in order to make it work I go back and forth between the two. I set the size of the font in the FCKeditor and then switch back to the TinyMCE for the rest of my formating. I am sure that there must be among the CSS styles a place to change the color of the background for the FCKeditor without changeing the color on the pages.

You must sign in to post in the forums. This thread is closed to new posts.