DCR links in email

I have 5 DCRs that need editing and reediting over the life of a project. In my first <grouptask> I am attaching the DCR's with the <files> tag.
I do not clearly understand:

1. Is there a CCI link to edit DCR's? (I only see a command for a new DCR)
2. How do I get these 'attached' files into the email?
3. If I create a link manually, will saving the DCR automatically proceed to my next workflow task?

Thanks in Advance.

Find more posts tagged with

Comments

Adam Stoller

If the grouptask is a start task - using <files> will work.
If the grouptask is NOT a start task - you cannot use the <files> element.

If the files are already associated with the job and you use one of the existing email scripts (iwsend_mail.ipl / iw_solutions_mail.ipl) then the links for the files should automatically be included in the email - otherwise you need to code your own solution using similar methods.

Note the files aren't "attached" - they're represented with CCI URL's.

Saving the DCR will not automatically cause the workflow to transition to the next task - if you look through the workflow forums you can find some posts from Smitty (about 4-6 months back I think) where he talks about how he managed to create links in his email to cause the transition to occur - but without going into a lot of customizations the user will have to go to the GUI and select an option from there.

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

summergs

Thank you very much for clearing that up for me.

Migrateduser

Just to follow up on ghoti's reference to my solution for providing links in emails for transitioning to the next task in a workflow, the best way to do this appears to be using a 6.x CCI link - I did this with the iw_solution_email.ipl script. The only drawback I found was that if the user clicking on the link isn't already logged into TeamSite - and I'm not sure if having a TeamSite window open is enough, as I don't understand cookies and all that stuff - it will pop up the TeamSite login window and force you to login. I don't like that part, but if it's not painful for your users, it's a small price to pay.

Had I won an iPod, I would have written an article about how to do this. Smiley Happy

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

summergs

I was just looking for your post(s) regarding this. Am I to understand that it is not possible using 5.5.2?

Migrateduser

I don't think it is. The CCI links provided in 5.5.2 are not robust enough to do what we want to do here. I think you'll have to take the plunge into 6.x in order to be able to pull it off. The whole CCI interface really evolves into something useful in 6.x.

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

summergs

Actually, I am totally puzzled by this. Since saving a DCR does not transition to the next task, how does the approver get the DCR/notification?

Migrateduser

I don't know. My thing has nothing to do with DCRs.

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

summergs

Can anyone enlighten me?

Dwayne

Tasks would transition in one of two ways, typically:

The user clicks on the "done" link in their To Do list, which transitions the task.
The user is provided a "transition task" link in the email they were sent, which does the same thing.

Transitioning a task automatically on saving a DCR would generally not be a good idea, for a number of reasons.

There may be more than one file associated with the task. Which save causes the transition
A user might want to save their work in progress, then come back later to complete it
A user might need to generate the file, which they can't do until after they save the DCR

Current project: TS 5.5.2/6.1 W2K

summergs

Thanks for your input. What happens in the following case:

Five DCRs exist. Each DCR is used for datadeployment upon approval, and should deploy independant of the other DCRs. Additionally, each of these DCRs can be edited and deployed many times during the life of the workflow. The life of the workflow is ended by an external task database flag. In other words; a workflow can exist for one year. During that year a DCR can be edited, approved, deployed 1000 times.

Does this mean I have to have a workflow for each DCR?

Thanks in advance.
Glenn

Migrateduser

You *could* write a workflow that was a big loop that would do this, but it's not clear to me what the value in that is, rather than initiating a new workflow for each edit-approve-submit-deploy cycle. But to the core of your question, yes, you do want each file attached to a distinct workflow if you want them to be approved and deployed separately from each other.

Dwayne

Given that each DCR's deployment is independent of the others:

It would probably be easiest to have five separate jobs. They can all be instantiated from the same workflow template, but five separate instances. You could certainly construct a workflow with five parallel paths, each of which contained one of your DCRs, but that seems very cumbersome and difficult to maintain. If the number ever changed, so that now you had six DCRs to manage, you'd need to completely recode your WFT file, kill the old job, and start a new one. If you just attach one DCR to each instance of the workflow, then adding (or removing) DCRs from this process becomes simple.

