I have a requirement in my SMF 2.0.5 forum for a custom profile field that:
1. can only be seen by the profile owner; and
2. can only be edited by a forum admin.
To implement this functionality I made the following changes:
./Sources/Profile.php
Find
// If it's the owner they can see two types of private fields, regardless.
if ($memID == $user_info['id'])
$where .= $area == 'summary' ? ' AND private < 3' : ' AND (private = 0 OR private = 2)';
Replace with
// If it's the owner they can see three types of private fields, regardless.
if ($memID == $user_info['id'])
$where .= $area == 'summary' ? ' AND private != 3' : ' AND (private = 0 OR private = 2)';
./Themes/default/Admin.template.php
Find
<option value="3"', $context['field']['private'] == 3 ? ' selected="selected"' : '', '>', $txt['custom_edit_privacy_none'], '</option>
Add After
<option value="4"', $context['field']['private'] == 4 ? ' selected="selected"' : '', '>', $txt['custom_edit_privacy_admin'], '</option>
./Themes/default/languages/ManageSettings.english.php and ./Themes/default/languages/ManageSettings.english-utf8.php
Find
$txt['custom_edit_privacy_none'] = 'This field is only visible to admins';
Add After
$txt['custom_edit_privacy_admin'] = 'Owner can see this field; only admins can edit it.';
That looks fine to me, I don't think there should be any privacy leaks or untoward bugs with this, though I would prefer if the AND condition were changed to != instead of <>.
Note I haven't tested it myself but first glance it seems sane enough.
ZitatI don't think there should be any privacy leaks or untoward bugs with this
I've been using this modification for quite a few years - I originally implemented it with the Custom Profiles mod on a 1.1.x install.
ZitatI would prefer if the AND condition were changed to != instead of <>
I use '<>' in my own coding because, even though functionally equivalent, '!=" is not ISO compliant.
ZitatI've been using this modification for quite a few years - I originally implemented it with the Custom Profiles mod on a 1.1.x install.
That's great but as I'm sure you can understand I have to be wary about vouching for things here ;)
ZitatI use '<>' in my own coding because, even though functionally equivalent, '!=" is not ISO compliant.
Neither, particularly, are the systems supported by SMF. The main reason I pointed it out, though, is that SMF uses != itself in queries and in general modifications should be consistent with that, especially given the different backends supported by SMF some of whom may not support <> syntax (while there is known to be support for != in all supported backends)
ZitatSMF uses != itself in queries and in general modifications should be consistent with that
No problems and I understand with regards to consistency (I'm a stickler for consistency in my own work team) - I've changed the code I submitted to use '!='.
Thanks :) It also occurs to me that SMF 2.1 already supports extra stuff in the DB department than 2.0 does (offers MySQL/MySQLi, PGSQL, and both SQLite 2.8 and 3.0) and it is possible other things will be added in future.