SDL Tridion now ships with many of these (potential) features out of the box in the form of modules such as (Tridion) Outbound Email, Translation Manager, User Generated Content, and External Content Libraries. To be clear, these connectors are part of Tridion but may come with their own databases, APIs, and user or system accounts. You still need to configure and implement these to meet your project's needs.
SmartTarget is not Fredhopper, but rather the GUI elements, delployer features, and delivery-side code to make Fredhopper work with Content Manager Explorer and Content Delivery.
Even
publishing is separate from CM or CD. The Content Manager Explorer interface uses the Core Service except item publish status, which is updated by the publisher.
Connectors Have Users
When I first read the Tridion documentation (back when it was PDF'd and in folders by phases) I didn't understand all the need for user accounts for various services.
The server-side user accounts included tcmsystem, tcmworkflow, tcmsearch, and more. I have since realized that the granularity is important to security (or at least those that care about security). For example the user for Content Managent search probably shouldn't do much more than index the search collection and deliver results.
Tridion's authorization model (as complicated as it seems--Dominic Cronin has pointed out it was built the way awhile back to accommodate certain legacy setups) follows some familiar conventions (groups, rights, and permissions), but it doesn't exactly match other systems. When connecting with Media Manager, Fredhopper, managed translation (TMS, WorldServer, or Language Cloud), or even when publishing or doing workflow, Tridion uses a particular user.
Though you might want finer control, I've seen a few things:
- In many implementations I've seen, the customer will ask to elevate access to make a user be able to do things he or she normally can't. They want more access and an easier integration, rather than more authorization settings.
- The roles allowed to "do" publishing, send translations, pick media, or configure targeting typically own or are trusted with the other system. These tend to be the web publisher, language expert, media owner, or marketer (or marketing SME) that pretty much have full access to the other system.
- If most of my projects have authorization as one of the last things on the list (with good reason, it's hard to know what people will break or get stuck on without using it, also you need to set up sites before restricting what users can access), then finer-grained permissions for these connectors would be "phase 3" projects
The wife, a proposal writer familiar with sales and marketing software, even confirmed with, "Who cares about the types of permission being granted if the main part of the build isn't done?"
Thinking in terms of users explains other scenarios such as:
- In terms of authorization this means users that can see the external items can typically use them, publish them, or send them for translation.
- Rollback acts as the user and requires delete permissions, because a rollback could delete versions of items. The user matters.
- Translation just needs scope on the targets, not sources. You can create a job for any items you can see and you can send a job with items you may not have access to.
Resolutions
Resolving is probably the hardest Tridion functional topic. Add it to your New Year resolutions if you haven't already. Each setup might have a different preference, but Tridion's resolving rules are designed to "make it work." Once you have such a default, you get disagreements with the assumptions. Though I don't always see people wonder why those defaults are there in the first place.
In publishing the basic idea is items that use!your item are republished.
- Why? Because those other items might render your item.
- Why not? A more static content model that explicitly places content on lots of pages means a single item queues lots of other items.
In linking the basic idea is that the link resolves to the
closest component presentation.
- Why? Content and pages can be separated and links will just work regardless of where content lives.
- Why not? When content = pages = URLs, which is less of a reality today.
With translation, the owning item (nearest local or localized parent) is resolved except for items not-yet-translated. Duplicates are also removed so the translation job just includes the source items it needs for translators. Not yet translated means items under version 2.0.
- Why? Reduce duplicate translations and avoid translating items not yet translated.
- Why not? See below, but sometimes it's tempting to shortcut a BluePrint design and skip translation Publications. It's also hard to realize there's a difference for a given setup.
The (Can Only Translate) Version 2.0 Myth
I admit that I missed some of these resolving rules. I thought "link propagation" worked the other way around (it doesn't, that's because of our templates might publish linked items). Some might miss the proximity rules in dynamic linking. And for awhile there seemed to be a myth that you can only translate version 2.0 items or that workflow can't send minor versions.
The 2.0 only applies for localized items. Managed translation should have a BluePrint of source and target publications where managed translation "owns" (manages) the translations between sources on targets, which is the typical setup.
So if you want multiple source publications, then you need matching target publication sets (times the number of languages), otherwise the "Version 2.0 myth" applies. Either way, make this easier by limiting sources, hiding Publications, or using the Publication filters.
Two Users
Users in Tridion that own a minor (temporary) change are the only ones that can see those changes or publish them. To get minor versions to translation in workflow, the translation and workflow users must match. My colleague
Eric Huiza pointed this out to me, which helped inspire this post (thank the Huizard).
Update and implementation warning (March 4, 2015): matching identities will let you
send translation, but be careful with new items, especially in a reserved state (which are forced to wait for Bundle workflow) since their child items cannot
accept the translations until they are unlocked. One approach to avoid dealing with issues with receiving such translations is to automatically increment to a major version for new items.
Which brings us back to the point of this post--there is always a user. If you understand how users are related to authorization, versions, workflow, publishing, and any "new" Tridion connectors, then you've solved the second-most-important question:
who.
The first important question is
why, but as I've noted, we may not always agree or even consider with the why.
For more technical details on the user and system accounts for the modules and extensions mentioned, see this
Tridion Stack Exchange Q&A on user accounts. I'd also love to hear your favorite (or worse) "gotchas" when it comes to authorization, users/user accounts, or extensions/connectors.
