How to determine publishing user / access Engine in custom resolver

Question

To enable custom user preferences during publishing we would like to find out in the resolve step (inside a custom resolver) what the publishing user is (so not the user account configured for the Publisher service but the user that initiated the publish operation).

To find the original publishing user we would need to have access to the PublishTransaction object (specifically the Creator property); we cannot use the User property from the Session inside the custom resolver as this Session is created by the Publisher service (and would give us the service account).

To find the current PublishTransaction Mihai has provided us with an excellent hack. In essence; if we can get our hands on an Engine object we can determine the context publish transaction.

In our custom resolver the Resolve method is called with four parameters:

public void Resolve(
    IdentifiableObject item,
    ResolveInstruction instruction, 
    PublishContext context, 
    ISet<ResolvedItem> resolvedItems
) { }

• The item can be used to provide us with a Session object but neither an IdentifiableObject nor a Session hold a reference to the Engine.
• The resolve instruction is just a set of data properties for the resolve.
• The publish context (unfortunately not a PublishingContext) holds the publication and publication target only.
• A ResolvedItem can give us access to the Session again but not the Engine.

My question (finally) would be two-fold:
1. have I missed any potential points where the context user account can be determined from (other than the PublishTransaction)?
2. have I missed any potential points where the Engine can be determined from the parameters the IResolver.Resolve() method is being called with?

---

Edit: I realize I left out the broader picture on why we want to customize the publish activity with extra metadata (from user preferences) because it is a bit of a long story;

What I ultimately need is to activate for a specific version of a component in the component template (by walking up the version list and finding a version that is linked to a dedicated marker component) but in order to do that I need to know what the marker component is. For this reason we publish the marker component (which will resolve all linked components and ultimately pages) and the custom resolver allowed us to push the TCMURI of the marker component into the session cache (making it accessible in the CT).

Now we want to set a "preference" for a specific marker component at a user level to allow smaller batches of assets to be published within this marker context (as opposed to publishing everything linked to the marker at once).

Because the TBBs running inside the CT actually DO have an Engine object available, we can use Mihai's method and determine the publishing user (as opposed to pushing the marker context from the resolver what we initially did) and in this way bypass the issue completely.

I was wondering why there is such a difference in information availability between a resolve and a render operation; both are afterall part of the same publishing context. I cannot help but feel I'm overlooking something very basic but maybe I'm not and accessing a publishing context or engine from the resolver is simply impossible.

---

Edit: as presumed by Dominic and confirmed by Nuno there is no "Engine" at the time of resolving; as such this half of my question has been answered. That leaves

have I missed any potential points where the context user account can be determined from (other than the PublishTransaction)?

Answer 1

I went down this road before in a project (trying to get the user in a Resolver extension) and it was a world of pain.

I moved from a Resolver extension to a Render Extension, and even considered a Transport extension, just to go back to the simplest approach possible: a TBB.

Granted, my use case was different than yours, as it looks like you may want to change the resolving behavior based on the user (some users don't like link propagation, right? - if they're afraid of changing content, then they shouldn't change it ;-) ) but I ended up not implementing it that way.

I think there was an Enhancement Request to include more info about the user triggering publishing actions, but if that is implemented in the product it will be for Tridion 2013, not sure you can wait that long.