Best Of

If you are in one folder and have 500 things underneath it in different folders and subfolders, you need to iterate that using WR or LR combination, so an example of such a query will be

Select Name, DataiD from DTREE where PARENTID=1234 // just the direct descendants of a folder

Since OT is now selling thousands of accounts of extended ECM, each workspace is a Volume and has an owner ID concept.BTW, for you to kno,w the Volume concept is not part of XECM but has been in the livelink schema for thirty-plus years and is a proper RDBMS construct. Enterprise WKSP , Personal WKSP, and Project WKSP were the earlier ones before the 848 subtype was invented. There are also thousands of other Volumes any object whoes parentid =-1 is a volume(in simpler terms you cant go higher)

SELECT * FROM [CS25DB].[csdbuser].[DTREE] where PARENTID=64307 does not mean anything that 64307 is an ECM workspace or any Volume

so what you need in that case is to get the workspaceid and query on ownerid

SELECT * FROM [CS25DB].[csdbuser].[DTREE] where OWNERID=64307 //all objects owned by the workspace. This is how OT used to teach us fundamentals. Also, an interview question on jobs in XECM.

Now this will work if your subfolders are part of workspaces, but OT has a convenient table called DTREEANCESTORS that knows the immediate parent :)

If you have a WR applying the correct permission on the folder, just call the same code on the DataIds returned by one of these queries, as the case may be.You can actually parse the children of a container but that maybe for your own reaserch :)

We typically don't use these sub-tags for the same use cases as object importer, though we have created a migration engine in the past, using this functionality where we are also potentially creating new CS objects and manipulating them with WR actions etc. - very flexible! Besides migration, there are actually dozens of use cases where checking file information, copying files, creating objects from files, or whatever are useful. Many customers and partners are using WR to create fully functioning, meaningful applications (including us) and to do that you need the full capability you would have with any development tool. Also, as with all development capability, there is the potential for creating trouble. Given that everything done with WebReports requires an authenticated user working through auditable, permissioned objects, the security is actually higher than many alternatives. Of course the best way to avoid compromising any server is not to allow anyone to do anything that would modify the core functionality, but that is not the world we live in, and all capability provided for development has the potential for trouble whether malicious or accidental. The objective when creating tools like this is to provide as much capability as possible with sensible safeguards built in. With these file sub-tags we did various things to restrict who can actually use them in a WebReport to limit the scope of people who can set them up, but we also wanted to reduce the possibility that a validly authenticated developer might accidentally damage something so we have a system of path variables that have to be setup using a separate tool in order to define what these sub-tags can actually access. This is similar to the restrictions imposed by core WebReports for file paths, and we will likely leverage those paths in the future too.

Finally, one of our objectives as a company is to help customers to achieve maximum development potential, while using all these tools safely and as they were designed to be used.

Cheers

Greg

Good point Appu. The sub-tags can copy or move content from the file system, but the gettextfile sub-tag is purely designed to get text out of a text type file so you have the content to use in some way. The sub-tags do not provide a viewer, they are only a mechanism to access files.

Resolved via execution of additional purge related commands (aside for helm delete and kubectl delete pvc —all) which can be found in readme.md —> "Uninstalling the Chart":

If OTAC was deployed remove configMap and job related to otac upgrade

kubectl delete configmap otac-pre-upgrade-configmap

kubectl delete jobs otac-pre-upgrade-job

If OTIV was deployed remove all secrets and service accounts related to otiv

kubectl delete sa otiv-job-sa otiv-pvc-sa

kubectl delete secret otiv-cs-secrets otiv-highlight-secrets otiv-job-sa-token otiv-publication-secrets otiv-publisher-secrets otiv-pvc-sa-token otiv-resource-secret