You can get this to work using a combination of the Rules module and the Content Access module, whereas the Rules module will automatically (behind the scenes) trigger the logic that's needed. The logic itself is entirely hidden for the user (author) and is equivalent to using the interface that you consider too complicated.
Here are some more details to get it to work:
Start from a rule that is similar to the example I included in my answer to "How to specify a Rules condition related to select list values?".
This sample rule uses a field named field_optionlist
, with 3 possible values A,B,C. In your case you could use any other fieldname (to fit your naming conventions). And your field only needs 2 values, say Y
(= yes, instead of A
) and N
(= no, instead of B
). Some more tips to get you going:
- Make sure to define this field (for your content type
news
) BEFORE importing the rule sample in item '1.' above (if not the import of the rule will fail).
- If you use another machine name for that field, also edit the field name in the sample rule before importing it.
- Adapt the Rules condition related to "value =
C
" to "value = Y
" (to fit your case), and the message included in the Rules Action.
QA-test the intermediate result after completing step '2.': you should have a Drupal message show up when a news
node is created with field value = Y
(and not when it is not Y
).
Use the integration of the Content Access module with the Rules module to create a Rules Action that updates the access of the node, similar to the Rules Action I included in my sample rule included in my answer to the question "How to revoke edit access to the node's author after publishing a node?". The actual settings to use for the content access module should match with the settings you seemed to already have tried (but which you consider as too complicated to have the node editor set them).
Refinement: if you really want a "checkmark" (instead of such yes/no selection field explained above), create a boolean field and rework the rule detailed above to use that field instead.
Bonus: if you ever need similar logic for another content type, just define the SAME field (with same machine name). After doing so, you should not have to change anything to the Rule as defined above. That's because of the "entity has field" condition ...