Best Of

Re: how to get custom content in the yellow box when using type ahead

Hi Greg - type ahead stuff is changing quite a lot in the 26.4 release, including what I think you're asking for - IIRC your version of CSIDE only provides text info on builtins, but once 26.4 is out you should get function & object comments (where comments exist) as well:

… as you can see: the help blurb will be HTML instead of plaintext, and will have clickable links (where links in the online documentation exist):

… the same blurbs will be shown when you hover things in the IDE.

More importantly: the detection for this sort of things has improved a lot, both in accurate results & speed. The changes also apply to "Go to definition (F3)" and hopefully "Find Workspace References (shift-control-G)" (I'm currently working on the latter bit now, I'm hoping something usable is in for the 26.4 release, but no promises).

Dave Carpeneto

1

Re: TBO access from Webtop

@sunilku

Composer is the best approach, it will create a DAR file you can use in your CI/CD pipeline (with headless composer) to deploy. Once deployed to the repository, all DFC clients will get it from the content server so no need to deploy to each application like the old BOF1 did, this ensure all DFC clients are compliant with your logic in your TBO.

Michael McCollough

1

Re: WebReport Trigger to Create Parent/Child Relationship between two Business Workspaces

Hi,

I've skimmed all of this so apologies if I miss a point. The piece I can't see here is that you probably need two WebReports as you need some way to pass the trigger Id to the WebReport that has the Livereport as a data source. E.g.

TriggeredWebReport, calls a SubWebREport

The SubWebReport has your LiveReport as a datasource and is essentially the code you have above.

The Triggered WebReport should include code something like this:

[LL_REPTAG_$WKspCreationWR RUNSWR:sourceId:[LL_REPTAG_TRIGGERID /] /]

Obviously the constant points to your original WebReport.

A couple of other points. Initially you could just have your WebReport return the simple row section:

[LL_WEBREPORT_STARTROW /]

[LL_REPTAG=WpWorkspaceid /]
[LL_WEBREPORT_ENDROW /]

just to confirm that you are getting the single Id as expected.

Also in your code you have:

[LL_REPTAG=WpWorkspaceid TRIM SHOW SETVAR:WPParentID /]

Minor point:

The SHOW sub-tag is unnecessary here. It is most effectively used when you want to set a variable, but you also want to show the value that was just put in the variable, e.g.

[LL_REPTAG=WpWorkspaceid TRIM SETVAR:WPParentID SHOW /]

Unless show is positioned after a variable setting (or CONCAT etc.) it doesn't do anything (though it will also not break anything).

I partly point this because I'm pedantic, but also if you're ever expecting an output through using SHOW it only works in the way I show above.

GregPetti

1

Re: why oracle does not appear during installation content server 25.4?

Hi all,

Thank you for your time on this post.

We identified the root cause: the team had installed the 32‑bit client, but according to the documentation only the 64‑bit client is supported.

After installing the 64‑bit client, we were able to select Oracle as the database.

Thanks and regards,

Kamal

KSanugula

1

Re: OCP Developer Workbench - API testing app

v 0.9.3: Debug instances!!

You can now debug running instances!! All you need it the running instance id (as long as it is not ended) and we will get the variables, current and past activities and model version and start a debugging session. If the running instance model is not the latest version, you will get a notification so that you don't overwrite the latest version. Finally, the debug session will not interact with the running instance, it will run the calls in separate instances.

LazarescuA

1

Re: OTDS OAuth2 Token Exchange — "User cannot be impersonated in resource Content Server" error despite

Resolved — Full Working Solution (Content Server 23.1 + OTDS 23.1.8)

After extensive testing I was able to get OTDS-based user impersonation working with Content Server 23.1. Here is the complete solution for anyone else hitting this issue.

The Core Problem

The OAuth2 token exchange grant type (urn:ietf:params:oauth:grant-type:token-exchange) is not the right approach for impersonation in this context, even though OTDS partially supports it. Instead, you need to use the OTDS legacy REST authentication endpoints directly with an OTDS SSO ticket.

Two important clues that point to this:

The token-exchange grant type does not appear in the OTDS OIDC discovery endpoint's grant_types_supported list at /otdsws/.well-known/openid-configuration
The KB article KB0717615 (legacy KB8295770) explicitly states that for OTDS-synced users you must use /authentication/ticketforuser or /authentication/resource/ticketforuser

The Working Flow — 3 Steps

Step 1 — Get an OTDS SSO Ticket for the Service Account

Use the /authentication/credentials endpoint — NOT the OAuth2 /oauth2/token endpoint. This returns a legacy *OTDSSSO* or *VER2* format ticket rather than a JWT.

