Diff DCTs available in diff WAs -- how?

Hi all...

What is the correct way to make different categories of templates available in different workareas?

In our config, every workarea has a corresponding category and users in one workarea can't see select categories that correspond to other workareas -- we used to control this in templating.cfg using the branch regex:

In this example, Association_Employees is the workarea, not the branch:

<locations>
<branch vpath-regex=".*Association_Employees.*" />
</locations>

This worked fine in TS 4.5.1 and TS 5.0.1 but no longer works in TS 5.5.2 -- using this config in 5.5.2, nobody can see any templates. It appears that in 5.5.2, the branch regex now truly only concerns the branch-level, not the workarea-level.

So how can I accomplish this?

Thanks,
Marc

Find more posts tagged with

Comments

bradkagawa

Hi, I'm having the same problem, has anyone found a solution to this?

Thanks!

mogoo

The category/types won't show up in any given area until the proper directories are in that workarea. So if you don't want a category/type in a particular workarea, don't include a directory for that category/type.
Does that answer your question?
maureen

bradkagawa

I'm concerned that people in the Workarea could just getlatest from Staging and then would have have access to all of the Data Types.

Migrateduser

Is it possible to control it with permissions, like only certain users can read the templatedata/category directory?

bradkagawa

Unfortunately, if I make the directories non-read, I still can choose the data types as new data records from the GUI...

james1

You can restrict categories and data types to specific users. (See the <allowed> tag.) I don't know if that will work for you or not. If your workareas have distinct sets of users, then it should be OK.

-- James

--
James H Koh
Interwoven Engineering

marcmundt

Thanks, James

We thought about this approach, and there are two drawbacks:

"allowed" for specific users is currently broken in 5.5.2 SP2 (scheduled to be fixed in SP3)
We need to do this for entire workareas, and maintaining "allowed" lists containing all users for a particular workarea isn't feasible

Best,
Marc