Upgraded 2013 SP1 to SDL Web 8.1.1 - existing security model broken

Question

Background

Currently, we have a very stable environment in Production - version SDL Tridion 2013 SP1 HR1 with a fully-functioning nested (most complex permutation is 3 groups deep) security model.

For example, Advanced Producer is a member of Producer group and Producer is member of Read-Only group.

So there is a base Read-Only group; then another slightly more capable Producer group with W/R capabilities; then more advanced Producer group with W/R/L/D; and finally a group with only Translation Management enabled that each user is apart of explicitly, which is inherited only from Read-Only group.

Issue

So when I upgraded to SDL Web 8.1.1 release in a lower environment that has been previously restored from Production; and there have been no changes to the Production groups since restore..

When I go in as a Producer or Advanced Producer in newly upgraded 8.1.1 instance to smoke test/regression check our products, the existing security model - as it works today in Production, does not work as expected. Immediate differences would include opening a component and not having permission to read/view fields that is local to that publication or when trying to edit from Parent. We did our due diligence and compared permissions from upgraded instance vs. Production and indeed, they are identical.

Oracle Database Information

- 64-bit ODAC 12c Release 1 (12.1.0.1.0) for Windows x64 [Released August 13, 2013]

Question

Has there been any Security Model changes we need to be aware of with 8.1.1 upgrade/release? If indeed, this is a permission issue.. which seems to be the ghost I am chasing thus far.

Answer 1

The first thing I'd suggest with any such performance issue is to check that you have run the relevant database maintenance scripts: sp_updatestats and the like. (You haven't said which database you are using. I'd suggest you add this information, as it is relevant.)

Beyond that - if you think you have covered an undocumented breaking change (it sounds like that's what you are saying), then your very first option should be to contact support, and have their help in investigating the problem. I'd expect SDL to be very willing to help with this kind of issue, as if it indeed is a breaking change, this would give them the chance to deal with it proactively for all their other customers.

If you want to investigate for yourself whether there are any relevant changes, most of the logic is in the database, so you could read through the database upgrade scripts or compare the before and after versions of the relevant stored procedures, indices etc. That's probably a fairly big effort though, and you probably want to leave it to R&D. The best way you can help support/R&D is by creating some crystal clear test cases that demonstrate the problem