Allow setting default value on field_domain_access

On point #1, not really. though you could delete the Domain field on the node type. I believe that would have the desired effect but have not tested it.

On point #2, You can set default values when configuring the field on each content type.

Some followup after reviewing the code:

* If the node is not assigned to a domain, it should receive the 'all' grant, which would make it accessible to any user who can access content.

* If you delete the field on some node types, let me know if you get error messages from DomainAccessManager::getAccessValues() or similar. Those are easily corrected. That method currently assumes that the field is present.

It seems that in 8.4 at least, the default value setting is not present. That's probably because we use a 'default value callback' to set the default to the current domain.

Ideally, we would remove that callback, and setting the default value to 'current domain' would happen by default. That's a little tricky to implement.

You could probably write a small piece of code to remove the default value callback from the field, and that would then allow you to set this value within the field configuration.

#4: Thanks for the guidance, so to know what was intentional and what just a quick fix.

Removing the default_value_callback from field_domain_access in fact enables the default setting.

Digging into the source, i guess it's not a good idea to add magick _current (or _all) values to referencable entities.

So a battle plan might look like:
1a) remove default_value_callback in domain_access_confirm_fields()
1b) ... and add an upgrade path for field storage
2) Move the current logic to hook_entity_prepare_form
3) deprecate the callback

In followups,

X1) Make the logic ("When creating a new entity, populate with active domain if required") configurable. (We may want to add other options like "Preselect all domains" there)
X2) Revisit the logic in domain_access_form_alter if still needed (to set value to all-domains if no field access)

Patch flying in that implements this.
Tested manually:
* upgrade path
* field default can be edited
* nonempty field default is used in node create form
* empty field default for required field leads to current domain used (BC)

EDIT: Ups, tests seem to be off for this project.

Confirmed that the patch in #8 works as expected! Thank you, great work.

I've been on vacation and will try to test this out before DrupalCON.

Multipatch flying in with one additional commit:
* Makes "add current domain" configurable/optional, including schema and upgrade path

Manually tested the setting and functionality on my box.

Nice work!

I think we would always set an empty value to the current domain, because that's the behavior in domain_access_node_access_records(). In essence, this field is always "required" in that it is set automatically for users without advanced permissions.

Because of that, I'm not sure we need the 3rd party settings?

> I'm not sure we need the 3rd party settings?

We have a use case for that: For some fields, we need a default value *and* additionally the current domain, for others, we only want the default value.

Moved a question about this to its own issue to not pollute this one: #3047514: Logic flaw in grants?

The patch in #11 does work for me. It respects the current domain and sets the default domain correctly. I wonder if it would be useful to have the option " Send to all affiliates" thus having the same options as on the node form?

> I wonder if it would be useful to have the option " Send to all affiliates" thus having the same options as on the node form?

Good point. Note that that is a separate field (the default of which just works).

Using #11. Works well. 👍

Queued for automated testing -- https://github.com/agentrickard/domain/pull/480

This patch also needs some tests of its own.

And a thorough review of existing tests, such as Drupal\Tests\domain_access\Functional\DomainAccessDefaultValueTest, which now fails.

I can confirm that patch #11 adds default value settings for domain access fields. (added screenshots)

Bumping.

Updated patch.

The test fail is due to the fact that on install, the module should set the "add_current_domain" value to TRUE.

That replicates the current behavior and matches the isRequired() logic in the patch.

The patch in #24 works for me. However, when I export the config for this field, only the option 'add the current domain' is saved in the config, not the actual domain (alias).

Re #25, 'add the current domain' is saved in config for all types on initial config export after patch applied -- fine.
I can then confirm that setting the defaults for a content type and exporting subsequently updates the config again as expected, and works.

@agentrickard thanks for the patch! #24 works for me.

Just one thing to double-check: Is it expected behavior that a user needs the "publish on any domain" permission for the auto-assignment to work on any domain? That's how the patch currently works. Or is that permission just for users that shall be able to explicitly set a specific permission, with the possibility to deselect the current domain?

edit: What the permission primarily does is showing/hiding the domain_access field in the form. On first sight, it seems plausible to me to exempt the auto-assignment from the permission.

Another aspect: The Add current domain to default values checkbox also appears on the user domain_access field setting, but when checked it does not auto assign users on creation.

Hi,
just testing this module for upcoming project.

Would be great if there is automatic default value for the user profiles, similarly as explained in #12.
With the provided patch I can see the extra checkbox, but it is not working for users.

latest patch, #24, used constant DOMAIN_ACCESS_FIELD instead of DomainAccessManagerInterface::DOMAIN_ACCESS_FIELD somewhere.
It gave me an error.

Marking patches as "needs review" will trigger tests.

I have a situation where I'd like some users to be allowed to publish content on a second domain, but have everyone go trough the "main" domain to create content.

Is it something that this patch would help to cover ?

Here's interdiff for 24 to 33, it does look like 24 incorrectly referred to a constant that wasn't defined.

This patch no longer applies

Attached is an updated patch for 2.0.0-beta2

can confirm that @johnjw59 's patch works on 2.0.0-beta2 and the Oct dev version.
It would be ideal to have an option to choose which domain to be the default, though.

Another reroll against 2.0.0-beta3 this time.

Unfortunately the patch contains two update hooks that are now in use by the project, so if you're updating the module and had previously installed this patch you'll need to reset the schema version to 8000 in "key_value" table before updating, patching and running DB updates.

Could we have a MR on 2.0.x please?

MR created.

This looks like a good candidate for beta4.

But we need some RTBC love for that.

I will provide a fix for the problem described in comment #29:

Another aspect: The Add current domain to default values checkbox also appears on the user domain_access field setting, but when checked it does not auto assign users on creation.

Looks like we simply need to handle the register operation.

Fix provided in issue #3564574: Add current domain option doesn't work when creating a new user.