Influencing the behavior of the embedded Editor

After getting the URL which allows you to embed an editor in your web portal (see ?Embedding an Editor in your own portals), and before posting the result to the client by putting it in the iframe, you have many options to influence the editor in addition to the calls to ?Webservice Functions - DocumentGetEditorURL

API Key Settings

A series of WebService functions exist which operate on the level of the current API Key (see ??API Key Settings for more information):

?Webservice Functions - SetAssetDirectories

?Webservice Functions - SetWorkspaceAdministration

?Webservice Functions - SetContentAdministration

?Webservice Functions - SetUserLanguage

The user levels managed by SetWorkSpaceAdministration and SetContentAdministration influence what the user is allowed to see and do within the Editor. Throughout the configuration of the WorkSpace, you will find pulldowns with settings referring to "administrators" and "end users" like these:

These settings do not necessarily correspond with administrators in your own portal. Rather, they should be seen as "advanced" or "basic" users. In most cases, this is very simple: advanced means your own designers/administrators/account managers, whereas basic means any other user logging in through your portal. The WorkSpaceAdministration and ContentAdministration settings follow these rules:

if neither is true, the user is considered an "end user"
if content administration is true, but workspace administration is false, the user is considered an "end user" only for those settings which directly influence the workspace/interface. This mostly concerns the "WorkSpace Settings" Panel, and configuration of the properties of the Tabs, Toolbars, Panels and Toolbar Items
if workspace administration is true, the user is considered in all circumstances to be an administrator

Admittedly not the most logical way of building in three levels, but then again: the use case was there, and we hope you'll come to appreciate our policy of never breaking configuration and API calls.

NOTE: users levels can also be "simulated". If a user logs in with administrative privileges, the "WorkSpace Box" toolbar item allows him to quickly simulate a lower user level:

In combination with the "initialUserView" querystring variable (see lower), this also means that you can easily allow your administrators to log in through your portal and:

Initially show them the normal "end user" view
Still allow them to easily toggle to Administrative view to finetune a document or a WorkSpace from within your own environment

Additional QueryString variables

In addition to the SetXXX functions (and of course the configuration of the WorkSpace itself by your administrators), you also have access to te following QueryString variables which you can append to te editor URL which is embedded into your HTML page:

windowTitle: if the editor URL is provided as a standalone URL (eg via email), this can be used to easily influence the browser title
logUserName: used for logging of annotations generated/edited in the user session
userAssetDirectory, userGroupAssetDirectory, documentAssetDirectory: see ?External XML URL replacement
initialLayoutID, initialLayoutName: influences the initially selected alternate layout. ID takes precedence over name, if both are provided
initialPageNumber, initialPageName: influences the initially selected page. Number takes precedence of name, if both are provided. The page name includes section prefix/suffix (as used in Page Labels or the Page Pulldown)
initialUserView: IF the user has an elevated user level (workspace or content administration), he can simulate another user level upon opening of the editor (but still be allowed to toggle to full privileges). Accepted values are "content" or "user"
d: set the main domain for security purposes. See ?JavaScript Security Considerations