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).