You can still use your database flag to trigger all of the jobs to terminate. They'd just all be reading that same flag. But another advantage of separating them would be that you could have "groups" of jobs, each controlled by a separate "flag." Just specify in a job (or task) variable what database table/column to monitor, rather than hard coding it.

--

Current project: TS 5.5.2/6.1 W2K

summergs

Thanks for the input. Does anyone know if it is possible to write the contributors/approvers to a database then as a TT_ DATA calls a workflow, retrieve the approver info from the database to instantiate the workflow?

Dwayne

Well, the WFT instantiation code is just perl, so if you've got the appropriate DBI Perl module installed and configured, you should be able to read a table to instantiate the job.

The question really should be: how do the contributors/approvers get WRITTEN to the database in the first place? These sound like workflow-related terms to me, implying that the DCR is already attached to a job. If that's the case, then the 'tt_data' command will never get invoked. If the DCR is already associated with a running job, TeamSite doesn't give the user a chance to associate it with a second job via the 'tt_data' method.

If you've already got the DCR associated with a workflow, then what's this new workflow supposed to be doing with it?

--

Current project: TS 5.5.2/6.1 W2K

summergs

That is interesting as I did not know that. What I was thinking is that I could have an author assignment.wft write the contribs/approvers to a database then end. Then as each DCR is saved, dynamically pick up the approver info from the database (as a seperate workflow) do the approval, deployment, then end. If I could do this, I would not have dangling workflows. Sounds good if I could figure out if it is possible or how to do it!

Dwayne

I think I understand what you're after. So this would replace the old workflow you were describing that would run forever until the flag was set in the database. If that will meet your needs, I certainly think the approach with the "short lived" jobs makes more sense.

I'm not sure that you need to save the contributor, though. Since this will be kicked off as the result of a 'tt_data' command after saving a DCR, wouldn't it make sense to assign the user who just saved the DCR as the contributor?

As far as the actual process of extracting the data from the database goes, take a look at perldoc DBI for information on the "standard" method of accessing a database from Perl. If you have questions on it, I would suggest asking in the Perl forum.

--

Current project: TS 5.5.2/6.1 W2K

summergs

I agree, I can just use the iw_user as the contributor. The Approver is what I need.... reading and writing to the database is not a problem for me. However, I do not understand how to put the Approver into the workflow dynamically as a result of the tt_data instantiating the workflow. Anyone have any ideas?

Adam Stoller

User Perl DBI code within the WFT to access the DB and retrieve the previous reviewer for the file(s) associated with the job being instantiated - if you get a value back from the DB - use it, otherwise prompt for a new reviewer (and then store it into the DB for the next time)

Then you can use __INSERT__() within the WFT whenever you need to assign the value of the reviewer to the owner of a task.

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

Dwayne

If you know how to get the approver's username from the database, then it's easy. If we assume that the approver's username is stored in a variable named $approver, then your WFT file just needs to contain a snippet like:

<usertask name="Review" owner="__INSERT__($approver);" description="..." ...>

--

Current project: TS 5.5.2/6.1 W2K

summergs

Ahhhhh! Thanks!

summergs

Problem. In order to acquire the approver from a database, it appears that I would have to have the start task as the external task to do this. However, I need to attach the DCR being submitted. TeamSite is stating that the <files> tag MUST be in the first task. Any ideas??

Thanks!

Dwayne

Why do you need an external task? That __INSERT__ logic that I talked about before goes in the WFT file, outside of any task. You read the database to get the value from inside a <template_script> tag in the WFT, then use that in setting the owner of the approval task. No external task required.

However, if you DID need to start with an external task, that's not a problem. You can put a <flies> </files> section in an external task just as easily as in a user task. The list of attached files "moves" with the execution flow of the job. That is, if you've got an external task which transitions to a user tasks, then when that external task does the transition, any files associated with it will become associated with the user task automatically.

--

Current project: TS 5.5.2/6.1 W2K

summergs

Am I to understand that template_script (before the tasks) will run the perl BEFORE the first task is started?

nipper

>Am I to understand that template_script (before the tasks) will run the perl BEFORE the first task is started?

Yes, but

It actually runs twice before the user input is entered, then again after. If you log
to a file (/tmp/WF_$$) you will notice double entries.

Did not really affect the way I coded, however it sure confused the heck out of me
until James Koh explained why it had to work that way.

Andy