ee1c7959 Changed the custom field modal to open a field to members with a switch
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
A publisher deciding what members may do with a custom field chose between
three levels in a select: staff only, members can view, members can edit. In
practice the decision is one question, whether members maintain this field
themselves, and the three-way control asked more than that while hiding the
one fact that matters when the answer changes: how many people will see it.
The modal now asks it as the newsletter modal asks its own opt-in question: a
switch labelled "Visible to members", with a sentence beneath saying how many
members can see and update the field from their Portal account settings, and,
when a field that was staff-only is opened, that anything already recorded
becomes visible to them. The list says so in the row's subtitle, after the
field's type, the way the staff list carries a fact about a person under
their name; on active fields only, since an archived field is closed whatever
its setting says.
The view-only level stays in the API. A field already at it shows as open,
says that members can see but not change it, saves untouched when only its
name changes, and returns to view-only if the switch is turned off and on
again, rather than being upgraded to editable on the way. 4d9cea19 Changed the custom field modal to open a field to members with a switch
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
A publisher deciding what members may do with a custom field chose between
three levels in a select: staff only, members can view, members can edit. In
practice the decision is one question, whether members maintain this field
themselves, and the three-way control asked more than that while hiding the
one fact that matters when the answer changes: how many people will see it.
The modal now asks it as the newsletter modal asks its own opt-in question: a
switch labelled "Visible to members", with a sentence beneath saying how many
members can see and update the field from their Portal account settings, and,
when a field that was staff-only is opened, that anything already recorded
becomes visible to them. The list marks an open field with a badge, on active
fields only, since an archived field is closed whatever its setting says.
The view-only level stays in the API. A field already at it shows as open,
says that members can see but not change it, saves untouched when only its
name changes, and returns to view-only if the switch is turned off and on
again, rather than being upgraded to editable on the way. 16e7907a Changed the custom field modal to open a field to members with a switch
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
A publisher deciding what members may do with a custom field chose between
three levels in a select: staff only, members can view, members can edit. In
practice the decision is one question, whether members maintain this field
themselves, and the three-way control asked more than that while hiding the
one fact that matters when the answer changes: how many people will see it.
The modal now asks it as the newsletter modal asks its own opt-in question: a
switch labelled "Visible to members", with a sentence beneath saying how many
members can see and update the field from their Portal account settings, and,
when a field that was staff-only is opened, that anything already recorded
becomes visible to them. The list marks an open field with a badge, on active
fields only, since an archived field is closed whatever its setting says.
The view-only level stays in the API. A field already at it shows as open,
says that members can see but not change it, saves untouched when only its
name changes, and returns to view-only if the switch is turned off and on
again, rather than being upgraded to editable on the way.