Skip to:
Content

Opened 8 months ago

Last modified 6 months ago

#7483 reopened defect (bug)

Required xprofile fields are not validated

Reported by: rmichel0 Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8.2
Component: Extended Profile Keywords: needs-patch dev-feedback
Cc:

Description

There is an issue with the custom xprofile fields editing (replicated on http://demos.buddyboss.com/boss/) when following this steps:

  1. Set a xprofile field as required
  2. Edit your profile, empty the required field
  3. No error message is displayed, and the required field is saved empty

(you can try on the buddyboss demo by setting the bio field as required)

I saw that it was an issue that should have been fixed in 2.0:
https://buddypress.trac.wordpress.org/ticket/5595
But it still happen with the last version of Buddypress.

Change History (11)

#1 @hnla
8 months ago

  • Component changed from Core to Extended Profile
  • Keywords needs-patch dev-feedback added
  • Milestone changed from Awaiting Review to 2.9

Confirmed on a single site trunk install - changing an existing field to required, then editing the profile on frontend to a blank/empty field results in it being saved.

Probably needs further conditions checking.

This ticket was mentioned in Slack in #buddypress by hnla. View the logs.


8 months ago

This ticket was mentioned in Slack in #buddypress by hnla. View the logs.


8 months ago

#4 @henry.wright
8 months ago

Does the type of field matter or does this apply to all fields?

#5 @rmichel0
8 months ago

@henry.wright This apply to all fields I tested it for - text input fields, textarea fields. I didn't checked for other field types, but it seems to be a general issue with how the required fields are handled.

#6 @Mamaduka
7 months ago

This only happens when current user has 'bp_moderate' caps.

This is how we currently check, if field is required in xprofile_screen_edit_profile:

$is_required[ $field_id ] = xprofile_check_is_required_field( $field_id ) && ! bp_current_user_can( 'bp_moderate' );

This logic was introduced in r10232.

Last edited 7 months ago by Mamaduka (previous) (diff)

#7 @henry.wright
7 months ago

@Mamaduka in that case I guess this is a feature, rather than a bug?

#8 @Mamaduka
7 months ago

@henry.wright yeah. Looks like this was intended to be feature, but I find it confusing. E.g. when you add required field, lets say in Gravity Forms, it's required for everyone.

I think we'll see similar reports again, if we don't clarify different UX for users with 'bp_moderate'.

#9 @hnla
7 months ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing this then as a 'wontfix' as it's only a higher level user that can do this and not general users.

#10 @rmichel0
7 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I can't replicate the following assumption: "This only happens when current user has 'bp_moderate' caps.".
The bug occurs for regular user (with subscriber role). Not sure if it has been tested thoroughly and if this should really be set as wontfix.

Last edited 7 months ago by rmichel0 (previous) (diff)

#11 @hnla
6 months ago

@rmichel0 I have just run further checks and as a required field I cannot empty the input and save.

Logged in as a subscriber.
Filling in a field previously empty but required ( created subsequent to user joining ).
Returning to edit screen and attempting to empty the field and save results in error message that it's a required field.

Can we ensure this is tested with a plain vanilla setup, WP theme, no additional plugins, as you do state in the OP that this is seen running with BuddyBoss.

Note: See TracTickets for help on using tickets.