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

[7.2.1]How to configure groups/roles to user OD from WFM?

Wolfwood

After our recent teamsite/opendeploy/livesite upgrade to 7.2.1 (which was horrible to do, but that's besides the point) our workflows stop deploying.

This seems to be because the user executing the workflow doesn't have any rights to use us Open Deploy. If an user is an od-admin or od-user (with the right deployment group) in OD it will work fine. that could work but adding every TS user to OD is a pain in the arsch. So isn't a option. Smiley Sad

Making owner of the workflow deploy task a default OD user/admin will work as well. However that way we won't (easily) be able to see who did the deployment and kick that persons'**** if there's a mistake. Smiley Tongue

So what do we want? To give the deployment rights to a group (and/or role) and add users to that group. The same way as other rights work (or another way) to give all current and future TeamSite users the rights for OD. Can anyone point me in the right direction? Smiley Happy

The error when an user doesn't have deploy rights:

2011-06-28 15:50:32,188 [http-0.0.0.0-8080-49] ERROR com.interwoven.ui.teamsite.workflow.task.URLExternalTaskCommand () - Exception when excuting URL external task com.interwoven.ui.teamsite.workflow.task.urltask.DeployURLExternalTask
java.lang.NullPointerException
 at com.interwoven.cssdk.sci.workflow.WorkflowServiceSciImpl.chooseTransition(WorkflowServiceSciImpl.java:632)
 at com.interwoven.cssdk.workflow.java.WorkflowServiceAdapterImpl.chooseTransition(WorkflowServiceAdapterImpl.java:68)
 at com.interwoven.cssdk.workflow.impl.CSTransitionableTaskImpl.chooseTransition(CSTransitionableTaskImpl.java:34)
 at com.interwoven.ui.teamsite.workflow.task.urltask.DeployURLExternalTask.startDeployment(DeployURLExternalTask.java:257)
 at com.interwoven.ui.teamsite.workflow.task.urltask.DeployURLExternalTask.execute(DeployURLExternalTask.java:133)
 at com.interwoven.ui.teamsite.workflow.task.URLExternalTaskCommand.execute(URLExternalTaskCommand.java:109)
 at com.interwoven.ui.base.impl.command.CommandHandler.doExecuteCommand(CommandHandler.java:915)
 at com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandDescriptor(CommandHandler.java:748)
 at com.interwoven.ui.base.impl.command.CommandHandler.tryRunForward(CommandHandler.java:645)
 at com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandID(CommandHandler.java:589)
 at com.interwoven.ui.base.impl.command.CommandHandler.runCommandLoop(CommandHandler.java:228)
 at com.interwoven.ui.base.impl.command.CommandServlet.doGet(CommandServlet.java:163)
 at com.interwoven.ui.base.impl.command.CommandServlet.doPost(CommandServlet.java:263)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
 at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445)
 at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
 at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
 at com.interwoven.ui.base.impl.command.CommandServletMapper.doGet(CommandServletMapper.java:90)
 at com.interwoven.ui.base.impl.command.CommandServletMapper.doPost(CommandServletMapper.java:108)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at com.interwoven.ui.base.impl.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:203)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at com.interwoven.ui.base.util.SetRequestEncodingFilter.doFilter(SetRequestEncodingFilter.java:106)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
 at java.lang.Thread.run(Thread.java:619)

Find more posts tagged with

Comments

Rick Poulin

So what do we want? To give the deployment rights to a group (and/or role) and add users to that group. The same way as other rights work (or another way) to give all current and future TeamSite users the rights for OD. Can anyone point me in the right direction?

You can't add OD permissions to groups, only users. So it sounds to me like you want to grant the od-admin role to a select few, which will manage the od-user list.

Making owner of the workflow deploy task a default OD user/admin will work as well. However that way we won't (easily) be able to see who did the deployment and kick that persons'**** if there's a mistake.

This is exactly what I usually do for my deployment tasks.. make the owner SYSTEM (wintel) or root/iwts ('nix). Since we're talking about a workflow, you should still be able to tell which user triggered it by looking at the job's creator or the job's comments or the job's history or...

Wolfwood

This is exactly what I usually do for my deployment tasks.. make the owner SYSTEM (wintel) or root/iwts ('nix). Since we're talking about a workflow, you should still be able to tell which user triggered it by looking at the job's creator or the job's comments or the job's history or...

Sounds workable. Smiley Happy

But don't the job's disappear after they are completed? How do you (quickly) get a list back with the completed jobs and their creators etc.

test_modified.rptdesign

bagman

Sounds workable.

But don't the job's disappear after they are completed? How do you (quickly) get a list back with the completed jobs and their creators etc.

How did you retrieve that info before?

According to iw.cfg.example:

## If set to false, workflow engine will *not* delete jobs from the
## backing store upon completion, and they can be retrieved using
## iwgetwfobj CLT and deleted using iwrmjob (but not searched against).
## Default is true.
delete_jobs_on_completion=false

However, I have mine configured this way and it does not appear to work.

In implementations I've worked on, we have added an audit task to the end of each job. This task can be as simple as an XML dump of the workflow spec to a file that you can parse or extract what info you need from the job spec and put it in a database.

Just some ideas...

Mark

Wolfwood

[QUOTE=bagman]How did you retrieve that info before?
By looking at the OD logs.

In implementations I've worked on, we have added an audit task to the end of each job. This task can be as simple as an XML dump of the workflow spec to a file that you can parse or extract what info you need from the job spec and put it in a database.

Thanks, that's an idea that might work. I'll suggest it here. Smiley Happy

But it's still a lot of extra work. It's so annoying that something was working just fine in a previous version brakes after an update. I want it to work as it was before..

Adam Stoller

Making owner of the workflow deploy task a default OD user/admin will work as well. However that way we won't (easily) be able to see who did the deployment and kick that persons'**** if there's a mistake.

So what do we want? To give the deployment rights to a group (and/or role) and add users to that group. The same way as other rights work (or another way) to give all current and future TeamSite users the rights for OD. Can anyone point me in the right direction?

In the ODHOME/etc/deploy.cfg file - look for

Deploy.cltProxyAuthCheck

and see whether it's set to "y" or "n". If it is currently "y" - try changing it to "n", restart the OD service, and see if that works for you.

Alternatively - learn how to use the iwodauthorize CLT - you could wrap a script around it that takes (among other parameters) a group name, expands it into a list of users into a file (one userid per line) and then invokes iwodauthorize with the appropriate parameters to set it up for you.

Also - if you want to automate the process within the workflow itself, you could have your deployment process check (on failure) what the cause of the failure was, and if it was something like "PERMISSION_DENIED" (I don't remember the exact string) you could then have the script transition to another task (owned by an od-admin) that retrieves the owner of the deployment task and runs iwodauthorize for them and then transitions back to the deployment task. A lot of moveable parts, but it should work. However, I'd opt for one of the other two suggestions first.