HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


ocPortal Tutorial: Advanced ocPortal member system

Written by Chris Graham, ocProducts
This tutorial will cover some of the more advanced features of the OCF member system.



Birthdays

Unless disabled, member birthdays will be shown in the main_bottom_bar block (shown at the bottom of the forum, by default).
Additionally, members may choose to receive notifications for their friends birthdays, or the birthdays of all members.

If members have chosen to reveal their age, their age will show, otherwise not.
If members have not selected a date of birth, no birthday can show for them.

OCF contains a feature to automatically create/link-to a shared birthday topic for a member. By default, this is linked both from main_bottom_bar and the notifications.

The OCF_BIRTHDAY_LINK template controls how the main_bottom_bar birthday links will be shown.
You can change this to change what link is provided. For example, the ocGiftGiver addon replaces the topic link with a link to send an e-gifts.

The notifications are sent using these language strings, defined in the ocf language file:

Code

BIRTHDAY_NOTIFICATION_MAIL_SUBJECT=It's {2}'s birthday
BIRTHDAY_NOTIFICATION_MAIL=It's {{{2}}}'s birthday. Come congratulate them on {1}:\n{4}
BIRTHDAY_NOTIFICATION_MAIL takes these parameters:
  1. Your site name
  2. The username of the member whose birthday it is
  3. A URL to the member profile (not used by default)
  4. The URL to create/view the shared birthday topic for the member
  5. A member ID
  6. Base URL

Merging members

Thumbnail: Merging members

Merging members

The ability to merge members is only of occasional use, but when you find you do need it, it can be a great help. The usual situation is that one member gets 'bored', feels 'victimised', or wants to go 'undercover' (often, talking with their other account to 'hide the fact'), and creates themselves a second username. This may be a violation of your rules, depending which you have chosen, but is often annoying; it can usually easily be noticed just by seeing that two members have the same personality, spelling and language habits, usage patterns and IP address.

It is worth noting, that you should not be overly suspicious, as members who share some of the listed characteristics, may simply be family members in a household that shares an Internet connection.

The merge member feature will attempt to reassign everything attached (in any way) to the 'from' member to the 'to' member.
It is possible that some reassignments will not be possible, in which case, records may be dropped; for example, if both members share a secondary usergroup, ocPortal would fail [due to database key constraints] to assign both membership records to the same user, and hence drop one of them. You do not need to worry as this is handled automatically.

Custom profile fields

Thumbnail: Adding a custom profile field

Adding a custom profile field

The 'Custom Profile Fields' allow you to create new data fields to attach to member profiles. By default, an 'About me' field is included, and a number of hidden/locked/non-editable fields that store details relating to point counts, and staff-membership and role.

You can manage Custom Profile Fields from: Admin Zone > Tools > Members > the Custom Profile Fields icon.

Lists

For a list-type CPF, define the list by placing a '|' separated list in the default value field (e.g. "This|That|Other"). The first value in the list will be the default.
Thumbnail: Custom profile fields are edited by editing member profiles

Custom profile fields are edited by editing member profiles

There are a number of custom profile field options that you may set that allow CPFs to function for a number of different purposes, including:
  • Storing hidden details on member (for example, a list of rule infractions, such as to aid decisions on cumulative punishment)
  • Allowing members to specify details about themselves (for example, their occupation)
  • Forcing members to specify certain additional details (for example, on a forum for staff of a company, you could make members enter their job role, so as to reduce the chance of a non employee from joining and remaining an active member)
  • Allowing members of a certain sub-communities (via their usergroup) to specify details appropriate to that sub-community (for example, those in the 'Football' usergroup of a school discussion forum could specify the position they play, whilst those in the 'Music' usergroup could specify the instrument they play).

There is a 'Privacy' sub-tab in the account settings that allows members to limit access beyond this. If there are more than 15 CPFs it will only give them options for the CPFs they have filled in.

Thumbnail: Custom profile fields are optionally shown where members post

