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; } } }

problem with permissions?

duartecordeiro

I grabbed author_submit_dcr and gave it a try.
Everything works as supposed:
- after closing a dcr window, it asks the author for submission. I say yes, fill some data, and a task appears to the area owner.

The only problem is that the areaowner can only "do things" with this task if he is logged as master/admin. Not as editor...
is this supposed to happen?

--
Duarte Cordeiro
Neoris Protugal

Find more posts tagged with

Comments

Migrateduser

Yes, that is the intended behavior. The usertask "Review" which is assigned to the area owner is a readonly task. The intent is that the owner of the workarea (the Editor) would only Accept, Reject or Cancel the submission. If you want to grant the Editor the ability to edit the submitted files, simply change the readonly="t" to "f".

Brinko Kobrin
Interwoven Staff Engineer

duartecordeiro

Sorry, I may have not been clear in my previous post.
When I say, "do things" I mean that when I log as editor I only see:

Job Name (ID): Author DCR Submission (2552) Created: 10/07/2002 07:53 Owner: duarte Creator: duarte Job Options ----------------- Job Details Job Admin Job Attributes
Description: /templatedata/GSK/Article/data/article1

Operation Task Name (ID) Date Owner Status Description
NA Review (2553) 10/07/2002 07:53 rui Assigned Work Review

The big problem is the operation options: NA.. I can't approve or reject as you say.

--
Duarte Cordeiro
Neoris Protugal

Migrateduser

If you are using the "out of the box" author_submit_dcr.wft, the owner of the "Review" task should be the owner of the workarea. If that user logs into WebDesk Pro as an Editor or as an Author, he should have a list of operations including Approve, Reject and Cancel.

For most of the other users in these roles, these operations will not be available because they are not the owner of the task. However, Admin and Master are given special powers that are not available to these lesser roles. In these roles, a user may be able to transition a task even if he is not the owner of the task.

Does this explain the behavior you are seeing? Or is it the workarea owner who -- when logged in as an Editor -- cannot access these operations?

Brinko Kobrin
Interwoven Staff Engineer

duartecordeiro

Well, while I understand your post, and agree 100% with you, what happens is:
I log in as duarte(author) and submit the files.
Log in as duarte(editor) and areawoner and still get a NA

Smiley Sad

Job Name (ID): Author DCR Submission (2606)
Owner: duarte
Creator: duarte
Workarea :\default\main\StagingGSK\WORKAREA\Developpers

Developpers owned by duarte shared with INTERWOVEN\DEV

File Operation File Name Path
NA sdasda.txt \binaries\images\

--
Duarte Cordeiro
Neoris Protugal

duartecordeiro

To directely respond to your post:
- Yes, it's the areawoner (or anybody else) who can't do any operation on the REVIEW task.

Could be a bug already fixed in a patch or SP?
We're being "forced" to use 5.0.1 SP1.

--
Duarte Cordeiro
Neoris Protugal

Adam Stoller

Are you simplifying things in your post or is the owner and creator truly just "duarte" and not "WINDOMAIN\duarte" ?

How is duarte listed in the IWHOME/conf/roles/*.uid files ?
How is the owner/creator of the workflow being set?

The owner/create should be fully-qualified Windows-domain userids if this is a Windows TeamSite server (it is Windows, right?)

--fish
(Interwoven, Curriculum Development)

duartecordeiro

Sorry, let me add some more info:

1&2 - Teamsite is installed on a WORKGROUP called INTERWOEN, its not a domain, its a workgroup.
The users, listed in the roles files don't have the workgroup information, just the username.
a) question: if I do have to add the workgroup info to the users, do I need to delete and create the branchs again to apply changes to ownership?

3 - I'm using the out of the box author_submit_dcr.wft...
so, the owner is the area owner.

4- if that is the problem, I repeat the question: how can I change the workarea owner without having to delete and create it again ?

Thanks for all the help provided so far,

--
Duarte Cordeiro
Neoris Pootugal

booklet.gif

Migrateduser

On Solaris, you can simply chown the workarea directory to whoever you want it to be. You can also do this for the shared group using chgrp. I can only assume there's an equivalent command in Windows. Of course, you need root or sudo priviledge.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

Re: 1 & 2 - I've never seen TeamSite implemented with just WORKGROUP's - so I have no idea what impact if any this might have on the workings of the system. Does this mean that user accounts have absolutely *no* hostname or domain name information associated with them??

If you hit Ctrl-Alt-Delete - what does it say regarding "Logon Information" ?

Re: 3 - that would appear to be a result of 1 & 2

Re: 4 - you should be able to chown/chgrp the branch/workareas using the standard Windows interface for setting permissions on files and folders (I believe this is discussed, at least briefly, in the TeamSite Administrator's Guide)

--fish
(Interwoven, Curriculum Development)

duartecordeiro

Well, I solved all the problems with a fresh install.
Updated to windows 2000 using ADS.
Now eveything works as everybody said in this thread.

but,
C:\iw-home\bin>iwuser -q PNCLAB\duarte
User PNCLAB\duarte
Entity ID 11
Aliases:
Windows SID S-1-5-21-1627535807-1930125358-1689280949-1120
Windows account name pnclab\duarte
No related groups.
Properties:
iw_which_ui=webdeskpro

it just says that duarte its not in any group.. but OTOH if I create a WA shared with a group where PNCLAB\duarte belongs.. I can work there perfectely.

A bug ? or what are the groups that iwuser talks about ?

(TS 5.0.1 Sp2, with patchs p2,p3,p4,p7,p8 & p11)

--
Duarte Cordeiro
Neoris Pootugal