WCI database Access Levels

If you’re a regular reader of this blog, you know we like getting under the Plumtree covers and figuring out what’s going on behind the scenes.  The ALUI databases are sometimes confusing – particularly the newer half-baked ones like the security database.  But the old legacy PT tables have undergone years of refinement, and every now and then show a well-thought-out design.

Today’s post is a quick lesson in binary math and how the ALUI security tables work. 

As you know, WebCenter Interaction object security includes READ/SELECT/EDIT/ADMIN privileges, and while there are some challenges to manipulating these security settings in the database (and some products to overcome the limitations), the underlying database structure is pretty straight-forward:  In tables like PTOBJECTSECURITY and PTCARDSECURITY you’ll find records that look like this:

While ObjectID, ClassID, and GroupID might be obvious in the context of the portal, AccessLevel is a bit-wise representation of the security level for that object, and contains either a 1, 3, 7, or 15.

Why these numbers?  Binary math.  Any number can be represented in binary (a base-2 numeric system) using bits; you’d represent the number 7 with a binary number of 0111, because:

Value: 8 4 2 1
Bit: 0 1 1 1

In other words: 8*0 + 4*1 + 2*1 + 1*1 = 7.

So if we look at the above table in the context of ALUI security privileges, EDIT access would be:

Bit: 0 1 1 1

i.e., a value of “7” in the database means “edit”, and you can calculate the values for the other privileges.  Interestingly, you can’t have EDIT privileges without having SELECT and READ (which is why you don’t see any values of, say, “4” in these tables). I wonder what would happen in the code if you manipulated the DB to give someone edit privileges WITHOUT giving them SELECT or READ? 

I guarantee this:  if you muck up this table, you are not going to get official support any time soon…

Tags: , ,

Leave a Reply