5

I need to log the user who clicked publish on an item. I can't use an event system(technical restrictions), so I thought I would create a TBB which would simply write to a txt file during publishing. Getting the user, however, proved to be a bigger challenge than I thought.

I tried:

engine.GetSession().User.Title

And this works only when rendering in the template builder. During regular publishing I always get the user who started the publisher services.

PublishEngine.GetPublishInfo(item)

Is always one step behind and returns all but the current publish.

Am I missing something? Any help would be appreciated.

2 Answers 2

7

engine.GetSession().User returns the User for which the Session was created. So it definitely will not solve the issue.

I guess PublishEngine.GetPublishInfo(item) excludes the current publish because the current publish operation is still not finished.

But I guess publish transaction can help you getting the user title. You can try getting the publish transactions by:

       PublishTransaction publishTransaction = engine.PublishingContext.RenderContext.PublishTransaction ;

and then get the user title using this code:

publishTransaction.Creator.Title;

I havn't run the code though, I hope it helps.

2
  • PublishTransaction publishTransaction = engine.PublishingContext.RenderContext.PublishTransaction; is unfortunately not supported in 2009 .
    – Atila Sos
    Commented Apr 10, 2015 at 8:54
  • Yeah, you are right it's for 2013 Sp1. But I am sure we can find the current transaction in 2009 supported API and can use that. Commented Apr 10, 2015 at 11:59
4

Writing text files at publish time is really a bad idea. You will for starters have to set your Publisher to be single threaded, or run the risk of the text file to be updated by multiple publish actions at the same time (and failing with file locks). Also you rule out multiple Publisher machines (even if you would write the text file to a network location, multiple Publishers, still introduce the threading issue you forced upon yourself).

To get more on the topic, the Publisher is running under an impersonation account, since it requires full access to all items to render them correctly. Hence you will find that once an item is rendered by the Publisher, it is not the same user who scheduled the Publish Transaction.

Basically your only resort is to find the Publish Transaction that the current (rendered) item belongs to, you can see here how Mihai approached it http://yatb.mitza.net/2012/03/get-current-publish-transaction.html, but it remains a bit of a hack.

In your situation, you are really best of by using an event handler on the scheduling of the Publish Transaction. So explain to whomever is posing your technical restriction, that event handlers are a part of a Tridion implementation that should never just be ruled out for whatever (silly) reason.

Alternatively you could write a UI extension, to log the Publish action. However I would put my money on challenging the technical restriction, rather than spend too much time on trying alternative routes.

4
  • 4
    That "hack" was fixed in 2013 btw, you don't need to go around-in-circles as Mihai did anymore.
    – Nuno Linhares
    Commented Mar 31, 2015 at 10:36
  • @NunoLinhares thanks for sharing that this is fixed in 2013. We are using the "hack" to capture the current transaction using the item being rendered and then adding the user information to the package which we use later Commented Apr 1, 2015 at 3:53
  • 1
    +1 for the suggestion that solving the technical restrictions is the way to go. This job needs an events system. Commented Apr 2, 2015 at 19:17
  • Thanks for the answers and the deeper insight. The requester was advised to re-evaluate the event system approach
    – Atila Sos
    Commented Apr 10, 2015 at 8:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.