Amusing JSON Details

I had a client practically teach me JSON in the middle of a functional design session yesterday. Yeah, you can't escape proper Tridion Content/Page Type analysis (a subset of Information Architecture or IA) without looking at markup, in this case it was in JSON rather than the typical XHTML, HTML, or XML (actually it will be HTML 5 escaped within a JSON string along with additional members).

Refreshingly familiar and easy-to-remember, I'm not sure why I didn't catch these amusing, memorable JSON details before:

• Objects have brackets, reminiscent of your first Hello World class in your favorite language.

  { }

• Arrays have straight brackets

  [ ]

• Members even have serial commas, the way I like (am accustomed to) them in prose. Though my Dutch colleagues might disagree.

Now, I'm curious if the team will produce XML that renders to JSON or use a (DWT) template building block for layout and the format. Luckily I'm just on the design side this round. :-)

Not always an Extension

Despite what you might find on Google, Tridion is not all about extensions. Consider implementing or configuring for the majority of your content management system functionality.

Update: Read an insightful follow-up from Robert Curlette on the history of Tridion extensions and their positive impact on projects.

Things I've seen customers or consultants wonder about:

• Default schema selection for components in a folder? Not an extension.
• Having such Linked Schema create the correct multimedia schema regardless of which component creation button is selected? Not an extension.
• Context menu show/hide dynamic changes according to security access controls? Not an extension.
• Filter author-entered rich text before component save? Not an extension.
• Change component markup to XML, (X)HTML, ASP.NET, JSP, PHP, Json, or some other text format? Not an extension.
• Have a component validate and update to its source schema? Not an extension, unless you want to automate this. :-)

You're Not Really a Tridionaut Until You've...

• experienced the 5 stages of Tridion.
• been schooled on StackOverflow or TridionWorld.
• extended the Content Manager. <cough>that's what she said!</cough>
• broken a Content Delivery install so badly you had to start over.
• added "check jars, dlls, jdbc, and configs" to your personal mantras.
• verified and logged a bug in the product (which, of course, rarely happens).
• been asked to train someone on a module you haven't had a chance to really use... tomorrow.
• started an intense exercise program such as triathlon training. Failing that, you likely earned and hopefully lost your "Tridion Ten/Twenty." (10kg or 20lbs) It's also called "consultant gut." :-(
• received Linked-In invites for contract/temporary/full-time employment for in a different state, region, or country for anything from half to twice your current income.
• lacked the time to really check Linked-In, think about your career, or even this blog. Quick, back to the ship, you've got websites/documentation/code/projects/tickets/random-Tridion work to create or break!

Safe travels as you launch from Tridion World into Tridion Space, fellow Tridionaut.

Other suggestions welcome, leave a comment and I'll add it to the list!

SDL Tridion Parent Publication Permissions Simplification

Here are some SDL Tridion patterns I like that fit a "don't overdo flexibility" mantra.

• Minimize content publications
• Minimize localization
• Make multiple schemas but reduce redundant work through embeddable schema
• Simplify selections by using Category and Keywords for text fields

Let's add one more: simplify permissions management. As promised, here's an implementation for a "brain-twisting requirement to manage permissions from a single parent publication." This can reduce the need to break inheritance or localize folders throughout the BluePrint and simplify your authorization model for the cost of some extra groups.

I really have to see and prove this out for more scenarios but so far this setup looks promising (i.e. test this out before going live).

1. Use default rights groups as parents (e.g. Author, Editor, Chief Editor)
2. Create subgroups for scope and permissions (e.g. Editor Global and Editor Local)
3. Set these as children of the default groups, with scope set to a specific publication (level)
• Editor Global is a member of Editor with 020 Content scope
• Editor Local is a member of Editor with 040 Website scope
4. Create "roll-up" groups such as All Authors and set these as children of the subgroups.

In your highest content publication, set folder permissions according to the following.

In this example, we want editors to see and edit components in this folder in 020 Content. Because the Editor Global membership scope to the Editor group is restricted to 020 Content,  both the Editor Global and its child group Editor All will have read and write permissions.

But we may not want editors write permissions in a lower publication. Because the Editor Local membership scope to the Editor group is restricted to 040 Createandbreak, both the Editor Local and its child group Editor All will have only read permissions.

For the "cost" of an additional roll-up group (and more subgroups, depending on how you handle scope versus permissions-based groups), you can:

• Manage most author permissions in fewer (a single publication if you create most folders in 020 Content) publications
• Set users to an "all" roll-up group and get combined publication scope and permissions--add a user to this group and they get the combined, yet separately managed, permissions, rights, and publication scope
• Have the flexibility to mix-and-match subgroups if needed

Reminder: only change the "All Publications" scope setting for the subgroup membership. Leave the user membership, the roll-up group membership, and the "available for setting permissions" set to "All Publications."
See update below.* Manage your unique changes, not everything. 

Now, anyone have some good tip on session and user management to test this all out?

Update: the full setup can include "ACL" groups for even read and write permissions across similar folders. Each time you set up a global folder, you could place it as part of (maybe a same-named) group for each. It's a bit extra work in the setup, but troubleshooting and managing this means you can add full sets of permissions just be adding/removing membership.

With an "ACL setup" you'd set "All Publications" for everything. But if only doing roll-up groups, you may need to adjust the scope membership settings as needed (e.g. the Editor All would belong to Editor Local with scope just set to the "Local" publication and so forth).