Default 'bp_xprofile_change_field_visibility' cap check passes

[r-a-y]

Reported here:
​https://buddypress.org/support/topic/profile-field-visibility-enforced-but-members-can-override/

If an admin has enabled 'Enforce field visibility' for a profile field, in v2.4.0, the "Change" link still shows up when a user attempts to edit the profile field.

The problem is due to the bp_current_user_can() modifications that were made in #6501 (my fault!) and how we do capability argument checks for the 'bp_xprofile_change_field_visibility' cap.

The 'bp_xprofile_change_field_visibility' cap checks if a specific capability argument is valid with isset( $args[0] ). In BP 2.3.4, this would fail; in BP 2.4.0, this passes since $args[0] is now an empty array and not null.

I've attached a patch that fixes this with a unit test.

[DJPaul]

Not tested but looks ok

[dcavins]

@r-a-y This change works for me and is much more clever than what I was thinking of doing (changing the isset()s to isset() && ! empty()s). Good catch.

[r-a-y]

In 10376:

Caps: Fix issue with passing an empty array as an argument in bp_current_user_can().

Changes to bp_current_user_can() in #6501 broke older capability checks
relying on an empty argument to be passed in order to use a fallback value.

Most notably, bp_current_user_can('bp_xprofile_change_field_visibility' )
checks now passed by default. This resulted in the "Change" link to
always be visible when editing a profile field even if an admin has enabled
"Enforce field visibility" for that particular field.

This commit fixes this issue by passing a null value if there are no
extra arguments to pass in bp_current_user_can(). Commit also includes
a unit test.

See #6730 (2.4-branch).

[r-a-y]

In 10377:

Caps: Fix issue with passing an empty array as an argument in bp_current_user_can().

Changes to bp_current_user_can() in #6501 broke older capability checks
relying on an empty argument to be passed in order to use a fallback value.

Most notably, bp_current_user_can('bp_xprofile_change_field_visibility' )
checks now passed by default. This resulted in the "Change" link to
always be visible when editing a profile field even if an admin has enabled
"Enforce field visibility" for that particular field.

This commit fixes this issue by passing a null value if there are no
extra arguments to pass in bp_current_user_can(). Commit also includes
a unit test.

See #6730 (trunk).

[r-a-y]

Thanks for testing, @dcavins!

Closing this one.