Answers.Body: <p>This is the expected behaviour. It makes perfect sense to display the human-friendly checkbox label on an admin screen, rather than the (potentially obtuse) checkbox value.</p>
  
  <p>To confirm that this isn't simply an issue with your form, I did the following:</p>
  
  <ol>
  <li>Created a test checkbox field with three options.</li>
  <li>Added the test checkbox field to the custom user fields.</li>
  <li>Set the checkbox field to display on the users list page.</li>
  <li>Edited a user via the control panel, and selected some of the checkbox items.</li>
  <li>Returned to the users list page to view the results.</li>
  </ol>
  
  <p>As expected, the users list page displayed the labels of the selected items.</p>
  
  <p>The only difference appears to be that in my installation the selected items are displayed in a single column, as a comma-delimited list, whereas in your example each checkbox item receives its own column.</p>
  
  <p>Here's a screenshot:</p>
  
  <p><a href="https://i.sstatic.net/rU7Ix.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/rU7Ix.png" alt="Screenshot of the users list"></a></p>
  
  <p>It's also worth mentioning that you are correct in stating that the checkbox option fields need to include the <code>[]</code> in the name. That's exactly how the admin forms work too.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-06T18:44:49.193Z
Answers.Text: Thanks Stephen. I have to disagree with this: "It makes perfect sense to display the human-friendly checkbox label on an admin screen" - in my scenario these are single checkboxes and to the admins it makes no sense as they think they are looking at data - you are on every other column. If the values were ones and zeros or more obtuse it might make sense.
Answers.UserDisplayName: joomkit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-06T19:10:40.460Z
Answers.Text: Fair enough. If you'd like this to change, you can make a suggestion on [the Craft UserVoice](https://craftcms.uservoice.com/forums/295386-commerce). In terms of your original question regarding whether this is a bug, though, no, it's not.
Answers.UserDisplayName: Stephen Lewis
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-29T17:30:26.587Z
Answers.Text: Feature requests have been moved from UserVoice to https://github.com/craftcms/cms/issues
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-06T00:57:42.747Z
Answers.LastActivityDate: 2017-05-06T00:57:42.747Z
Answers.UserDisplayName: Stephen Lewis
Answers.Body: <p><a href="https://craftcms.stackexchange.com/a/20378/57">Stephen's answer</a> is correct in that it's the default behavior.</p>
  
  <p>You could also write a simple <a href="https://pluginfactory.io" rel="nofollow noreferrer">plugin</a> that supplied it's own Checkbox field type that extended Craft's default implementation. It could override the <a href="https://github.com/pixelandtonic/Craft-Release/blob/master/app/fieldtypes/BaseOptionsFieldType.php#L209" rel="nofollow noreferrer"><code>getTableAttributeHtml()</code></a> method to return the values instead of the labels for element index pages.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-08T22:17:18.500Z
Answers.LastActivityDate: 2017-05-08T22:17:18.500Z
Answers.UserDisplayName: Brad Bell
Body: <p>I have some custom profile fields saved on registration in the front end.
  They are checkboxes and only submit on front end reg when they are set as an array. eg:</p>
  
  <pre><code>&lt;div class="checkbox"&gt;
      &lt;label&gt;
          &lt;input type="hidden" name="fields[phoneOptIn]" value=""&gt;
  
          {% set chbox = craft.fields.getFieldByHandle('phoneOptIn').getFieldType.options %}
  
          {% for option in chbox %}
              &lt;input type="checkbox" name="fields[phoneOptIn][]" value="{{ option.value }}"  tabindex="29"&gt;
              {{ option.label }}
          {% endfor %}
      &lt;/label&gt;
  &lt;/div&gt;
  </code></pre>
  
  <p>"fields[phoneOptIn][]" only works to save with "[]" in name.</p>
  
  <p>The problem in the CP user display is that when configuring to show the check box fields in the CP, the values of the checkboxes are not shown. What is displayed instead is the labels. eg:</p>
  
  <p><a href="https://i.sstatic.net/k2FL3.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/k2FL3.jpg" alt="labels not values shown in user profile fields in craftcms cp"></a></p>
  
  <p>Is this a bug? Really want to see values in backend not labels.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-28T22:12:12.913Z