Custom profile fields are optionally shown where members post

A 'locked' custom profile field can not be edited or deleted.

Thumbnail: Custom profile fields are all shown in member profiles (those that the viewer has permission to view)

Custom profile fields are all shown in member profiles (those that the viewer has permission to view)

It is possible to configure where a value for a custom profile field for members will be displayed. The field will always be visible from their profile page, but also:
  • if 'show in posts' is selected, it will also be visible on their forum posts, and their member galleries and member gallery images/videos
  • if 'show in post previews' is selected, it will also be visible when displaying a member sub-gallery in a list of sub-galleries

If you have more than 60 textual CPFs (except Comcode ones), any ones created after the 60th will not be included for searching on the search module's member search form. This is due to a limitation in MySQL.
Additionally, you could run into problems with large numbers of CPFs on some servers. Some servers limit the number of request variables, either using a PHP setting, the unofficial Suhosin addon, or through other means that may not even be visible. If you notice field values disappearing, or WYSIWYG-edited fields showing in raw HTML after editing, it is likely caused by a server limitation.

Display rules

CPFs are pulled up according to the following set of rules:

PROFILE FIELD SETTINGS SHOWS IN FOLLOWING CIRCUMSTANCES
Owner viewableOwner settablePublicly viewableRequiredJoinAdmin add memberEdit own profileEdit others profileEdit others profile but has 'View any field' permissionView own profileView others profileView own or others profile but has 'View any field' permissionMember searchable

N

N

N

N

 

N

Y

N

N

Y

N

N

Y

N

N

N

N

Y

 

Y

Y

N

N

Y

N

N

Y

N

N

N

Y

N

 

N

Y

N

Y

Y

N

Y

Y

N

N

N

Y

Y

 

Y

Y

N

Y

Y

N

Y

Y

N

N

Y

N

N

 

N

Y

N

N

Y

N

N

Y

N

N

Y

N

Y

 

Y

Y

N

N

Y

N

N

Y

N

N

Y

Y

N

 

N

Y

N

Y

Y

N

Y

Y

N

N

Y

Y

Y

 

Y

Y

N

Y

Y

N

Y

Y

N

Y

N

N

N

 

N

Y

N

N

Y

Y

N

Y

N

Y

N

N

Y

 

Y

Y

N

N

Y

Y

N

Y

N

Y

N

Y

N

 

N

Y

N

Y

Y

Y

Y

Y

N

Y

N

Y

Y

 

Y

Y

N

Y

Y

Y

Y

Y

N

Y

Y

N

N

 

N

Y

Y

N

Y

Y

N

Y

Y

Y

Y

N

Y

 

Y

Y

Y

N

Y

Y

N

Y

Y

Y

Y

Y

N

 

N

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

 

Y

Y

Y

Y

Y

Y

Y

Y

Y



In addition, members may override display settings in their Account, on a per-field basis. They may choose to display fields:
  • Not at all
  • To members
  • To friends
  • To certain usergroups
  • To everyone

Encrypted CPFs

When creating a custom profile field, it is possible to mark it as encrypted. If you have the OpenSSL PHP extension installed and configured (see the Web Hosting for ocPortal tutorial), ocPortal can automatically encrypt the contents of such CPFs, such that their sensitive data would not be revealed if the server were to be compromised.

To mark a CPF as encrypted, tick the "Encryption" box when creating the field, making sure to first have encryption set up on your server and on ocPortal.

When editing the value of an encrypted CPF, the encrypted data will be shown. To change the value, simply overwrite it with the data you want to change it to. Leaving the value alone will not cause it to be doubly-encrypted.

When viewing an encrypted CPF on a member's profile page, the encrypted data will not be decrypted or shown. To decrypt and view the data, click the "Decrypt" JavaScript link for the CPF. A popup will allow the decryption passphrase to be entered and the data decrypted. The decryption passphrase is the passphrase used to unlock the private key, as specified when originally generating the public/private key pair. Typically only staff will have knowledge of the passphrase, since there's only one for the entire site.

