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

Default Allowed Approvers for a .wft workflow

HurricanesFan

Hello,

another workflow approver thread, but this is for a .wft workflow.

I made a review workflow based on solutions/author_submit_with_deploy.wft - I had noticed (so I thought) when testing that workflow that you had to be an Admin in the branch to be able to approve/reject and editors couldn't, which would have been sufficient for my needs.

But for my workflow I notice that now editors can approve/reject.

So my question is who or what role are default approvers for .wft worklfows? Haven't found a note on that in the (obsolete) documentation.

A "foo" xml file excerpt for my workflow follows; note I am not using a <grouptask>, as I was hoping I wouldn't need to and approvers would be by role. What do I need to enable/disable approvers? Cheers.

<workflow name="Promote (with Review)"
          owner="root"
          creator="root"
          description="Peter Check 20151106 1143">

    <externaltask name="Email_Reviewer"
          owner="root"
          start="t"
          description="New Job to review: Peter Check 20151106 1143 from nlmoccstest3">
        <areavpath v="/default/main/nlm/WORKAREA/common"/>
        <successors>
            <successorset description="Approve">
                <succ v="Approver"/>
            </successorset>
        </successors>
        <command v='/usr/nlm/iw/iw-home/TeamSite/local/config/wft/nlm/email_messages.ipl review_review_default_ nlmoccstest3@mail.nlm.nih.gov
'/>
    </externaltask>

    <usertask name="Approver"
              owner="root"
              description="Review Task"
              start="t"
              readonly="t">
        <areavpath v="/default/main/nlm/WORKAREA/common"/>
        <successors>
            <successorset description="Approve">
                <succ v="Submit"/>
            </successorset>
            <successorset description="Reject">
                
                
                <succ v="Rejection_Email"/>
            </successorset>
        </successors>
        <files>

                               <file path='htdocs/accessibility.html' comment='Valid'/>
                               <file path='templatedata/internet/main/data/accessibility.dcr' comment=''/></files>

        
        <activation>
                <pred v="Email_Reviewer"/>
                
        </activation>
    </usertask>

    <submittask name="Submit"

etc

Find more posts tagged with

Comments

nipper

Your approver task is set to root

<usertask name="Approver" owner="root"

However people with the right permissions can transition someone else's workflow. I am rather surprised that an editor can.

Normally you would have a group task here, then no one can trnasition it until they take control and no one can take control unless they are listed.

HurricanesFan

Yes, I thought setting the owner to root would prevent the initiator from approving his own job - certainly make it more rather than less stringent.

I thought I had it so that only Admins could approve/reject. I'll retry the OOTB workflow I based this on to compare.

I am trying to avoid a <grouptask> if possible as my remit is to produce a workflow with "less clicks", and I'd rather not have an extra "take" task.

Adam Stoller

HurricanesFan wrote:
Yes, I thought setting the owner to root would prevent the initiator from approving his own job - certainly make it more rather than less stringent.

I thought I had it so that only Admins could approve/reject. I'll retry the OOTB workflow I based this on to compare.

I am trying to avoid a <grouptask> if possible as my remit is to produce a workflow with "less clicks", and I'd rather not have an extra "take" task.

If you don't have a group task, you need to determine who the owner of the task should be - either during instantiation (a drop-down most likely) or via a CGI Task or programmatically (somehow) in an External Task.

Since you say you only want Admins to be able to approve / reject - this sounds very much like a Group Task, but if you provide a drop-down menu (in instantiation or CGI Task) with a list of users who have the Admin role on the particular branch, you should be able to take the selected value and make that user the owner of the review task.

I don't think an Extneral Task would be much use unless you want to somehow randomly select a user from the group of Admins and just make them the owner of the task (kind of a reverse lottery? :-))

HurricanesFan

Hmmm. I've tried making other users the owner of the Approver <usertask>, but it seems that anyone can perform the task. Ditto with the OOTB solutions/author_submit_with_deploy.wft workflow.

I am certain that was not the case when I first tested this, when only Admins could review. The only change that I can think of that may have affected this, is that I changed our branch regime from individually-owned workareas to 1 group-owned, common workarea. But I don't see why that could have made a difference - I think it will make iw_areaowner = root, but even then.

I was hoping to avoid this, but it is looking like I may have to add a <grouptask> to stop "lower-level" users from being able to approve/reject. Man Sad

