workflow not available in Content Center Standard

Attached is my available_templates.cfg

Check out the template called "Deploy Web Site". It's the first entry in the config file. When I'm logged in as role=master using the Professional interface that workflow is available to me along with some other workflows that are triggered on new_job.

However, if I'm logged in as role=master but using the Standard interface, I get this error when I click on new job:

Could not find available new_job workflow templates for user CFCF\tsi (master, )

I allowed all users of all roles in the role_list and even explicitly specified all users in the user_list but I'm still getting the error.

What's up with that?

TS 6.5
Windows 2000 Server

Find more posts tagged with

Comments

nipper

CCSTD often has no branch associated with it. Since you can have multiple
branches depending on your config.

Try removing the branch restictions.

HTH

me

yanSi

Thanks, that worked!

How do you suggest we go about making certain workflows available to the appropriate people without the branch_list?
1) Use the role_list and user_list? That would be painful I think.
2) Change the workflow code to do a bunch of checking? That would be even more painful.

TS 6.5
Windows 2000 Server

nipper

This is a major problem with cc-std. I do not know how a large company with a
diverse set of branches can use it. Similar issues with Templates.

If someone from IW wants to chime in, that would be great

yanSi

I also noticed that the My Workareas portlet is doing something weird in content centre standard. It seems that a workarea will appear in the portlet only if you are the creator of the workarea. It does not matter if sharing is set to a group and I'm a member of that group, the porlet just won't show the workarea if I didn't create it. In content center pro, I don't have problems at all accesssing that particular workarea.

The problem can be solved if we are able to set some default favorites for our users, but I searched devnet and it appears that it is impossible to do.

Has anyone else encountered these types of problems? It seems to me that this is a serious issue since content center standard is useless with all these problems.

TS 6.5
Windows 2000 Server

Adam Stoller

You could probably set default favorites for users if you wanted to -- do it for one user and then look at the data associated with them in their entity file - and then copy that information to the other user's entity files.

I'm not sure that I'd consider this a "recommended" procedure - and perhaps not even an "officially supported" procedure - but I *believe* it would work.

Also - I don't think it matters if the user *created* the workarea - what matters is if the user is the *owner* of the workarea. On that respect - if the behavior is as you describe (I don't use CCStd if I can avoid it) - then there's probably a feature request there for having the portlet respect both ownership *and* group-sharing aspects of workareas (though I suppose the industrious folks out there would write their own portlet to do this - it would seem reasonable for IWOV to supply it OOTB).

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

yanSi

We were able to set default favorites for users by editing the serialized user files. But there's another problem with that approach. A new user has to log in first before their user object is serialized. You have to shut down the services before you edit those user files so on a production server this will be a big pain. I suppose we could copy the user files from a test server to a production server but again what a pain. If we use this approach, we'll end up with just the favorites portlet for users to browse to their workareas and create new forms so that's just stupid.

Does anybody out there actually get their users to use the standard interface or are you all sticking with professional?

Man, I really love complaining.

TS 6.5
Windows 2000 Server

Edited by yanSi on 03/24/05 07:47 AM (server time).

yurin

'My Favorites' are stored in the $iw-home/local/entities/Data directory
The file $iw-home/local/entities/Data/Index contains the index of all real TeamSite users and MyFavorites list is stored in the:
$iw-home/local/entities/Data/[userId] file in the field: iw_filesys_bookmark ="....."
This information can be transferred between user profiles

yanSi

We tried to set default favorites for our users, but it only worked for a few people and didn't for the majority. I don't know the reason for it and I don't want to figure it out since the approach with using favorites is retarded anyway.

Looks like nobody from Interwoven wanted to comment on this topic so I guess I just have to diss Interwoven to get their attention. My opinion is that CC STD is absolutely useless. I don't think Interwoven did any testing on SSstd, otherwise they wouldn't have overlooked such a major problem.

If anybody thinks I'm wrong, PLEASE put me in my place.

TS 6.5
Windows 2000 Server

Adam Stoller

From a workflow perspective CCStd works fine if you're workflows are not context-sensitive / your users are used to [willing to] select branch / workarea during the job instantiation.

I think that it is conceivable that "novice" or "non-power" users could actually prefer CCStd -- however it's difficult for me to really assess that as I don't fit into either of those categories and the customer I'm working with is used to using WebDeskPro with context-sensitive workflows - so CCPro is a much better fit (we used the information posted on the forums to disable the CCStd choice - and I'm happy to say that it survived the SP1 installation!)

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

iwovGraduate

On my TS 6.5 on Windows I am able to see the workareas that I don't own or I did not create.
Am I missing something ?

Adam Stoller

iw.cfg settings for enabling branch and/or workarea security?
iw.cfg setting for enforcing authentication when going through iwproxy?

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

iwovGraduate

In my configuration:

branch_security =off
workrea_security=on
authentication when going through proxy - No.

earlier in the thread by yanSi -

I also noticed that the My Workareas portlet is doing something weird in content centre standard. It seems that a workarea will appear in the portlet only if you are the creator of the workarea. It does not matter if sharing is set to a group and I'm a member of that group, the porlet just won't show the workarea if I didn't create it.

However this is not the case in my installation (nor have I observed it earlier). I can see (and browse) workareas
- that I did not create,
- that I do not own,
- are shared by a group of which I am a member of
from CCStd My Workareas portlet while loging in as Editor role. (I am also a part master.uid. Perhaps that makes the difference?)

So I am inclined to think that yanSi is facing this due to something particular to his/her installation.

Adam Stoller

There are a couple of possibilities - one of which is your being a member of the master.uid file - another possibility is what the access rights on the workareas are from the filesystem perspective -- i.e. do they have Everyone access?

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

iwovGraduate

Hmm, good point. I didn't think about that.

However -

The workarea (that I was testing with) does NOT have Everyone as sharedby. From the filesystem security of the workarea I see three entries - the owner of the workarea (not my userid), TS Web Preview group and the domain group that is used as sharedby (of which I am a member of).

Further, I removed myself from master.uid, verified that I don't have master access by running iwckrole, and then logged in to CCStd. I am able to see/browse the workarea(s) from My Workareas portlet.

Perhaps I am missing something else here.

Regardless, the original issue in this thread - if I understand it correctly - is due to the fact that CCStd does not have the context of current workarea which creates problems when the workflow (or the wft instantiator) expects a workarea vpath. There is a simple solution/workaround to this - disable the New Job link from the CCStd main/home page and add a New Job link in the workarea browse screen - which will have the workarea vpath variable, and thus avoiding the original issue.

Migrateduser

Interwoven did to user interface testing on CC Standard. The feedback was that people did want the interface to work this way.

I was not directly involved with this work, but I know it happened. I can't elaborate on the rationale, which is why I didnot post before.

hth,

lissa

faz_at_freddie

I have the same question, is working on two different interfaces worth the effort, especially since it seems that there are numerous tweaks that need to happen to get ccstd working correctly (with customizations). Have you guys gone with one or both interfaces? If I remember correctly, there isn't an officially supported way to turn off ccstd, but you can make it difficult to find or get there.