OpenWGA 7.10 - OpenWGA Concepts and Features

Design and development » WebTML » Features » Actions

Master sessions and actions

OpenWGA knows special user sessions called master sessions. These sessions are executed under unlimited user rights.

When a master session is used from WebTML it generally is executed in a parallel process. This is neccessary to temporarily use different rights while still maintaining the current database sessions. This however has some drawbacks:

  • Fewer functionalities are available to master sessions than to the WebTML page or script that calls them. So access to all browser and WebTML page related information is not available. Look for the section "Available on:" on each functionality in the TMLScript reference to see if it is available in master actions or other types of scripts.
  • Also the information about the current user is not directly available. However there are special metadata fields of name "original_user*" which give you information in master sessions about the user that triggered its creation.
  • Data changes done in master sessions may not be directly available to the session that called the master functionality. It may be necessary to reopen the current database session to view those changes on the current user session. See below for more information.

In OpenWGA design it is possible to execute special code under these rights, for example using master actions. An action is simply determined as master action by setting the attribute master of its <tml:action> tag to "true".

Note the following example of an action that allows users deleting the current context document, even if they have no rights for document deletion in ACL.

<tml:action id="deleteDoc" master="true">



An alternative to master actions are master functions and methods. They can be defined and called inside a script which generally is executed under normal user rights. This is quite handy if some of the operations you need to do need master rights while other operations need to run under the original user session. They can be called using methods WGA.Master.runFunction() and WGA.Master.runMethod().

Note the following example where a document is saved in a master function - which may not be allowed for the current user - and then redirects the user browser to a different URL, which in turn is not possible on a separate master session.


  function() {





As stated above it may be neccessary to reopen the current database session after a master functionality was called to see the modifications that were done there. This is done automatically by OpenwGA when a master action is called directly from an action link on a WebTML page. It needs to be done manually in every other situation. Use the method WGA.reopenSessions() to perform this.

See the following, a bit more complicated but quite practice-oriented, example on session reopening:

<tml:action id="createDoc">

var newDocKey = WGA.Master.runFunction(

  function(form) {

    var newDoc = db().getArea("orders").createRootPage(db().getContentType("order"), form.orderid);



    return newDoc.getContentKey();





var newDocContextcontext("docid:" + newDocKey);



The example explained:

  • A master function is called using WGA.Master.runFunction() with the current WebTML form object as parameter
  • The master function creates a document in area "orders" with createRootPage() , fills it with the TMLForm information and publishes it.
  • The master function exits returning the key of the newly created document which the calling action receives as return value newDocKey
  • Now the calling script wants to generate an URL to the new document. It has the key but it needs a TMLContext object for the doc to generate an URL, which it currently cannot retrieve as the new document is yet invisible to the current session. Therefor it reopens the current database session using db().reopenSession()
  • After that it creates a context object "newDocContext" for the new doc using context expression "docid:" plus the key. It uses the newDocContext to generate an URL for redirection.

Master actions. functions and methods can be used by the designer to provide special, well defined functionalities to the user that exceed his normal user rights. So on the one hand they are a potential security risk, as they may contain risky procedures if the designer is not careful enough. On the other hand they sometimes offer the opportunity to give the users lower general access rights and then carefully define the "exceptions" from that as master actions. This is often more secure than given a user higher general access rights which may include operations that are not intended for the user.

Asynchronous master actions

A master action can additionally be marked as an asynchronous action by setting attribute async to "true" on <tml:action>. 

After being called these actions are run "in background". The calling code does not have to wait for the called action to finish but continues directly after triggering it. For example if the async action is directly called via action link on a WebTML page then the call returns immediately with the next page, even if the async action continues to run longer. This comes at the drawback that the calling code cannot retrieve the return value of the async action and cannot react at anything it does.

Therefor async actions are suited for all processes that may run longer and where the calling functionality needs no feedback. A common use case is sending an E-Mail, which may take longer depending on the reachability of the server.