I set up nodewords, and came across an issue when using it with nodecomment, which replaces regular comments with full nodes.
I have set up two meta tag fields that should appear on node edit forms: keywords & descriptions. Now every user who can post nodes as comments can set description and keywords for the node, which he should not be able to. I can set a permission for "administer meta tags" but none for "set meta tags". I actually think this is crucial, but wonder if I am missing something, because in my opinion it is absolutely undesirable that everyone who can create a node is automatically able to set its meta tags.

Comments

chadwick wood’s picture

I totally agree... I'm looking for this option myself.

Anonymous’s picture

Title: Nodewords Permissions » Add "edit meta tag XYZ" permissions
Project: Nodewords: D6 Meta Tags » Extra meta tags modules
Version: 6.x-1.12-beta9 »
Component: User interface » Code

I am moving the report to the project that will implement this feature. There is already a permission module, but its code still needs to be expanded.

Anonymous’s picture

The module will actually implement the code to decide who can edit a meta tag, or not, but it will not expose additional permissions in the permissions page.

Narretz’s picture

Good to hear it's work in progress, thx!

Anonymous’s picture

Title: Add "edit meta tag XYZ" permissions » Add the settings to select which roles, and users can edit each meta tag

I am re-titling the report to make it clearer.

Witch’s picture

This issue is plaguing me too, i hope a solution will be found soon.

sf_wind’s picture

subscribe

Anonymous’s picture

Project: Extra meta tags modules » Nodewords: D6 Meta Tags
Version: » 6.x-1.x-dev

This project is not maintained anymore. It should be implemented in Nodewords.

gilgabar’s picture

This may not be a complete solution, but it resolved my immediate problem of having meta tag fields showing up for users who should not see them.

I added a permission for editing meta tags in nodewords.module:

<?php
function nodewords_perm() {
  return array('administer meta tags', 'edit meta tags');
}
?>

Then I added a user access check to the hook_form_alter that inserts the meta tag fields in nodewords_ui.module:

<?php
function nodewords_ui_form_alter(&$form, $form_state, $form_id) {
  $bool = (
    user_access('edit meta tags') &&
    isset($form['type']) &&
    isset($form['#node']) &&
    $form_id == $form['type']['#value'] . '_node_form'
  );
?>

I'm using 1.12-beta9 in case that is different from the dev version.

tinker’s picture

Thx Gilgabar. Patch working great on Nodewords 6.x-1.12-beta9. I think this is an essential feature.

danny englander’s picture

Subscribe

xjm’s picture

Status: Active » Needs review
StatusFileSize
new380 bytes
new307 bytes

Attached are patches implementing #9 (one for nodewords.module, and one for nodewords_ui.module; apply both).

xjm’s picture

Applying both patches in #12 and configuring the permission resolved the issue for me.

damienmckenna’s picture

Issue tags: +v6.x-1.12 blocker

Adding this to the v6.x-1.12 issue list.

dave reid’s picture

Assigned: Unassigned » dave reid

Yeah this is definitely needed. The fact that anyone that can add/edit nodes or edit their own profile can also edit meta tags on the page is a bad, bad, bad thing.

dave reid’s picture

Revised patch that adds a 'edit meta tags' permission and is used to control access to if users can view meta tag fieldset on node or account edit forms.

damienmckenna’s picture

Looks great - adds a much-needed improvement and cleans up the existing code in the process, good stuff!

dave reid’s picture

Status: Needs review » Fixed

BANG! Committed to CVS.
http://drupal.org/cvs?commit=444264

Feels good to have this long-standing issue finally fixed.

damienmckenna’s picture

I added a follow-up issue to expand upon this to control it per content type: #957860: Per-content type permission to control access to Nodewords fields for each content type

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

doublejosh’s picture

Does this not get checked for on the node edit form? I still see them as a user without this permission.

Perhaps the "administer meta tags" permissions is meant just for the global settings?

Anonymous’s picture

The administer meta tags permission is used to determine which users can access the administration pages for Nodewords; the permission Dave Reid is speaking of on #16 is edit meta tags.

doublejosh’s picture

Sorry, I get it. Dealing with anonymous users creating nodes, so this is extra poignant :)

