The profile entity should be used for fields that provide information about the user visible to other users. Meanwhile settings for the user themselves should be stored on the user entity.
In the profile refactoring of #3230125: Refactor profile field management and visibility this distinction becomes more strictly enforced because by default profile fields will show up for site managers and users for management of visibility.
It doesn't make sense to manage the visibility of the field "Allow members to follow me" since it's a settings field and not something to be shown on the profile.
The value of the field should not be updated programmatically but is managed by the experimental social_follow_user module. Similarly the SocialFollowUserHelper service should be used to read the current setting for a user.
These two things combined means we can transfer the create a field with storage on the user entity with the same settings as the currently existing field on the profile entity. After migrating existing user preferences from the profile to the user we can then delete the field on the profile. The code in the social_follow_user module is adjusted to read and store the value from the new field, calling could should not have to make any changes when correctly using SocialFollowUserHelper.
The field "field_profile_allow_following" on the profile entity is deleted and replaced by the field "field_allow_following" on the user entity.
Comments
Comment #2
tbsiqueira