Use the same permission as CCK for the HS config form for a field

Nice find!

I'll happily welcome and commit your patch :)

Hm, I went a bit insane with this and tried doing it like content_menu did it (define a menu entry for each field/content_type). Had to add in an additional hook implementation (content_fieldapi) to ensure that menu is rebuilt.

If this is a bit too much, there was also two additional issues. The menu entry was using the wrong permission (administer site configuration instead of administer content types) and there was no checking that the item was a hierarchical select item since any field, typename is accepted (solved by only having menu entries for the necessary fields/content types).

WOW. I appreciate your contribution, but that's an extremely overkill solution. A simple string replace will do.

http://drupal.org/cvs?commit=281970

Ah, I see it now and see where some of most of my road block came from:
There's an not needed line in hs_taxonomy_form()

I managed to comeptly not realize that that was an unused, uninitialized variable.

It'd be nice if hs_taxonomy could be weighted at the same level as taxonomy would be, which would have avoided some of issue since most taxonomy modules expect to run after taxonomy, but i8ntaxonomy remaking of the taxonomy array proves problematic to do. Of course, could weight i8ntaxonomy below hs_taxonomy..

That was necessary due to #475784: #options set by forum module, this causes a validation error. What you could do, is change the weight back to 1 and then unset #options from within HS itself, at the end of the #process callback.

But please discuss that in #601500: HS Taxonomy interaction with other modules (content_taxonomy, unhides taxonomy fields)! :)

(Oops, I meant to post in that one. And got reaally confused when I didn't see my last post till looked over at this issue).

Anyhow looked at the commit; there's two other issues I noticed while doing above, sorry for not mentioning them more clearly; I think the hs config form doesn't check if the field is a hs widget so would show for invalid fields and the permission does not match the regular field form permission, though I can't imagine someone with administer content types but not administer site configuration.

I think the hs config form doesn't check if the field is a hs widget so would show for invalid fields

Indeed, but that can't hurt. To do that, you'd have to actually manufacture such an URL. I'll gladly accept patches to fix that though, but not in the way you wrote it (i.e. adding menu callbacks), it should work using _load() functions that verify the existence dynamically.

permission does not match the regular field form permission, though I can't imagine someone with administer content types but not administer site configuration.

Exact same answer as above :)

Attached is the permission change.

Not bothering with the other one; it'd need a different access callback that checks on content type/field permission or something

If you want to see something quite funny, try adding drupal_not_found to a hs_content_taxonomy_config_form . It puts the entire not found page inside the the $content of the page sorta.

Committed. http://drupal.org/cvs?commit=282150

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