og_audience field should be locked

I don’t recommend locking the og_audience field in our case.

While it’s an important default that OG creates when no other og_standard_reference fields exist — and definitely useful for new OG installs — our situation is different. We're migrating from Drupal 7 and already have several specifically named og_standard_reference fields in use. In our case, og_audience has been deleted and is not part of the current architecture.

Locking it could prevent us from removing or editing the instance/widget settings — for example, to use custom selection handlers. That gives me pause, especially considering the underlying ambiguity around the meaning and enforcement of “locked” in core config entities. Some relevant issues:

• 📌 Clarify what 'locked' means for a config entity and whether it's okay for code to rely on a locked config entity existing Active
• 🐛 Locked fields can change the widget but not settings Needs work
• 🐛 Do not allow to alter Locked field via UI Needs work
• 🐛 Locking field.storage should not lock field instance settings (field.field) Active

What problem or motivation is behind the request to lock it? Or are you assuming some of the issues above are unlikely to ever be resolved? I believe (though haven’t tested) that removing locked fields via config import might still be possible under current behaviour, but if some of those issues above are resolved that may not be the case in the future.

Well, really, I think it should be a code bundle field, but I figured that might be too big a change.

It needs to be something that can't get deleted by accident, surely, since the module won't work properly without it.

Yeah, I agree — OG requires at least one og_standard_reference field on group content to function properly.

How about: what if we instead throw a warning on the Field UI and/or Status page if a group content bundle doesn't have any og_standard_reference field defined? That way we’d catch real misconfigurations regardless of field name, without assuming a specific implementation or locking down unused fields.

That could provide the safety you’re looking for, while still keeping things flexible for cases like ours where the field exists under different names due to migration history (or other pedantic reasons).

> regardless of field name, without assuming a specific implementation or locking down unused fields.

👍

I don't think migration is a good reason to keep this sort of flexibility.

Renaming fields during a migration is a one-time problem. Once it's done, it's over and the complexity of the migration is gone from the system.

But Having OG need to detect a field of the right type is permanent complexity in the system.

The issue is that you can have one or multiple OG audience fields, but there's no hardcoded 'og_audience' name. It's just a default.

In that regard, it's similar to any entity reference fields. If you accidentally delete those, you'll also lose functionality. Or @joachim, do you have anything else in mind?