Add profile weights / priority

I vote for use of the new role-weights module. I need to do the same for my path_access module too.

Tobia, I like your patch, that seems to make the most sense.

I'm not entirely sold on the role_weights module, so let's here some more thought on that. I'll commit a patch that fixes it once we decide :)

I have a patch posted here for what I think is the same problem:

http://drupal.org/node/66014

I took an even simpler approach- I just load the profile associated with the highest Role ID.

I think this will address 95% of the use cases, since it easily allows one to use different profiles for:

1. authenticated users
2. authenticated users with another role in addition

I'd appreciate your feedback on this approach.

I think that there is a real problem, and inluding one of these solutions in the module is important. I don't have particularly strong feelsings about which is the "best" solution.

This patch is a solution to this problem that I believe will be much more flexible.

I came across this problem when I was trying to have two tinymce profiles for the same role, one for a specific node-type that required less buttons and one for every other node-type. My patch allows as many profiles as needed per role and checks them all with _tinymce_page_match (visibility option in admin/settings). Only one profile should match and be displayed. If more or less than 1 profile matches, tinymce is disabled.

This allows users to configure profiles to be displayed by role-weights or node-types or ANYTHING else as defined in the Visibility options.

Just installed the patch file "profile_weight.patch_0.txt" and have to report that this is exactly what I wanted!

Thank you very much. Hopefully this will get into the main distribution.

andrewlevine, I like your patch the best, it is the most functional. I really hope your patch gets into the next release of TinyMCE because it fixes all the problems I've run into related to roles and profiles.

There is one minor problem that is more of an annoyance than a problem. I'll explain my setup first, so this is easier to understand.

I have a role called "writer", it is automatically an "authenticated user" because Drupal doesn't let you deselect that role for a user. I have two profiles setup, one for "authenticated user" and another for "writer"; the "writer" role has more TinyMCE features than the "authenticated user". Both of these roles need to be able to post comments using TinyMCE so I have configured them to show up on "comments/*" in the Visibility section.

Here's where the annoyance comes in. Since a "writer" is also an "authenticated user", the "More than one tinymce profile was configured to show on this page." message is displayed on the comments page. This message is irrelevant because the profiles are intended for two completely different sets of users.

It's my opinion that if a user has a custom role (a role that is not "anonymous user" or "authenticated user"), then the "authenticated user" role (and all profiles setup with no custom roles) should be ignored by TinyMCE's profiles for that user. This would ensure that the custom role user is always getting the proper profile and it would stop the message from appearing unnecessarily.

Thanks for the great patch, besides that one minor issue it's working great for me! Hopefully you or someone capable (I'm sure not) can fix up the custom role / "authenticated user" situation.

Nick

Yes, this problem needs to be fixed in some way- did you look at the extremely simple fixed I came up with: http://drupal.org/node/66014

NickHBO,

The best part of my patch is that you don't have to remember defaults or orders of roles. If you configure in the visibility options for two different profiles to both show up on the same page under the same conditions, that is wrong.

