Styling the Backend!

[garvinhicking]

Hi!

It might be that the variable names are different! Try to add

Code: Select all

echo "<pre>" . print_r($group, true) . "</pre>";

within your foreach loop to see how it is called. It might be that 'name' is already substituted with the final Usergroup name, not the constant any longer.

Best regards,
Garvin

[Don Chambers]

It has already changed the name based on the language file, so since that is not constant, I cannot use it. So, I either need to do the comparison based on the database value, prior to translation (if that is possible), or I have to use the ID, unless you have a better idea:

Code: Select all

            if ( $group['id'] == 3 ) {
                $img = serendipity_getTemplateFile('admin/img/user_admin.png');
            } elseif ( $group['id'] == 2 ) {
                $img = serendipity_getTemplateFile('admin/img/user_chief.png');
            } else {
                $img = serendipity_getTemplateFile('admin/img/user_editor.png');
            }

[garvinhicking]

Hi!

Actually, now that I think about it: Giving the icon at that place is misleading, we should not do that.

The icons indicate the userLEVEL of a user, not the userGROUP! So if we mix'n'mojo groups and userlevels on the backend by using the same icon, this would lead users into not getting the difference between a userlevel and a usergroup?

Regards,
Garvin

[Don Chambers]

I'm not sure I follow you there Garvin. From the admin panel, when editing a user, is this notice regarding user level:

NOTICE: The userlevel attribute is now only used for backward compatibility to plugins and fallback authorisation. User privileges are now handled by group memberships!

I did, however, steal the idea from users.inc.php:

Code: Select all

        if ($user['userlevel'] < $serendipity['serendipityUserlevel'] || $user['authorid'] == $serendipity['authorid'] || $serendipity['serendipityUserlevel'] >= USERLEVEL_ADMIN ) {
            if ( $user['userlevel'] >= USERLEVEL_ADMIN ) {
                $img = serendipity_getTemplateFile('admin/img/user_admin.png');
            } elseif ( $user['userlevel'] >= USERLEVEL_CHIEF ) {
                $img = serendipity_getTemplateFile('admin/img/user_chief.png');
            } else {
                $img = serendipity_getTemplateFile('admin/img/user_editor.png');
            }

I still do not see it as terribly misleading. If anything, seems like the userlevel is where the confusion exists. Looks like there was previously a user level, equal to what s9y now has as its default groups.

Anyway, lemme know if you want me to ditch this as this addition was to be part of the changes I intend to send you.

[garvinhicking]

Hi!

Exactly! The images are meant for USERS, not for GROUPs. The image represents the userlevel, NOT the usergroup.

So that userlevel is seldomly used by s9y now and only indicates a global cateogirzation of a user and for older plugins. Which is why I think we should try to keep it as unique compared to groups as it can be.

Best regards,
Garvin

[Don Chambers]

Do you want me to poke through the Nuvola icon pack and see if I can come up with some suggestions for groups, or you think I should just shelve the entire concept of using icons for groups?

[garvinhicking]

Hi!

I personally would rather didch that. The proper way would be to define custom icons for usergroups, but that can't be done so terirbly easily, as it requires a new database column.

The reason is, you will later have many other usergroups apart from the default ones, and which icons would we use for those?

Best regards,
Garvin

[Don Chambers]

Yes - I suppose the the proper way to do it would be to allow the user to select ANY icon (perhaps from the media lib) and assign it to any particular group.

Well, it was an interesting learning experience. At least the edit and delete stuff is keepable. Back to an ealier question: Below are from entries.inc.php and are the 2 links shown for "Edit" and "Delete" for each entry on the "Edit Entries" page:

Code: Select all

<a href="?serendipity[action]=admin&serendipity[adminModule]=entries&serendipity[adminAction]=edit&serendipity[id]=<?php echo $entry['id']; ?>" title="<?php echo EDIT . ' #' . $entry['id']; ?>" class="serendipityIconLink"><img src="<?php echo serendipity_getTemplateFile('admin/img/edit.png'); ?>" alt="<?php echo EDIT; ?>" /><?php echo EDIT ?></a>

<a href="?<?php echo serendipity_setFormToken('url'); ?>&serendipity[action]=admin&serendipity[adminModule]=entries&serendipity[adminAction]=delete&serendipity[id]=<?php echo $entry['id']; ?>" title="<?php echo DELETE . ' #' . $entry['id']; ?>" class="serendipityIconLink"><img src="<?php echo serendipity_getTemplateFile('admin/img/delete.png'); ?>" alt="<?php echo DELETE; ?>" /><?php echo DELETE ?></a>

So why does the delete link have serendipity_SetFormToken and the edit link does not? And..... should I also use that same setFormToken for the delete link on Manage Users and Manage Groups? The existing text links on those pages do not currently use it.

[garvinhicking]

Hi!

Yes, maybe we can note this down for the future, to add custom group icons might be interesting.

The Token is only appended to the DELETE-Link, because that could immediately modify content. The EDIT-Link only leads to a page where an editform is present, it does not need to be secured. A token prevents XSRF, see http://en.wikipedia.org/wiki/Cross-site_request_forgery

HTH,
Garvin

[Don Chambers]

As mentioned, those 2 pages did not previously use the token on the delete link, but I will add it to my revisions.

You know, once upon a time I just happened to trip across s9y, and thought it might be interesting to use it for a very non-blog application.... I should have just shot myself right then rather than continuing to dig deeper and deeper in over my head!!

[garvinhicking]

Hi!

Ah, it might be that those delete-links also first show a "doorway" page before executing anything, so it might not be needed. Tokens are only required when an action is performed without user interaction. It also won't help to just add a token to a URL, because the functionality that performs an action also need to check it. So it might be that adding the link doesn't help anythin.

But please, include it in your patch, I will take care of this. Your help is much appreciated

Regards,
Garvin