In Content Server, some settings are applied at a user level by the administrator. For instance, the access controls on the content, or the ability to create more or less type of objects in the system.
In order to quickly test or demonstrate this, it is convenient to switch from one user (with administrative rights) to other users showing the applied settings.
Here is one convenient way to do this using a custom view on the front page (Enterprise Workspace):

fast switching users in Content Server

First, you need to enable “Allow log-in via HTTP GET request” under “Server Configuration > Configure Security Parameters > Log-in Connection Policies” in the admin pages. This may not work in a production environment for security purpose, but is acceptable in a demo or development environment:

HTTP GET request

Also, your environment must be using the Content Server Internal Authentication (or use a backdoor to access internal accounts on your server) for this switching to work.

Next, you may want to retrieve some users icons to use on the top row of the custom view (optional). I chose icons with a similar look and feel, and with a 64×64 size. You will save these icons in a location that is mapped in your Content Server Site:

By default, the “http://servername/img/” is mapped to the “..OPENTEXT/support” folder, so you could use this to save your icons in a subfolder within the “support” folder. Check the proper mapping (if different than “img”), and, save the icons in a folder named: “..OPENTEXT/support/appearances/users/”

You will also need to create and know the users needed for switching, together with their passwords (which will be visible to everyone, thus, making this method unsafe for a production environment)

Then you need to create a text file which will be used to build a custom view with the following code, using the “LL.login” function to pass the user name and password, and bypass the login screen of Content Server:

The first row (<tr>) is for the icons, and the second row displays the text.

Replace the values between “<>” such as server name, passwords and user names with actual values, and also check for the image (icons) mapping, as well as the instance name (OTCS in this case, seen both in the beginning of the URL and in the NextURL tag).

Add as many <td> (cells) in each row of the table as you need users to switch.

Create a Customview in the Enterprise Workspace using this text file and test it. Ensure the custom view has proper permissions to allow all users to see and use it. When your user switching works, you can then hide this custom view from the Enterprise workspace.

Here is a way to solve this with SQL Server, found after a bit of reading.

Lets use a flat table named “Example” containing some hierarchical data with the following column:

ID

Name

ParentID

1

Root Name

NULL

2

child1

1

3

child2

1

4

Grandchild1

2

5

Crandchild2

2

6

Grandchild1

3

In this table, any row can have a parent (except the root one), and therefore a hierarchy view could be created:

Root: Level 1

Level 2

Level 3

Root Name

Child1

Grandchild1

Grandchild2

Child2

Grandchild1

In order to create a query to display this hierarchical view, we first create a recursive source (‘recursive_source’) to provide the expected result. We will need the following 4 columns in our result:

ID: a unique identifier used for joining itself recursively to the parent ID,

The name: this is what we want to display in our report,

The depth level: to be able to indent the result nicely

A sort field: to ensure we display the data in proper hierarchical order

WITH recursive_source( ID, Name, Depth_Level, Sort) AS

(

The first selection is only to get the starting point, the root of our hierarchy (level 1), with the “Parent Name”:

Select root.ID,

convert(varchar(255), root.name), /* The name, we need no discrepancy in the column type so we convert this into varchar */

1, /* depth level: this is the first iteration, therefore we set it at level 1 */

convert(varchar(255), root.name) /* we will start with the parent name for sorting our output */

from Example as root /* we name this first iteration table "root" */

Where root.ID = /* either know the parent ID, or prompt users to select where they would like to start the hierarchical report from */

This is where we create the recursive query

UNION ALL

Select iteration.ID,

convert(varchar(255), REPLICATE('|---', Depth_Level) + iteration.Name), /* Add "|---" as many time as Depth_Level (= Replicate) in front of the name, this creates a natural indentation of the result */

Depth_Level + 1, /* increment Depth_Level for next iteration */

convert(varchar(255), RTRIM(Sort) + '|---' + iteration.Name) /* Append the new name at the end of the sort field + "|---" to keep the hierarchical order of the data as previous level are in front of the name */

From Example as iteration, recursive_source /* The source is recursively queried */

where recursive_source.ID = iteration.ParentID

)

Then create the select statement which will display the sorted recursive result with hierarchical indentation:

“Categories and Attributes” in Open Text Content server is a nice way to add customized metadata to your content stored in the system.

If you want to have “cascading” attributes, for instance “Country >> City”, where you will only display the list of cities within the selected country, you need to use some look-up tables and a bit of SQL.

Here is an example of how you can implement this, with one pitfall and how you can avoid it.

Step 2: fixing a “Table Key Lookup” attribute type shortcoming:

The SQL code provided in the “Table Key Lookup” can’t be more than 255 characters, and must be very simple.

As we would like to combine and display in our look-up values the English and French description, and in order to keep the select statements simple in the attribute definition, we will then create 2 views from our previous tables as follow:

The “Custom SQL statement” box should be checked in order to edit the “Values” box where we will add the SQL statement to query the list of available countries in our look-up table:

Use the following simple select statement to retrieve the list of available countries from the look-up table:

Select Country_desc from Country_view

Create the “City” attribute in the same way (except that this one may not be required, and display it after “Country”), and with the following SQL select statement to retrieve the list of cities based on the selected country:

SELECT City_Desc FROM City_view where Country_Desc = <Country>

Then, test your newly created category by selecting first a country, and then display the available cities you can select: