Customizing SMF > SMF Coding Discussion

Add new data values to smf_members d-base table

(1/3) > >>

keyrocks:
Version:SMF 2.0.2
Developing: offline (localhost)

I've added three new data values to the smf_members table in my d-base.

Task 1: I want to add three fields to the Registration form, between username and e-mail and have the data from those fields saved to the smf_members table when a guest registers.

When the Admin reviews registrations waiting for approval, we click the link from the list to bring up the registrant's Profile panel and... if we're OK with the registration, we click the approve link and the registrant's account gets activated.

Task 2: I want to retrieve the three new data values from the smf_members table and have them shown on Profile and panel so I can review the information provided to see if it is correct. And, if it isn't correct and needs editing, I also need the same information visible and editable in the Modify Profile > Account Settings panel and have any changes updated to the smf_members table.

I am fairly comfortable working with PHP. However, being fairly new to SMF, I just need to know which functions in which files I need to modify in order to add the fields and which dbase queries need to be modified to add/update the new data values to the table.

I know... I could just add custom fields to the form from the admin panel, but I need these values in the smf_members table so that the three new values can be auto-updated with data from another database from time to time.

If anyone can help me with the two noted tasks, I would appreciate it. :)
Thanks.

Labradoodle-360:
If you are using SMF 2.0.x you can do this using Advanced Profile Fields without having to hack any code :)

keyrocks:
Thanks for the quick response Labradoodle-360.
Well, yes...  but not quite.
The Custom Profile Fields approach works sure enough.
However, the new fields are grouped below the default fields in the registration form, not where I want them to be, and their values are in the smf_custom_fields table.

As I noted, I would rather have the values located in the smf_members table. I would also want the new fields & values visible to, and editable by, the Admin only. In other words, they need to be invisible to the User so that the User cannot edit them later. Perhaps I should give you some more information to better explain what I need to accomplish.

I am developing my SMF project to be used as a Forums system for members of a political organization.
The organization has a proprietery, scratch-built, web-based, national membership registry (NMR) accessible only to the organization's official agents. It is located externally but on the same server network. The NMR contains (among other things):
1) each member's member ID (up to 9 digits),
2) the ID number of the geographical area (electoral district) in which the member resides (5 digits),
3) and the name of the geographical area.

So the three new fields are required in the registration panel to collect those three values during registration.
When an Admin approves a new account, the new User must be assigned to one of 340 Primary Membergroups.
The name of each Primary Membergroup is structured to match each electoral district's ID number and name:
Example: 45010 - Waterfield-Kilby Lane
... And the Admin would use the data provided by the registrant to quickly identify which Primary Membergroup to assign.

My eventual objective is to write a set of functions that will:
1) Connect with the organization's existing NMR,
2) Query the NMR to verify if the registrant's name, email, member ID and electoral ID exist in the NMR as provided,
3) Automatically activate the new account & assign the correct Primary membergroup if the data-check returns a postive match,
4) Hold the registration in the pending list for Admin review if the data-check does not return a positive match,
5) Send an auto-generated email to the registrant confirming that the account has been activated or that it is being held for further review, depending on the outcome of the NMR data-check.

If the above is achievable, my next objective will be to write another function-set that will also:
1) Check the NMR database to retrieve the User's organization membership expiry date,
2) Disable the User's account when the membership expiry date has passed (if not renewed),
3) Send an auto-generated email to the User noting that their User account has been disabled until their organization membership has been renewed,
4) And re-activate the User account when the organization membership has been renewed in the nmr database.

I know this will require a fair bit of work but, considering the organization's membership base runs anywhere from 75,000 (at the low end) to over 500,000  (at the high end)... the automation will alleviate a significant amount of manual account maintenance work for the SMF site's volunteer administrators.

Having all of the data located in the one table - smf_members - will mean that my new function-sets (yet to be written) would only need to retrieve data from one table rather than two in order to run the data-checks with the esternal NMR database.

I hope this makes it a bit more clear as to why I am adding the new data values to the smf_members table.  :)

Labradoodle-360:
What I'd suggest doing then is digging through the registration code, ./Themes/default/Register.template.php and ./Sources/Subs-Members.php (I believe)

keyrocks:
Thanks for narrowing it down for me. I appreciate it.  :)

Navigation

[0] Message Index

[#] Next page