Database Changes

Differences with the v3 schema are summarized in this table:

v3	v4
ExSite::SQL	ExSite::MySQL
section, page, content	content (with a type column)
content_data	revision, view
member	user
member_site_link	content_key
keyword, keyword_tag	deprecated, replaced with Index class and aliases

Notes:

section_id columns contain the content_id of a content record of type “section”. They might be replaced with content_id columns, if they can be related to something more specific than a section.
member_id has generally been replaced with UID.

DB Maps

DB maps now support a help column. This replaces the old help files in cgi/dbmap/help/table/column. These columns will be used to automatically add tooltips to your forms.

The enum: datatype works like a list: datatype, except that it returns an integer value instead of the text value. For example:

list:onoff on|off

returns text values of either "on" or "off".

enum:onoff 1:on|0:off

returns numeric values of 1 or 0, but displays text values of "on" or "off" to the user.

Attributes & Metadata

The attribute table (and ExSite::Attribute class) provides a generic metadata functionality, as in v3. This can be overloaded to provide a more dedicated/specialized metadata feature for specific tables or types of data. V4 has a few predefined specialized metadata tables/classes:

table	class	extends	notes
attribute	ExSite::Attribute	any table	used for preferences
metadata	ExSite::Metadata	content	see v4 Content Model document
contact_info	Modules::ID::ContactInfo	contact	contact information fields

Use/inherit the ObjectMeta class on the extended object to get these metadata features. When calling the new() or setup() methods of the extended object, you can optionally pass a metadata option to preload the metadata. This can save some database reads in cases where you already have the data handy:

my $article = new ExSite::Article(id=>456, data=>$article, metadata=>$article_metadata);

my $contact = new Modules::ID::Contact(id=>123, data=>$contact_record, metadata=>$contact_info);

Object Handling

As in v3, an ExSite object is a software representation of a database record. This all works similarly to v3, with some efficiency enhancements.

You can preload your objects with partial data if you have some of the record data handy. Simply pass your incomplete datahash to the data=> parameter in new(). If getdata() requests data that is already present, no database load is required. But it needs an efficient way to check whether it needs to load the full record if the data is not present. See ExSite::Content::getdata() and ExSite::Content::loaded() for an example implementation of this feature.

The ObjectMeta class also lets you preload metadata into your objects if you happen to have it handy, which can also save on database calls. Pass the metadata as a hash of key=>value pairs.

my $content = new ExSite::Content(data=>$cdata,metadata=>\%meta);

The ObjectList class will try to track metadata as well, if you provide it, and use this feature to preload object metadata when you pull objects out of the list. To push a record and its metadata onto the list, use:

$list->pushmeta($record,$metadata);  # one object

$list->pushmeta(\@records,\@metadata);   # multiple objects

Not all list operations will be able to preserve the metadata. In those cases, the metadata might get cleared, which will force it to be reloaded from the database.

Objects also support an unload() method that tries to drop internal attributes that are no longer needed. This is useful when looping over large data sets, to keep memory leaks under control.

When working with lists of content objects, extracting an object from the list will return a content subtype class, eg. a Blog object instead of a generic Content object.

Security

There are now 10 access levels:

#	old#	name	notes
0	0	public	unauthenticated visitor
1	1	user	authenticated user
2		member	official or paid member
3		site-defined	board members, committee leads, ... ???
4		site-defined
5		site-defined	reviewers/moderators ???
6		site-defined
7	2	manager	can perform all section-specific admin tasks
8	3	system administrator	can perform system-wide tasks, can make keys
9	4	root	all security rules disabled

Levels 0-4 are regular website visitors, permitted to use the website front-end. Levels 5-9 are executive users, permitted to access the website back-end. Levels 3-7 are undefined for now, and can be used for customizing local site privileges.

DB maps must be upgraded to reflect this. Code should not test for absolute levels, but for user types. For example:

is_admin (level 8+)
is_manager (level 7+)
is_executive (level 5+)
is_visitor (level 4 or lower)
is_member (level 2+)
is_user (level 1+)

Privacy settings and access controls are now numeric. A privacy/access level of 2, for instance, means that the viewer must be at least level 2 (an active member) to view the data or access the function.

Groups

You can create user groups using the security tools, and assign or remove arbitrary users to/from these groups.

Keys

Access keys can be assigned for any content object, not just sections. (However, sections remain the default way of partitioning security.)

Access keys can also be revoked for particular content. To do this, set the key type to “revoke” instead of “grant”. Revoked keys disable a certain type of access in that part of the site. For example, say user Admin has editorial permissions on the main section. But on a particular page, you revoke those editorial permissions. The admin user’s permissions will not extend to that page, or any below it.

Keys can be granted to individual users, or to groups. Group keys can be used by everyone in that group.

Security Roles

v3	v4
editor, designer, administrator	editor, designer, administrator, reviewer, owner

The reviewer role controls moderation and approval of submitted and draft content.When new content requires approval, the reviewers will be consulted first.

The owner role is for content that originates from non-executive users. (For example, a regular member could have permission to publish content that they owned, such as postings, profiles, etc.)

If the auth.view_keys config option is enabled, any key will grant access to view a content object. That would allow you to grant specific users or groups permission to view admin-only content, for instance.