How does ElevatePrivileges work

Question

As mentioned in this answer on ElevatePrivileges and described in the docs, ElevatePrivileges lets you temporarily elevate the privileges of the current user.

I believe this was meant to let item version history reflect the user a given action was performed "on behalf of." Was that the main use case?

I have questions on the the method.

1. Is ElevatePrivileges only available in the CoreService?
2. Any restrictions or gotchas for using it in CM-side code like workflow, event system, or templating?
3. Does it only apply in the context of a given CoreService "session?" In other words, would a user connected to the Content Manager be "elevated" outside of code that calls ElevatePrivileges (I'm thinking no)?
4. Is the elevation to a specific user/group or just to an "administrative" level?
5. Do the Privileges feature in SDL Web Cloud and Web 8.5 affect ElevatePrivileges?
6. And out of curiosity, what happens if you don't call RestorePrivileges after using ElevatePrivileges?

Answer 1

Indeed, one of the advantages of using privilege elevation instead of using a sysadmin account in order to do things that the original user may not be allowed to do is that the actions are still performed in name of the original user. So that, for example, the original user name shows up in a history list.

Another advantage is that you don't have to configure a sysadmin account name (or full credentials).

Now onto your questions:

1. The functionality is available in Core Service and TOM.NET API (like everything else: the Core Service is a web service on top of the TOM.NET API). In TOM.NET, you can use a ElevatedPrivilegesScope object for that pupose; similar usage pattern as TransactionScope in .NET Framework.
2. Note that Automated Workflow Activities are executed by a sysadmin account (typically: SYSTEM) anyways, so no need to elevate privileges there. Template code also already runs with elevated privileges, but in a special mode called Trusted read-only mode. This means that the code can read everything, but not change anything. You should not try to let your template code change the state of the system.
3. Privilege elevation indeed only applies to the Session you perform it on.
4. You can elevate to any privilege. Up till SDL Web 8.5 (?), the only privilege that existed was System Administrator. Nowadays there are more granular privileges.
5. Yes, see 4.
6. The privilege elevation will remain intact till the end of the Session.