damienmckenna’s picture

Status: Closed (fixed) » Needs work

Needs to be re-rolled against the latest 6.x-1.x codebase.

damienmckenna’s picture

Status: Needs work » Needs review
StatusFileSize
new14.43 KB

I re-rolled Dave Reid's patch from #16 against the latest 6.x-1.x codebase and ensured all hook_form_alter() and hook_form_FORM_ID_alter() changes are appropriately secured.

damienmckenna’s picture

StatusFileSize
new13.01 KB

Re-rolled against 6.x-1.x, again.

jwilson3’s picture

Status: Needs review » Needs work
+        if (user_access('administer meta tags') || user_access('edit meta tags')) {
+          $tags = nodewords_load_tags(NODEWORDS_TYPE_USER, $account->uid);
+            $form['nodewords'] = nodewords_form(

Indentation is slightly off, I think.

Not about to claim I know what all this patch does.. its a biggie!

xjm’s picture

Status: Needs work » Needs review

#27: I believe that is an illusion of the diff. The whitespace is different because an additional if () has been added.

damienmckenna’s picture

StatusFileSize
new13.05 KB

Updated. The logic for identifying if the user profile meta tags should be edited has been adjusted slightly, per the following comment:

    // Only show the meta tags fields if:
    // * This is the main 'account' profile edit tab,
    // * The user meta tags are enabled.
    // * The user has the main 'administer meta tags' permission
    //   OR the user has the 'edit meta tags' permission and is editing their
    //     own profile.

The question is - is this ok? Should it just be expanded to have a separate permission for each type meta tags, i.e. one for nodes, one for terms & one for users? Should the users tags functionality be changed to have one permission or option for deciding if a user can edit their own tags and something else to decide if a "manager"-style user can modify someone else's tags? Or should we instead just rely on the core 'administer users' permission to decide some of this? Answers on a postcard - what does everyone think?

damienmckenna’s picture

Title: Add the settings to select which roles, and users can edit each meta tag » Expand the Nodewords permissions to cover more granularity

I'm starting to think that the permissions need to follow Drupal core a little more closely:

  1. administer meta tags - control all Nodewords configuration and meta tags.
  2. administer content types (from Drupal) - change the default meta tags for each content type (see #945676: Allow defaults to be defined per content type and #1279864: Restructure tagging to be a series of hierarchies). I figured that if you're giving a user the permission to edit the content type that they should just have all permissions?
  3. edit any meta tags for [content type] nodes - change meta tags for any nodes of a given content type.
  4. edit own meta tags for [content type] nodes - change meta tags for nodes the user created of a given content type.
  5. administer taxonomy (from Drupal) - change the default meta tags for each vocabulary.
  6. edit meta tags for [vocabulary] terms - change meta tags for terms in a given vocabulary.
  7. edit meta tags for all users - change meta tags for any user.
  8. edit own user meta tags - change a user's own meta tags.

Right now we only have 'administer meta tags', so there's a long way to go.

Should we go that far with it?

Thoughts?

Status: Needs review » Needs work

The last submitted patch, nodewords-n823982-29.patch, failed testing.

damienmckenna’s picture

Issue tags: -v6.x-1.12 blocker

Not going to add this to the next release.

damienmckenna’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev

Bumping to v2, I just feel this will require too much API changes to be worth its while right now.

damienmckenna’s picture

Status: Needs work » Postponed

Marking all v2 issues as postponed while v1 is finished off.

damienmckenna’s picture

Assigned: dave reid » Unassigned
damienmckenna’s picture

Issue summary: View changes
Status: Postponed » Closed (won't fix)

Unfortunately this module is no longer supported, so I'm closing this issue.