Make it possible to control access to form elements

This a great little patch. Is there any way we can move it into form_render, however? I'd like to see form_render turn into plain old render(), to be used with content arrays, link arrays, and more. the access flag would be a great built-in addition to all of those, not just forms...

In either case, though, a big +1. If necessary, this bit can be moved to the rendering function by a later patch when it's actually needed in non-form settings.

After talking to chx and Steven, I agree -- this is a building task, not a rendering task. +1.

code looks fine. do we have any use case for this in core or contrib? i suppose we could use this on the node form for admin stuff?

I think I have a use case: profile forms. These are currently either available or not. With this patch I could make them available based on user role or what I like. Great for social software like Drupal.

Cool patch! +1 from me. (Applying the patch doesn't make sense as it isn't used anywhere.)

There is still an issue with this patch: if you set #input is TRUE if the #type is value. Is it possible to inject values via a manipulated POST request despite #access being FALSE?

I should not move around parts of sentences without checking afterwards if the grammar is still correct ;-)

I would like to see one implementation in this patch. perhaps try the path.module field on the node form .. .also, what about fieldsets that have lots of protected fields. does developer ahve to set same access param on all of them. should we do a kind of inheritance like menu.module does? perhaps thats scope creep.

very needed, and very obvious =)

+1

   if (isset($form['#access']) && !$form['access']) {

isn't that supposed to be :

   if (isset($form['#access']) && !$form['#access']) {

chx last patch hasd a problem - it was possible to deny access to input fields but the corresponding fieldset was still visible. I moved the deny code up out of the input conditional and it seems to work. furthermore, you may now place #access on the fieldset and the interior fields are all omitted. @chx - please check my form.ionc change.

i went ahead and changed all the node form admin bits to use this mechanism instead of conditional form insertion. The node form is now not person specific, and all elements can be cached once once this one gets in: http://drupal.org/node/38798

I really like this patch, because a module can now use form_alter() to change the #access param to show/hide admin bits as needed. Now that these bits are in the $form definition, the module developer has lots of added power.

chx informs me that we must pass #access element to children like we do for #tree. patch attached.

I have some questions on this patch:

• Why is $posted undefined if #access => TRUE?
• Why is it still allowed to alter children that have #access => TRUE while the parent denies the access?

Updated the patch. Please review it. I can't guarantee that it's absolutely right what I've done.

No longer applies.

Rerolled against HEAD, hopefully I haven't made a mess...

Second time lucky...

Here's the re-rolled version with a three-line addition that makes the #access flag apply to rendering elements as well. This means that node rendering and (if moshe's patch to profiles goes through) profile rendering can use the same #access conventions for display as well.

This is, indeed, very cool.

I like this patch, but so far, the only thing it does is removing an if (user_access('foo')) test. Any by doing so, it makes Drupal a little bit slower. So, I'm still interested in one or more killer use-cases that demonstrate that a simple if-test around the form isn't up to the job ...

Any _relevant_ use cases? And why is this better than an if-test?

Dries:

One of the biggest use cases for this is that modules, using alter functions, can *impose* viewing/access restrictions on specific fields even if they are not inherent to the field. By adding conditional #access flags to a form, a node content array, or (with moshe's patch) the fields of a profile, site-specific, user-specific, etc access control schemes could be imposed without hacking core modules.

@Dries - IMO, the issue here is ease of use for developers. In their form_alter hooks, it is much easier to alter an element which is present than one that is not. For example, imagine a site that wants to let a certain class of users alter the sticky flag without 'administer nodes' perm. With this patch, the developer just has to set $form[options][sticky][#access] = TRUE in hook_form_alter(). He knows which element to change just by clicking on the tab in devel.module.

Without this patch, the developer has to inject the whole form element himself which means figuring out where it comes from. Before you know it, we have a frustrated developer. This is about improving learnability for developers. There are *many* developers who are good enough to alter an array element but not good enough to grok form submission particulars.

It's also important to note that this makes the presence or absence of a particular form element, field, etc something that is directly died to *user access* rather than a particular workflow. There are place, for example, that we conditionally build chunks of form based on whether the screen is in edit or add mode, whether a particular parent record has been chosen, etc, in addition to user access.

By making the structure of the forms the same regardless of user access -- but then embedding access info in the form itself -- we reduce the risk of confusion and bizarre form-building contortions in those complicated cases.

That's my feeling, at least. :)

+1 to the use case outlined by moshe @ #30

To use a specific example, a recent client wanted to control the order that a few nodes appeared on the front page. The quickest and easiest way to do this was to simply render the "Authored On" field and let users change the value. However, there are access controls hard-coded in node.module to prevent access to this field by anyone other than node administrators. So I had to make a new field with a custom submit function to update the $node->created date after the fact. Not the most intuitive thing.

With access controls on form elements, this would've been a one-liner.

i tried to inject a custom path when i was not permissioned to do so. my request was properly ignored. Various forms are behaving as expected ... RTBC.

Committed to CVS HEAD. Thanks.