HurricanesFan

I discovered something interesting.In our TeamSite Production environment we have a Review workflow that does have a "take" <grouptask> before the Review <usertask>.

And I found that I can review jobs as an unauthorised user. I can not "take" Jobs (get "permission denied"), but even after someone else has "take"in a Job, I can go in as that unauthorised user and do the review.

So it looks like the <grouptask> really only serves to halt the workflow Job until an authorised user turns up to "take" the Job.
But if that user doesn't go in and review right away after that, then anyone else can go in and approve/reject.

Anyone else noticed that loophole?

Adam Stoller

What roles do you have when you are transitioning a grouptask that you did not take?

Can you post - as an attachment - the job spec for the workflow in question?

HurricanesFan

Thanks for looking at this, Ghoti. I may be not be completely au fait with the workflow jargon, such as "transitioning a grouptask".

I've made a word doc with screenshots I want to attach, but I can't see where at the moment, so in words:

I made a simple workflow with a grouptask then usertask to demonstrate (foo file follows), but it exhibits the same behaviour I see in our more long-winded prodution workflow i.e. has me wondering about the use of the group task if a non-authorised user can still go in and do the Review:

User nlmoccstest1 (editor in nlm branch) starts workflow – 1st screenshot
- Note: It would be good not to see (and thus go into) the Review Task at this stage
nlmoccstest1 can not “take” Job (not a member of group psdweb)
I can take Job – 2nd screenshot
But even after my user has taken the Job, user nlmoccstest1 can go into the Review Task and approve/reject – 3rd screenshot

foo of this workflow instance:

HurricanesFan

I found a possible solution.

If you disable <TransitionTask> for authors & editors in roles.xml, then only Admins can approve/reject in the Review <usertask>.

However this only applies if users are universally NOT Admins everywhere. For example my test user is an Admin in just 1 branch and he can approve/reject, another user is only an editor in every branch and she can not approve/reject. So I need to take away Admin rights for all users I don't want reviewing but can't for some, not sure why that is:

iwaccess all-permission-entries-of-user nlmoccstest1
//pvlbteamsite02/default editor
//pvlbteamsite02/default/main/nihseniorhealth admin,editor
//pvlbteamsite02/default/main/intranet editor

iwaccess remove-permission-entry /iwmnt/default/main/nihseniorhealth -user nlmoccstest1 -role admin
Invalid or no permission entry

Huh?

So that's another issue.

But this is looking like the best solution to have a workflow where only certain users can approve/reject the Job...

...given that I really am not seeing the point of the <grouptask> directive. Sure it only lets those users who are part of the defined group "take" that task, but what's the point if anyone can still go in and approve/reject in the successor Review <usertask>? Not getting that.

nipper

HurricanesFan wrote:

...given that I really am not seeing the point of the <grouptask> directive. Sure it only lets those users who are part of the defined group "take" that task, but what's the point if anyone can still go in and approve/reject in the successor Review <usertask>? Not getting that.

In my experience, people tend to transition soon after taking a task. Yes, if I take a task ans leave it sit for a while, the job owner, or other peron can transition it. But only someone who is on the group list can take it and if they act on it quickly, the problem is solved.

HurricanesFan

Yes I think that must be it, Nipper. I didn't realise there was this "loophole" until I theorised it, hence my surprise.

The upshot from this exercise is that in order to have a workflow in which only certain people can approve/reject the Job to deploy files live, I have 2 choices (unless anyone has better ideas):

1. I put a <grouptask> before the Review <usertask>, and only users within the group defined can "take" the Job. It is assumed they will immediately go on to Review the Job, before anyone else does. Extra clicks.

2. I make all (and only) allowed reviewers as Admins so that only they can Review Jobs, with "TransitionTask" disabled for authors & editors in roles.xml. Think that's OK because I don't think we have a need to differentiate user rights for any other reason here. Means some user re-configuring and I am finding an issue with removing Admin rights in some branches for some users.

Hmmm.

Cheers

nipper

Why would use put the group task before the user task ?

Replace the user task with a group task

Then it is a single extra click.

You will need to change your email because the email task cannot point to a group task, but you cna make that an alias with some work

HurricanesFan

Tching, of course! Amalgamate into 1 task, not sure why I was hung up on having 2 separate tasks - probably because I was following our old workflows.