Here is what you would do with my patch (I haven't ran the code so there may be an error or two):

Put this under Visibility options in "Show if the PHP code returns TRUE" in the authenticated user tinymce profile:

global $user;
if ((strpos($_GET['q'], 'comments/')===0) && !in_array('writer', $user->roles)) {
  return TRUE;
}

This will prevent the profile from matching when the user has the writer role.

pwolanin, I did take a look at your patch but I didn't install it. From what I read, it seemed like your patch only handled picking the highest role number (for example "writer" [3] over "authenticated user" [2]) and had no way to determining what profile to use in the instance that one role had more than one profile (for different pages on the site, of course).

Having more than one profile is necessary if you want to have a "simple" profile for "writer" to use on comments/* and an "advanced" profile for "writer" to use on node/* - that's my full setup (I said I only had 2 profiles in my previous reply to keep the point concise). If your patch handles this case, I'll give it a shot as well.

andrewlevine, I tried that code in the Visibility settings (and made sure I changed the radio button to PHP), but it had no effect. The code produced no errors on the pages or in watchdog, it still showed the conflict error.

I realize that having two different roles show up on the same page under the same conditions is wrong. However, that's my whole point; it is not desirable to evaluate the "authenticated user" role if a user has a higher role. There is no way to remove the "authenticated user" role from users with custom roles and this leads to the error message showing when it does not have to.

I've got Profile 1 that is for "authenticated user" and it has very simple buttons; Profile 2 is for "writer" and it has additional buttons (thus why it is a separate profile). Each role needs to see their respective profile on the comments page (the second radio button and comments/* are set for each profile), but the error message will always be displayed because "writer" is also an "authenticated user".

That's the reason why I suggested ignoring "authenticated user" status when a custom role (anything >2?) exists, I can't think of a situation where you would want to take the "authenticated user" permissions over those you setup for a custom role.

I hope I'm communicating the issue clearly enough, it's a bit hard to explain with just words.

Nick

NickHBO,

The code I gave you not working and the problem of dealing with the authenticated role in general are two separate problems.

With the solution I have proposed the "authenticated role problem" does not exist. In my opinion adding more complexity in the form of defaults is counter-productive.

Whether my patch or code snippet has bugs is another question. I'd love to try to debug if you contact me via my contact page on this site (as I believe this is not the place for this). We can scratch each others backs.

NickHBO,

I just tested my patch and the code I gave you in a configuration similar to the one you described and it worked.

So I'm not sure what's wrong. Contact me through my contact form if you still need help.

While not a fix, a quick workaround for a simple scenario with only an 'advanced' and 'default' profile is to setup the advanced first then the default profile in drupal/admin/settings/tinymce/

Reporting: I just patched with andrewlevine's multiple_roles.patch.txt and used the visibility code provided. Everything seems to be working great. I'll report back with any problems.

Has anyone used these patches with the current 5.x-1.x-dev?

I haven't used the "multiple roles" patch but I have looked at the code. I still think it falls short. My usecase (and I think its a common one) is when you want the TinyMCE buttons to match up with your HTML filter rules. If you have a series of filter rules that are less and less restrictive, then you should be able to use the corresponding TinyMCE profile.

I don't know what the weighted roles module is but I don't think its necessary to have a dependency on another module. We just need a simple weight field similar to that used in many other modules. If multiple modules are associated with the user's role(s) then the one with the lowest weight is selected.

Darren has another approach that is similar: http://drupal.org/node/132198 -- what do ya'll think?

Let's consolidate our work in one place.

This issue is older. Marked mine as duplicate.

Better title.

IMHO this might be a show-stopper for custom Drupal setups, but basically it is a feature.

I'd say we already have the feature and it's not working. What's the use of profiles for roles if every user is using the authenticated user profile no matter what his role?

Here are my thoughts on this subject. There are two separate needs being addressed in this thread, both important:

1. "User belongs to more than one role. I want tinyMCE to show the user the profile associated with the highest-privileged role to which they belong."
2. "I want tinyMCE to show the user one profile when viewing Page A, and another profile when viewing Page B."

In my judgment, TinyMCE needs to recognize role weights, and without requiring another plugin. That, I think we all agree on here.

Here is my summary of the pros and cons of each approach so far:

1. Tobias's approach is the simplest and best solution so far. It allows you to "rank" importance of roles so tinyMCE accurately chooses which profile to present. In doing so, it doesn't break anything. My thoughts:
   • It requires an update and a new database field. No problem, just keep this in mind if you want to install the patch.
   • Addresses the following case: "User belongs to more than one role. I want tinyMCE to show the user the profile associated with the highest-privileged role to which they belong."
   • It does not address the following case: "I want tinyMCE to show the user one profile when viewing Page A, and another profile when viewing Page B."
2. pwolanin's approach needs to be ignored because it weights roles by their database ID number, which has no logical relationship to role importance--except (in default sites and some other sites) by complete coincidence. My thoughts:
   • Addresses the following case: "User belongs to more than one role. I want tinyMCE to show the user the profile associated with the highest-privileged role to which they belong."
   • Uses nonsensical logic to accomplish this.
   • It does not address the following case: "I want tinyMCE to show the user one profile when viewing Page A, and another profile when viewing Page B."
   • Hackers and module maintainers should ignore this one. Good for default sites or simple setups where it happens to work.
3. Andrewlevine's approach is to merely to override the module's conflict checks in order to allow you to have multiple conflicting profiles; in other words, gives you the freedom to shoot yourself in the foot if you're not careful. (Normally, the tinyMCE module won't LET you create two profiles for the same role. The default tinyMCE module will give you a "Not all user roles are shown since they already have tinymce profiles. You must first unassign profiles in order to add them to a new one" alert message, for example. The point is it does not allow it.) If you apply Adrewlevine's hack, you are now free to have multiple profiles per role; for example, you can create a "Simple Profile" for the Administrator role which has bold and italic buttons only, then create a "Complicated Profile" for the Administrator role which has bold, italic, and image insert. It is then UP TO YOU to make sure that in the Visibility settings for each profile, you enter whatever code prevents them from being demanded simultaneously. For example, you put comment/* under "Show on only the listed pages" for the "Simple Profile," and node/* under "Show on only the listed pages" for the "Complicated Profile." Now if you are an Administrator, you'll get the simple editor when commenting and the complicated one when adding a node. This will guarantee they won't conflict. But you are perfectly free to put in Visibility rules which do conflict, in which case you get an error message and no tinyMCE editor shows up at all on that page! Therefore, andrewlevine's solution is merely a workaround. Here are my thoughts on it:
   • Addresses the following case: "User belongs to more than one role. I want tinyMCE to show the user the profile associated with the highest-privileged role to which they belong." But only by using convoluted code in the Visibility section. So it POORLY addresses this.
   • Addresses the following case: "I want tinyMCE to show the user one profile when viewing Page A, and another profile when viewing Page B." Does this very well, but requires manual customization of each profile.
   • Produces too much room for error to be a part of the module itself, and fails in an ugly way.
   • Patch fails in 5.x-1.x-dev anyway, because the code has changed.
   • There is a particularly nasty bug in that $profile_name is never set in function tinymce_process_textarea! In many cases, no tinyMCE is loaded at all an no error message thrown.
   • Summary: Addresses a serious need but does so in a non-user-friendly way which is difficult to administer, and code is not updated for latest tinymce module anyway and is buggy to boot. Avoid.
4. flanderz: your desire to have TinyMCE match with the input filter is common but another issue entirely, outside the scope of this discussion. It is highly problematic to associate filters with tinyMCE settings because you can change filters on the fly. What happens when you check "Full HTML" after editing for a while in "Filtered HTML"? Does TinyMCE suddenly react and add buttons? You see what I mean.

My conclusion?

This issue remains UNSOLVED. In the meantime, Tobias's solution is a solid one which I believe the maintainers should roll into the module right away because it is a non-destructive improvement.

However, ultimately, the solution this module needs is one which successfully addresses both of the following needs:

1. Addresses the following case: "User belongs to more than one role. I want tinyMCE to show the user the profile associated with the highest-privileged role to which they belong."
2. Addresses the following case: "I want tinyMCE to show the user one profile when viewing Page A, and another profile when viewing Page B."

It occurs to me that this would require a very good interface; I propose a separate primary-task tab. I propose that you detach the access and visibility settings from profiles and have them managed separately.

So you'd have "TinyMCE settings" page, an the first (and default) tab would be "Profiles." Then the second tab would be "Access." The "Profiles" tab would look very much like it does now--but when you edit a Profile, there are no longer select boxes for roles or a Visibility box. All of that would be moved to the "Access" page.

Under "Access," you would have a list of the Profiles you've created, each as a collapsible fieldset you click on to expand. So if you created a Profile called "Site Editor," you'd click on it, expand it, and see a bunch of form options. For each profile you would see:

1. First would be a master "Weight" dropdown to manage collisions between profiles on the same page. More on that later.
2. Second would be a list of all roles, each role with a Weight box. (In this way, you could apply different role weights to different profiles! Very nice.) It would also have a checkbox for whether or not to display the Profile for that role. This takes care of the "User belongs to more than one role. I want tinyMCE to show the user the profile associated with the highest-privileged role to which they belong" issue.
3. Third would be a Visibility section (perhaps in its own collapsible sub-fieldset) where you type the visibility settings. Here is where you could put in your custom PHP code for displaying different profiles on different pages! This takes care of the "I want tinyMCE to show the user one profile when viewing Page A, and another profile when viewing Page B" issue.

Because Profiles are detached from Access, you can apply profiles at will to roles and pages, regardless of multiple types assigned to the same role. To manage profile collision (a problem that ultimately dooms andrewlevine's solution), each profile on the Access page would have its own weight, as specified in point one above. So when a page is loaded which had two profiles set for the same user level, it picks the one with the lower weight! This would allow for some pretty complicated setups without ever breaking.

(To make all this work easier, you could have a "duplicate" or "clone" link next to each profile, so you can quickly fill up profiles and apply them to different pages on the Access tab.)

This would also allow for future expandability, in case you wanted to add more complicated rules to the "Access" page, such as only showing the tinymce editor on one textarea but not to another on the same page.

That's my proposal!

Let me try a simpler approach for this issue:

- Profiles differ in the amount of features TinyMCE offers.
- The problem here is, that a user with more permissions gets a profile intended for users with lesser permissions.
- Profile weights are nasty.

Instead of weighting profiles, weighting roles or sorting after ids, we want to get the profile with the maximum amount of features for a specific user.

Thus, why don't we count the number of enabled plugins in a profile, save this count for each profile in the database and add ORDER BY plugin_count DESC?

Subscribing.

I like the suggestion except that it's too complex, and the number of options in the "Access" tab are likely to confuse people. Can I suggest two possible solutions:

- that item 2 on the tab is dropped, as changing the weighting under specific circumstances is the same as making the demoted profiles not visible under those circumstances. Or make item 3 return a weighting rather than visible / not-visible.

or

- the Profiles have two separate sets of information in them, those that affect TinyMCE's behaviour and integration with other modules and those that affect the button's etc. available. These need to be controlled separately. The buttons etc. are "additive" in the sense that you can create a basic profile and then add more features as people are either more expert or more trusted. The behaviour and integration stuff tends to be about how the site is set up, so less likely to change in different circumstances.

Hello everyone,

This is a great thread. Thanks to everyone for their hard work.

I am attempting to patch the most recent development snapshot of TinyMCE via Tobias' patch in comment #4. I first attempted the patch on the most recent stable release, 5.x-1.9. Attempting the patch of both resulted in patch errors.

Please excuse me if this is obvious, but can someone recommend an approach to patch the most recent version of the TinyMCE module with this patch?

Many thanks...

I've been running the patch in http://drupal.org/node/132198#comment-534721 for about a year now on a dev release of TinyMCE for many sites without a single issue. I can't/won't upgrade to the latest version (1.9) as this breaks the patch. I suppose that's what you get for using patches, but it's the only solution that nicely addresses the very common case of a user with multiple roles being randomly shown a less featureful TinyMCE interface than intended, which is a common "show-stopper" (hence change to bug report and critical).

When is this problem going to be addressed in a release? This has been an issue for about 2 years now...

I'm unassigning it from Tobias as his last post on this was 9 months ago, he's not in the developer list, and perhaps having no-one assigned will get some attention. :P

http://drupal.org/node/181798#comment-792447

husztisanyi: you're the best!!!

But, this still a bug for developers!!!!

#27 has been implemented in Wysiwyg Editor module now. (see http://drupal.org/cvs?commit=120098)

Also, I've posted an updated version of the patch in http://drupal.org/node/132198#comment-534721 for tinyMCE 5.x-1.9 at http://drupal.org/node/132198#comment-1181848

This is no longer needed, since the overall approach of defining multiple, unrelated profiles was wrong. Please read the announcement on http://drupal.org/project/tinymce and upgrade to http://drupal.org/project/wysiwyg

[oops, put this in the wrong issue. deleting]