nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Forms filtering by workarea

rapid

TeamSite 6.1 SP1 on W2K

Branch A
|___ Workarea B(Marketing group)
|___ Workarea C(Corp Comm group)

Workarea C users will only be working on a few of the templates.
Even if i don't keep these templates in Workarea C, when user does a Get Latest, they will get all the files.
(Get Latest only for particular directories could work but would be difficult to control)

I don't want to have these templates under the templatedata folder in WORKAREA C.
I could control access through folder permissions, but when user selects new form in Workarea C, he is going to see all the forms.
If i mark the particular (templatedata>>category>>data-type) folder as 'private' / Do Not Submit for Workarea B,
that may seem to solve this problem, except that the DCRs will never get submitted and i won't have a history.

Is there any way to achieve this ? Maybe filtering "Get Latest" in Workarea C??
Thanks.

Find more posts tagged with

Comments

Adam Stoller

The templatedata directories need to exist in both workareas (there have been other threads about trying to coerce different content in different workareas on the same branch - generally not supported) - but you *might* be able to configure the templating.cfg to show some in one workarea and some in the other workarea.

I say *might* because templating has a history of only being able to be configured at the *branch* level rather than the workarea or directory level - but it's still a possibility.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Dwayne

What about just marking the datacapture.cfg as private, rather than the entire folder? If I remember correctly, the logic that was put in place to filter categories (and re-enabled in SP1) looks for the presence of datacapture.cfg, not just the directory.

If that works, then the only versioning you're losing is on the DCT itself, rather than the DCR. However, it may still lead to problems. What happens when (not 'if') a user in workarea C clicks 'edit' on a DCR that's based on one of these 'hidden' types? They're going to get a rather unfriendly error message.

rapid

Thanks for your responses.
Dwayne - I think the logic looks for presence of the data-type's directory. I tried removing the datacapture.cfg, it still shows that data-type in the New Forms.

ghoti - I tried coercing templating.cfg into filtering by WORKAREA, but doesn't work. I had seen the other posts but not found any solution to this. I was hoping there was some workaround in TeamSite 6.
Basically, we have different templates in different workareas within the same branch - i guess this is not supported.

Thanks again.

y-axis_grouping_issue1.jpg

Dwayne

In reply to:

think the logic looks for presence of the data-type's directory. I tried removing the datacapture.cfg, it still shows that data-type in the New Forms

Oh, well. So much for that one. (I'm assumng that you've set the prune-missing-files="t" attribute in templating.cfg, right?)

In reply to:

Basically, we have different templates in different workareas within the same branch - i guess this is not supported

It really does break the basic TeamSite paradigm that each workarea os a virtual view of the same content..

Have you investigated using <allowed>? It becomes a pain to manage, because you need to list individual users, but it might give you what you need, as long as some combination of user and role can uniquely identify those users who shouldn't see the data types in question.

rapid

>> Oh, well. So much for that one. (I'm assumng that you've set the prune-missing-files="t" attribute in templating.cfg, right?)
Yes

>>Have you investigated using <allowed>? It becomes a pain to manage, because you need to list individual users, but it might give you what you need, as >> long as some combination of user and role can uniquely identify those users who shouldn't see the data types in question.

Exactly. I wish allowed could accommodate usergroup. That would make maintenance easier.

I have these 2 options to somewhat achieve what i want:
>> add allowed tags in templating.cfg.
>> set directory permissions on the individual directories in the workarea and modify submit.cfg to enforce that.

Dwayne

In reply to:

Exactly. I wish allowed could accommodate usergroup. That would make maintenance easier.

That's been a complaint of the various incarnations of the <allowed> tags for a while. Unfortunately, I don't see that changing while TeamSite is relying on the OS for group management. Querying a list of group members can potentially be fairly expensive in terms of time to execute. Interwoven takes enough performance complaints as it is. I doubt they're going to add something in which would add to it..

The equivalent in workflow's <grouptask>, <sharedby> is OK because the user isn't waiting for it to process before they can continue. Imagine a templating.cfg with multiple group entires in various <allowed> tags. It might take quite a long time for the list of allowed categories and types to show up.

When (if) they break the "joined at the hip" mentality with the OS, this sort of functionality may be more feasible. (Along with true SSO integration, etc, etc)