Comments.Text: I can't tell where your screenshot is from in the CP... is that from a custom plugin?  Or maybe an element index page?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-29T21:56:36.907Z
Comments.Text: Thats from plain old users view with settings cog used to show checkbox profile fields
Comments.UserDisplayName: joomkit
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-05-03T19:55:12.293Z
Comments.Text: Any one got an answer as to why the recommended front end format results in lablels not values shown in profile fields in the user panel?
Comments.UserDisplayName: joomkit
Tags: <control-panel><user-profile>
Title: Checkbox profile fields front end show labels in cp
ThreadText: # Checkbox profile fields front end show labels in cp
  
  (Asked by: username_0 on 2017-04-28)
  
  I have some custom profile fields saved on registration in the front end.
  They are checkboxes and only submit on front end reg when they are set as an array. eg:
  
  ```
  <div class="checkbox">
      <label>
          <input type="hidden" name="fields[phoneOptIn]" value="">
  
          {% set chbox = craft.fields.getFieldByHandle('phoneOptIn').getFieldType.options %}
  
          {% for option in chbox %}
              <input type="checkbox" name="fields[phoneOptIn][]" value="{{ option.value }}"  tabindex="29">
              {{ option.label }}
          {% endfor %}
      </label>
  </div>
  
  ```
  
  "fields[phoneOptIn][]" only works to save with "[]" in name.
  
  The problem in the CP user display is that when configuring to show the check box fields in the CP, the values of the checkboxes are not shown. What is displayed instead is the labels. eg:
  
  [![labels not values shown in user profile fields in craftcms cp](https://i.sstatic.net/k2FL3.jpg)](https://i.sstatic.net/k2FL3.jpg)
  
  Is this a bug? Really want to see values in backend not labels.
  
  **Tags:** control-panel, user-profile
  
  > **Comments:**
  > **username_1**: I can't tell where your screenshot is from in the CP... is that from a custom plugin?  Or maybe an element index page?  
  > **username_0**: Thats from plain old users view with settings cog used to show checkbox profile fields  
  > **username_0**: Any one got an answer as to why the recommended front end format results in lablels not values shown in profile fields in the user panel?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-05-06. Score: 1
  
  This is the expected behaviour. It makes perfect sense to display the human-friendly checkbox label on an admin screen, rather than the (potentially obtuse) checkbox value.
  
  To confirm that this isn't simply an issue with your form, I did the following:
  
  1. Created a test checkbox field with three options.
  2. Added the test checkbox field to the custom user fields.
  3. Set the checkbox field to display on the users list page.
  4. Edited a user via the control panel, and selected some of the checkbox items.
  5. Returned to the users list page to view the results.
  
  As expected, the users list page displayed the labels of the selected items.
  
  The only difference appears to be that in my installation the selected items are displayed in a single column, as a comma-delimited list, whereas in your example each checkbox item receives its own column.
  
  Here's a screenshot:
  
  [![Screenshot of the users list](https://i.sstatic.net/rU7Ix.png)](https://i.sstatic.net/rU7Ix.png)
  
  It's also worth mentioning that you are correct in stating that the checkbox option fields need to include the `[]` in the name. That's exactly how the admin forms work too.
  
  > **Comments:**
  > **username_0**: Thanks username_2. I have to disagree with this: "It makes perfect sense to display the human-friendly checkbox label on an admin screen" - in my scenario these are single checkboxes and to the admins it makes no sense as they think they are looking at data - you are on every other column. If the values were ones and zeros or more obtuse it might make sense.  
  > **username_2**: Fair enough. If you'd like this to change, you can make a suggestion on [the Craft UserVoice](https://craftcms.uservoice.com/forums/295386-commerce). In terms of your original question regarding whether this is a bug, though, no, it's not.  
  > **username_1**: Feature requests have been moved from UserVoice to https://github.com/craftcms/cms/issues  
  
  ---
  
  ### Answer by username_1 on 2017-05-08. Score: 0
  
  [username_2's answer](https://craftcms.stackexchange.com/a/20378/57) is correct in that it's the default behavior.
  
  You could also write a simple [plugin](https://pluginfactory.io) that supplied it's own Checkbox field type that extended Craft's default implementation. It could override the [`getTableAttributeHtml()`](https://github.com/pixelandtonic/Craft-Release/blob/master/app/fieldtypes/BaseOptionsFieldType.php#L209) method to return the values instead of the labels for element index pages.
  
  
  ---
  
  