Tested it and it worked. The only thing which is missing when you create a new item and set the default value to allowed is that the "Calculated Setting" still shows not allowed. See my screenshot:

The calculated field is not updated until you save (read the notes).

As your screenshot shows you haven't entered a title (which is required)
you can't have saved yet.
On 11 Aug 2015 6:32 am, "laoneo" notifications@github.com wrote:

Tested it and it worked. The only thing which is missing when you create a
new item and set the default value to allowed is that the "Calculated
Setting" still shows not allowed. See my screenshot.
[image: access-allowed]
https://cloud.githubusercontent.com/assets/251072/9190882/269bf602-3ffb-11e5-879a-1ff7ee01d325.png

—
Reply to this email directly or view it on GitHub
#7517 (comment).

That's exactly what I wanted to show. If I set the default value to "Allowed" on a fresh new item, then IMO the calculated setting should reflect the actual state which is "Allowed" in that case.
Additionally if you set, for example the edit.state permission to "Allowed" in your component permissions for the "Registered" group. And you create a new item, then the "Registered" group has the "Allowed" setting and the calculated settings shows "Allowed" too. Despite the item was never saved. So the behavior should be the same I think.

As the notes state the calculated setting is ONLY updated on save. Logical
or not that is not related to this issue.
On 11 Aug 2015 6:59 am, "laoneo" notifications@github.com wrote:

That's exactly what I wanted to show. If I set the default value to
"Allowed" on a fresh new item, then IMO the calculated setting should
reflect the actual state which is "Allowed" in that case.
Additionally if you set, for example the edit.state permission to
"Allowed" in your component permissions for the "Registered" group. And you
create a new item, then the "Registered" group has the "Allowed" setting
and the calculated settings shows "Allowed" too. Despite the item was never
saved. So the behavior should be the same I think.

—
Reply to this email directly or view it on GitHub
#7517 (comment).

I'm not yet sure what the purpose of the default is.
First, it would be hardcoded by the developer in the XML, which imho makes no sense for an ACL.
Second, we already have kind of defaults implemented in the system. It's called inheritance, meaning by default it will take the values from either the parent or global level.
So for items, it doesn't make any sense at all, it should be inherit and take the permissions from the component level if not set otherwise.
For component ACL, there is a small usecase when the component uses an ACL rule which isn't available in the global config and for some reason that action should be allowed by default. Which usually doesn't make much sense.

I have rules in my new custom fields component which are not available in the global config. This rules should be by default "Allowed" for all groups. If an admin then wants to restrict permission for my custom rule then it can be done in the permissions.

@brianteeman but then all the fields should be on Calculated setting initially on "Not allowed". IMO it should be the same for all, or not?

@brianteeman but then all the fields should be on Calculated setting initially on "Not allowed". IMO it should be the same for all, or not?

In the case you have shown in the screenshot, all other actions are not allowed for registered users. Thus the calculated settings are actually correct.

In that screenshot yes, but here not:

I mean I can live with it, that the "Calculated Setting" is calculated on Save and doesn't respect the initial default value. It is only cosmetic.
@Test success

Tested it successfully

This PR does the default value only as a visual thing by pre-selecting the respective option in the select. If you want to have the calculated value as well, then you would have to do a bit more code than that.

Also when I look at the code, I think the default values are not used when calculating the actual value. So if you haven't saved the permissions yet, the default value isn't used at all. Which would be a major flaw in the PR.
Eg you use a default value for a rule in your component permission tab. As long as the component settings aren't saved, the action will be denied for anyone. As soon as you save the settings, the action will be allowed (if default is allowed).

I have rules in my new custom fields component which are not available in the global config. This rules should be by default "Allowed" for all groups. If an admin then wants to restrict permission for my custom rule then it can be done in the permissions.

That is the only usecase I can see. But it has a lot of flaws to it imho and is countering how our ACL works:

• The only default value that makes sense is "allowed", "inherit" would be default anyway and "denied" does exactly the same thing as "inherit" at this stage.
• If you set the action to "allowed" by default, it means that you basically turn of inheritance of the ACL. All child groups get a dedicated "allowed" as well, when they in fact should instead be inheriting that setting from the parent group.

I think there has to be a better approach to fix your issue with your fields. This one just feels wrong.
Maybe view levels (and setting it to public by default) is a better fit?

The only default value that makes sense is "allowed", "inherit" would be default anyway and "denied" does exactly the same thing as "inherit" at this stage.

Agree.

If you set the action to "allowed" by default, it means that you basically turn of inheritance of the ACL. All child groups get a dedicated "allowed" as well, when they in fact should instead be inheriting that setting from the parent group.

Think about a component which integrates the same way as com_categories (no own menu link in back end). If that component want's to add new rules, there is no way to set it globally. The admin has to go to every item and manually set it to allowed. What would be then the right way to add new rules in that way?

Maybe view levels (and setting it to public by default) is a better fit?

This would be an abuse of view levels as access levels are intended to be used to display stuff and not while editing.

What would be then the right way to add new rules in that way?

Maybe consider adding an own menu item for that component which allows setting component wide permissions?

This would be an abuse of view levels as access levels are intended to be used to display stuff and not while editing.

True

For the time being, I made my own rules form field to add the default value for the new rule. I hope that this PR will be merged as there are use cases when a default value makes sense.

For the time being, I made my own rules form field to add the default value for the new rule.

That is probably the best approach for this quite usecase specific request.

This request was not made for my specific use case. I've just tried to explain one use case. It was a coincident that @thongredweb made a PR which would solve my use case.

Any news about this feature?

Hello @thongredweb

Thank you for your contribution.

The last comment here was on 28th January 2016. So the question is, Is this issue/pull request still valid?
If no reply is received within 4 weeks we will close this issue.

Thanks for understanding!

Guess it didn't found much of acceptance.

Closed as stated above. It can always be re-opened if needed