I browsed through the code of field_tools_menu() and noticed that the access definition for /admin/reports/fields/ and below relies on the last result of the earlier loop over entity_get_info(). This is probably rather an oversight than by design (and present since 2012-09-02).

It seems to me that the field tools overview as well as the pages below would require either a custom permission or a combined permission check over all involved entity types/bundles (or a combination of both).

Comments

joachim’s picture

joachim CreditAttribution: joachim commented
Priority: Minor » Normal

IIRC, the pages we add below admin/reports/fields are all just reports -- there are no forms there that let you change anything. So it seems to me that the permission for these pages should be the same as for Core's page at admin/reports/fields itself.

I'll set this to normal priority, as I don't think access can ever be minor, but as this is a developer tools module and one that shouldn't be run on production, and only in alpha, it's not a major :)

ciss’s picture

ciss CreditAttribution: ciss commented

IIRC, the pages we add below admin/reports/fields are all just reports -- there are no forms there that let you change anything.

Not quite true, unfortunately:

  • "admin/reports/fields/field/%" lets you synchronize field instance settings.
  • "admin/reports/fields/field/%field_tools_field_menu/delete" allows you to delete field instances.
joachim’s picture

joachim CreditAttribution: joachim commented

Ah, thanks for the correction.

In which case, yes, we either need to define a new permission or add an access callback that checks ALL the permissions on ALL the entities. Both seem a bit faffy, as this module is really one that's meant to be used by uid 1. I'll sleep on it and see which I prefer! :)