Note that encrypted CPFs are not supported for any kind of CPF value that is not typed in (such as list selections).

Categorisation of CPFs

If you prefix CPF names like "Example: Field A" and "Example: Field B", ocPortal will be smart enough to treat this as a categorisation and render the join/edit-profile forms in a more appropriate way.

Special CPFs

ocPortal may install a number of special CPFs used for keeping hold of standardised user data. ocPortal's core set of profile settings is intentionally kept very narrow, and the special CPFs extend it, even for some core data. This both keeps our system lightweight, and also serves as a mechanism for us to store core data in third party forums.

To avoid user-interface-bloat, we automatically hide some of the special fields, if they are not currently in use. Typically this is when no addon needing them is installed.

Special CPFs include:
  • CPFs for tracking different sources of points (for example, how many ratings the member has made)
  • CPFs for holding address details (used by the shopping addon, passed through to PayPal, for example)
  • CPFs for holding payment details (if local payment is enabled, which is not a default-supported option by any bundled payment gateway, and should only be developed by programmers with a strong understanding of security and who will customise payment flow code as required)
  • CPFs for storing a list of what sites a member of staff is staff on (used if a multi-site-network has been configured)

All these CPFs may be edited just like any other CPF – as long as they are currently active (see above). One exception is the CPF title, which has to be edited via language string editing rather than on the CPF editing form.

By default the values of the CPFs are not publicly viewable.

Welcome E-mails

Thumbnail: Creating a welcome e-mail

Creating a welcome e-mail

ocPortal provides special support for composing a series of welcome e-mails that are sent out to new members on a predefined schedule.
The purpose of this feature is to gradually advertise the features of your website to your members in a way that reinforces awareness. As most members will not usually return to a website, welcome e-mails provide a strong tool to keep them aware and entice them to fully embrace whatever service you are providing.

For welcome e-mails to work the ocPortal cron bridge must be configured as discussed in the Configuration tutorial

Referencing member-specific data

As long as you have the newsletters addon installed, welcome emails will piggy-back off the newsletters templating code (regardless of whether the welcome email is being sent to members or to a newsletter). This functionality is as described in the newsletters tutorial ("Templated newsletters"); essentially it means you can use things like {name} in there.

CSV files

You can use CSV files to put member data into your website, or to export it. This functionality is available from the 'Tools' section of the Admin Zone. There is full support for auto-creation of usergroups and custom profile fields as required to get the data imported.

Implicit usergroups and external usergroup listings

ocPortal has support for 'implicit usergroups' which are usergroup memberships defined by custom code written by programmers. It is useful for using permissions for handling special circumstances. For example, a programmer could create an implicit usergroup for under 18's and remove the bypass-wordfilter permission for that usergroup.

In addition ocPortal can take usergroup memberships from LDAP.

Usually when ocPortal handles checks of when someone is in a usergroup it goes through some fool-proof methods to do it. However for performance sometimes it needs to get a full list of everyone in a usergroup without having to run a lot of calculations. In these situations only natural ocPortal usergroups are checked.
This said, ocPortal automatically syncs LDAP groups and ocPortal has a CRON hook (scheduler task) that is disabled by default that can be turned on by an OcCLE command to synchronise implicit usergroups as normal usergroup memberships:

Code

:set_value('implicit_usergroup_sync','1');
If this is set then anyone put into the usergroup manually that does not match the implicit usergroup check would end up being removed again.

If synching is not enabled, or group memberships come from LDAP, then the following things will not work as expected when it comes to them:
  • member search by usergroup
  • birthdays RSS feed filtering by usergroup
  • sending a newsletter to a usergroup
  • implicit memberships are not shown in exported CSV files
  • copying members from one usergroup to another
  • various areas of code that list all staff or super-members
  • signing up everyone in a usergroup for calendar event reminders
  • showing how many members there are in a usergroup
  • listing usergroup memberships when viewing a usergroup


See also