You are a coding God among mortal men!
Perfect.
I love this software.
Haha. I don't know about that, but I'm happy to help.
One other tip I do to make the database more readable on things like that. I always do 0 and 1 instead of 1 and 2. 0 always means off or no. 1 always means on or yes. I title the db accordingly so...
if the column is private
1 would mean yes, private
if it's public
1 would mean yes, public
It doesn't seem like a big deal, but 6 months from now it saves you from having to go back in the code and figure out what's what.
Good point. I'm not actually sure why I chose that way, other than the fact I was already trying to figure out a three-state status for a direct debit process ('no action' = 0, 'clicked link' = 1, 'direct debit confirmed' = 2). Guess it just stuck.
As a matter of interest, would I need to make any modifications to make that button work within the context of a list (for example, the view_all_users list) so that he button was repeated in each row and only acted on the associated record? Or would the necessary coding make the lights go dim? I'm not used to working with lists.
The thing you'd have to change if you're in a list is that you'd have to pass in the user's id into the form itself. If it's just something that the admin is going to use, you could do input hidden with a name of userid and a value of the user's id. If that's something end users will see, you don't want to do that because they could use the chrome inspector to change the value of the hidden input.
This would only be done in the context of an approved admin role carrying out a triage of applicants, for example assessing the information supplied when joining and applying a permission setting of 'not eligible', 'consultant' or 'associate trainee'. It is not something that a normal user would ever see.
Right. So the idea of just putting the user id in as a hidden form field on that same form would be fine. Then just grab the user id from the $_POST instead of $user->data and you'll be good to go.