POST /otdsws/rest/authentication/credentialsContent-Type: application/json{  "userName": "YOUR-SERVICE-ACCOUNT@OAuthClients",  "password": "YOUR-CLIENT-SECRET"}

PowerShell:

$auth = Invoke-RestMethod -Method Post `  -Uri "https://YOUR-OTDS/otdsws/rest/authentication/credentials" `  -ContentType "application/json" `  -Body '{"userName":"YOUR-SERVICE-ACCOUNT@OAuthClients","password":"YOUR-SECRET"}'

The response includes a ticket field starting with *OTDSSSO* or *VER2*. This ticket can be reused to generate multiple impersonated tickets until it expires (1 hour).

Step 2 — Get an Impersonated Ticket for a Specific User

POST /otdsws/rest/authentication/ticketforuserContent-Type: application/json{  "ticket": "TICKET-FROM-STEP-1",  "targetResourceId": "YOUR-CS-RESOURCE-ID",  "userName": "USERNAME@PARTITION-NAME"}

PowerShell:

$impersonated = Invoke-RestMethod -Method Post `  -Uri "https://YOUR-OTDS/otdsws/rest/authentication/ticketforuser" `  -ContentType "application/json" `  -Body (ConvertTo-Json @{    ticket=$auth.ticket    targetResourceId="YOUR-CS-RESOURCE-ID"    userName="USERNAME@PARTITION-NAME"  })

Note: The userName must include the OTDS partition name appended with @. For example: myuser@Non-Sync Users - DEV. The exact spelling and case must match what appears in the OTDS admin console under Users & Groups. To get your Content Server Resource ID (no auth required): https://YOUR-CS/otcs/cs.exe?func=otdsintegration.getresourceid

Step 3 — Call Content Server with the Impersonated Ticket

Use a GET request with the ticket as an OTDSTicket header — not in the POST body.

GET /otcs/cs.exe/api/v1/nodes/2000OTDSTicket: IMPERSONATED-TICKET-FROM-STEP-2

PowerShell:

Invoke-RestMethod -Method Get `  -Uri "https://YOUR-CS/otcs/cs.exe/api/v1/nodes/2000" `  -Headers @{OTDSTicket=$impersonated.ticket}

Important: OTDS tickets are single-use. You must request a fresh impersonated ticket for each Content Server session. The Step 1 ticket can be reused until it expires to generate multiple impersonated tickets.

Required OTDS Configuration

Setting	Value	Where to configure
OAuth client — Allow Impersonation	Enabled	OAuth Clients → your client
OAuth client — Confidential	Enabled	OAuth Clients → your client
Service account in otdsadmins group	Required — see note below	Users & Groups → otdsadmins@otds.admin → Add Member
Access Role — User Partition	Add partition containing users to impersonate	Access Roles → Access to Content Server → User Partitions tab
Access Role — Resources	Add Content Server resource	Access Roles → Access to Content Server → Resources tab
CS Resource Impersonation	"Allow this resource to impersonate users" checked	Resources → Content Server → Actions → Impersonation Settings

Critical — otdsadmins membership is required: The service account must be a member of the otdsadmins@otds.admin group. Without this you get error 1012: "Impersonator must be a resource or an OTDS administrator". The ticketforuser endpoint enforces this check — there is no way around it for OAuth client accounts. Adding the OAuth client to otdsadmins is the correct and necessary configuration.

Note: we tested whether creating a separate OTDS resource for the service account would work as an alternative to otdsadmins membership — it does not, because the authentication is still performed as the OAuth client identity, not as the resource. The otdsadmins membership is required.

Error Reference

Error	Cause	Fix
1009 Invalid parameter	Username format wrong or OAuth client partition mismatch	Use `username@partition` format; set OAuth client partition to Global
1012 Impersonator must be a resource or OTDS administrator	Service account not in otdsadmins group	Add service account to otdsadmins@otds.admin group
invalid_scope: User cannot be impersonated in resource	Resource impersonation not enabled, or using wrong grant type	Enable "Allow this resource to impersonate users"; switch to credentials endpoint approach described above
1015 Replay detected	OTDS ticket reused — tickets are single use	Request a fresh impersonated ticket for each session
Authentication Required (Bearer token)	Passing JWT to CS instead of OTDS SSO ticket	Use credentials endpoint (Step 1) to get SSO ticket, not OAuth2 token endpoint
username/password required on CS auth	Passing ticket in POST body instead of header	Use GET request with OTDSTicket as header

Reference

OpenText KB article KB0717615 (legacy ID KB8295770) — "Content Server - SDK - How to use Impersonate User using REST API to create an item as a specific user" — confirms that for OTDS-synced users, the OTDS /authentication/ticketforuser endpoint is the correct approach.