Received a report from a user of a new site we developed with Toolset that when they tried to edit their profile and upload a new user photo, the fields of the CRED form were all for a different user (a separate member). We are concerned as we do not want member information to be available to other members.
Don't have a screenshot of it, but just a report of it happening 4 days ago (we were just notified).
"I tried to add a photo to my profile and it came up with (ANOTHER USER) in the fields. Very confusing as it was all there a moment before when I went to update my profile with the photo."
Any assistance to determine what could be the cause of this would be appreciated. Available for a video/phone call if necessary, and can provide backend access.
More information to hopefully help get this resolved....Use case is this: A User (Administrator or Member role) logins and sees a member dashboard. They can click on 'Edit Profile' which takes them to a page that has this the 'Update Profile Form' view within. Here, they will see a form allowing them to update their own user profile (some built-in wordpress fields, some additional custom user fields added from Toolset), for their user account only (only ever their User ID). After they submit, they get redirected to the membership dashboard.
Attached is a screenshot of the view that is being used -- is there an issue with the filtering here? If so, please advise on what I should have this set to. The user is always going to be logged in, and should only ever be able to edit their own user profile.
Well, the only thing that looks odd is that on your Update Profile page, instead of inserting the user form directly, you insert a View and add the form to the output section of that View.
From what I can see the View serves no purpose whatsoever.
Please delete the View and insert the shortcode for the form itself.
In that case the form should be editing the current logged in user.
Your Access settings only allow the form to be used for members to edit their own profile and not someone else's.
I can't account for what your user reports, but if there were to be a problem I suspect it would be related to your use of the View to host the form when that is not required.
Make the change, and then try a series of tests, logging in as different members.
We will be making the change shortly, and then give it some tests. We will let you know, although we never encountered this before going live.
We are inclined to believe the members report on this, because they did share the name of the other user they saw listed in the fields. Possible there is some edge case here that could be getting a bit of spotlight?
No other reports of this just yet, but, would it be possible to investigate from your end? Bit weary as we need to ensure privacy is upheld, so anything you and your team can find (if there is an edge case / bug with using this in a view) to help provide some relief would be appreciated.
The problem is in identifying the edge case. We need details to be able to reproduce the problem and identify the cause. We don't have any other reports of this, and it appears to be working normally. For a product like Toolset which can be used in a variety of ways within the broad WordPress ecosystem, we rely on our clients somewhat to find and report such edge cases.
You could try adding an activity logger that records everything which happens on your site, so that were it to happen again there might be some context available that would help identify why.
See this post, for example, for a description of such plugins: hidden link