I found I was able to make it work simply by changing the Review <usertask> to <grouptask> and adding in a <sharedby> tag for the relevant group. So I have a "take" button which must be clicked to make the approve/reject buttons active. In theory someone could just click "take" and someone else could go in and approve, but since it is all on 1 screen I can live with that - I'll just provide instructions in the user guide I have to write.

Bit more testing, but I think I'm just about there.

nipper

If you use email notification, you will need to change that. But it is pretty easy.

HurricanesFan

My emailing tasks are just externaltask's so didn't have to change them, they are working.

For the record this is what I ended up with (foo):

<workflow name="Promote (with Review)"
          owner="root"
          creator="root"
          description="Submitting as NLM OCCS Test1 20151112 1334">

    <externaltask name="Email_Reviewer"
          owner="root"
          start="t"
          description="New Job to review: Submitting as NLM OCCS Test1 20151112 1334 from nlmoccstest1">
        <areavpath v="/default/main/nlm/WORKAREA/common"/>
        <successors>
            <successorset description="Approve">
                <succ v="Approver"/>
            </successorset>
        </successors>
        <command v='/usr/nlm/iw/iw-home/TeamSite/local/config/wft/nlm/email_messages.ipl review_review_default_ nlmoccstest1@mail.nlm.nih.gov
'/>
    </externaltask>

    <grouptask name="Approver"
              owner="root"
              description="Review Task"
              start="t"
              readonly="t">
        <areavpath v="/default/main/nlm/WORKAREA/common"/>
        <successors>
            <successorset description="Approve">
                <succ v="Submit"/>
            </successorset>
            <successorset description="Reject">
                <succ v="Rejection_Email"/>
            </successorset>
        </successors>
      <sharedby>
        <group v='psdweb'/>
      </sharedby>

        <files>

                               <file path='htdocs/web/test/test_Teamsite751_Roger/RogerTestPage4_asNLM_OCCSTest1.html' comment='Valid'/>
                               <file path='templatedata/internet/main/data/web/test/test_Teamsite751_Roger/RogerTestPage4_asNLM_OCCSTest1.dcr' comment=''/></files>

        <activation>
                <pred v="Email_Reviewer"/>
        </activation>
    </grouptask>

     <submittask name="Submit"

etc

nipper

Easy-peasy.

Some email tasks point to the user task and grab the email of the person assigned. Since you don't do that, you are golden.

BTW, I would suggest you start phasing out the use of .dcr and move to .xml. Just a best practice, some functionality (you may not care about) won't work on the .dcr extension

HurricanesFan

Thanks Andy.

I am likely to encounter a resistance to change if I try to change anything with the templating, and it is fiercely guarded, but as a matter of interest what extra advantages and functionality would we see if we go from .dcr to .xml?

And a question on board etiquette, as I irked someone before: Which post should I mark as the solution - the post from another user that suggested the change that ultimately proved to be the solution, or a post (which would be by me) that puts down the actual solution complete with code? The former obviously gives credit to the person who provides the suggestion for the breakthrough (I am not sure if people are tallying these?), the latter provides the best summary for anyone else who has the same problem.

Cheers

nipper

Answers inline in red

HurricanesFan wrote:
Thanks Andy.

I am likely to encounter a resistance to change if I try to change anything with the templating, and it is fiercely guarded, but as a matter of interest what extra advantages and functionality would we see if we go from .dcr to .xml?

If you use SitePublisher and different languages you can use the feature that a page will select the appropraite language from foo.xml, foo_es.xml, foo_fr.xml, automatically. On a project where there was no extension and this is biting me in the a$$

It is also something that you can download and view in a browser or other tool as XML, since it knows the files are XML.

I really don't expect you to rename all your old DCRs, but if you start new projects, use the XML style DCRs rather than iwov and use .xml as a standard.

And a question on board etiquette, as I irked someone before: Which post should I mark as the solution - the post from another user that suggested the change that ultimately proved to be the solution, or a post (which would be by me) that puts down the actual solution complete with code? The former obviously gives credit to the person who provides the suggestion for the breakthrough (I am not sure if people are tallying these?), the latter provides the best summary for anyone else who has the same problem.

Your call. Rankings (stars on the username) are based on liked posts and solutions. If there is one close than mark it as a solution. Otherwise like the ones that help and post a solution and mark it. I have done both.

Cheers
PJ