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

TeamSite 6.x URL Commands (CCI Links)

System

I've recently installed TeamSite 6.1 and am happy with most of the improvements to the URL Commands over the way they were in 6.0. The addition of the done_page parameter is very helpful.

That being said, there are still some issues:
1) The biggest issue for me is the taketask Command. It just drops you in the job interface and the user has to search for the "Take" link in order to take ownership. The way it used to work (5.5.x) is that the taketask CCI would actually take the task and leave the user at a blank window. Although, not perfect, it was better than the way it's currently working. The BEST solution from my point of view is to actually take the task for the user (as soon as the taketask link is clicked) and then redirect them to a page provided in the done_page parameter. This gives the developers the ability to choose to give the end user feedback or just close the window. One of the built-in done_pages needs to be able to give feedback to the user as to whether the take task was successful or not.

2) Bug #52886. done_page=/iw-cc/teamsite/common/close_window.jsp doesn't work perfectly. When the user clicks done, or transitions the task, the IE security kicks in. It tells you that the page is trying to close the browser window and asks for confirmation. I've filed the bug and have offered the following fix to Interwoven: Before the window.close() call in close_window.jsp, add the following JS - top.window.opener='';

The fact remains that the URL Commands need to be designed to be used independant of the TeamSite UI. The whole reason to use the URL Commands is to keep the end user from being exposed to the UI. Dropping them into the UI to take task by searching the page for a little link that says, "Take" doesn't solve our issue. I have custom coded a work-around and am glad to share it. Send me a private message if you need it.

- Jason

Find more posts tagged with

Comments

Migrateduser

I think the take ownership CCI should have an option to lock all files associated with the task to the user taking ownership if they are not already locked to another user.

Migrateduser

>> 1) The biggest issue for me is the taketask Command. It just drops you in the job interface and the user has to search for the "Take" link in order to take ownership.

I don't think this is the case. If it is, then it's a bug. Yes, it should be dropping you in the UI, but no you shouldn't have to click "take" link. It should have already been taken for you, and ready for you to work on the task.

Todd

Dev. Mgr., CCS and UITK

Migrateduser

> I don't think this is the case. If it is, then it's a bug.

Then it's a bug. It definately drops you into the task details screen.

- Jason

Migrateduser

Right, I'm not saying it doesn't drop you into task details. I'm saying that it takes the task and then drops you into task details. So there is no need for the end-user to find the take task link to take the task.

Dev. Mgr., CCS and UITK

Migrateduser

> I'm saying that it takes the task and then drops you into task details.

Negative. You MUST press "Take" for it to take task. However, I don't like the fact that it even drops you into the UI. What's the point of URL Commands if all they do is drop you in the UI? I think the solution for take task was better in 5.5 and it just left you at a blank window, but at least it took the task. Like I said earlier, the "correct" solution is to take the task and give the user feedback as to the success or just close the window (up to the TS Admin/Developer). Dropping my users into the UI completely undermines the purpose of URL Commands. I ended up writing a JavaScript to monitor the iw.ccstd.take_task command. Which does actually take the task instantly, but still takes you to the task details page. Would prefer that you guys just make it more like the way it was in 5.5.x so that we don't have to rewrite our email notifications, and come up with hacks using JS to get the desired effect.

Anyway, I'll get off my soapbox now.

- Jason

Migrateduser

Jason,

You're operating from a faulty premise. The public URLs for ContentCenter are not intended to be "URL commands". They are simply entry points into the ContentCenter interface. They allow you to link to a specific part of the UI so that you don't need to navigate to that particular area. They are not intend to hide or replace the standard UI. If you just want the raw TeamSite functionality then you can use the CS SDK or one of the other APIs.

This is a major change from the "CCI" URLs in WebDesk which -- to a large extent -- let a casual user bypass the standard UI.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

Brinko,

So, what you're saying is that CCI's were designed to allow us to put links in our emails to complete specific pieces of workflows or to get information about files or other misc. functions of TeamSite, but URL Commands are designed to drop the user into the TeamSite UI and force them to use the UI? Doesn't that seem like a step backwards? I realize that you guys are proud of your new UI's and everything, but I'm not sure that cramming it down our throats is a productive thing to do.

As developers, we can custom code CCI's using CGI and CLT's. I can create a CGI that performs a taketask and gives exactly the feedback I want the users to see. Why can't you make that available (like it was in 5.5) so that I don't have to custom code it? Why is it that every other URL Command that I've tested works pretty much the way it did in 5.5? Why is it that you have a special transition JSP for the transition URL Command, but you couldn't do the same for taketask? For the transition URL Command you could have just plopped the user at the task details page too, but you didn't. There must be a reason. Either there's an disagreement about the way URL Commands should work or someone screwed up and doesn't want to admit it (this is my guess).

In any case, even if your goal was to take the end user to the task details page with the taketask URL Command, it still needs to actually take the task before absent-mindedly dropping the user into the UI. I hope that we can at least agree on that.

If you are saying that Interwoven will not be creating a user-friendly taketask URL Command, then I'll be coding one up and distributing it freely here on DevNet. I'm pretty sure that everyone that setup their email notifications in 5.5.x (to prevent users from needing to be exposed/trained on the UI) will not want to expose/train the users on this small aspect of the UI.

Anyone want to back me up? Smitty? John?

- Jason

Migrateduser

Actually, Jason, I was somewhat agreeing with your point that, "Dropping my users into the UI completely undermines the purpose of URL Commands." It would if these were URL commands. But they are not.

As Todd indicated earlier, the intent of the take task URL was to take ownership of the task and then display the task details. If it is not doing that, then -- as he said -- there is a bug in that URL.

The main reason for the change from 5.5 is that (according to our usability studies) most users was to have some kind of confirmation after taking any action. So, for example, after taking ownership of a task they want to see that they are now the owner of the task. I can certainly understand that this extra verbosity would seem to be a step backwards to a power user.

It would also have been possible to create some kind of separate UI element for each URL, like a "take task confirmation page". But each of these pages would have to be developed, translated, documented, tested and maintained separately from the standard pages. And that probably isn't where most of our customers would like us to be expending our efforts.

Besides, what is the user going to do after taking ownership of a group task? Go home and celebrate? Most likely that user is then going to do something else with the task, like review or edit its files. It is not practical for us to build all of the task-related functionality into an email message (due to the vagaries of multiple email clients), hence we send the user to the task details page.

I encourage you to share solutions that you have developed for your specific needs with others. That is one of the purposed of DevNet.

Brinko Kobrin
Interwoven Staff Engineer

Adam Stoller

It might be nice if the URL could take an optional additional parameter (like the done_page one) such that, by default it would do what it is [supposed to be] doing (taking task and then redirecting to task details page), but optionally one could have it redirected elsewhere (like to a CGI that sends email and provides a customized UI to preesnting the task details or some such).

Just a thought (I haven't been using too many of these URLs yet)

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

Migrateduser

> It might be nice if the URL could take an optional additional parameter (like the done_page one) such that ...

I believe that this is the purpose that the optional done_page parameter is intended to server, but I have not used it much myself and I don't know how many of the public URLs support this parameter.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

Of course I agree with Jason here. This is why I stick with a CGI to handle my email links rather than calling any of the CCI URL's directly. In the case of a grouptask, my users don't give half a **** that they need to take ownership of the task - they just want to perform the task operation. So when an email is sent out to the owners of a grouptask, the link embedded in my email doesn't say "Take Task" - that's crazy. Instead there are separate links for each successor option in the grouptask. When they click on one of those links, it calls my CGI which recognizes that the task is a grouptask, then automatically takes the task using the CLT to do that, then performs the chosen successor. No TeamSIte UI pops up. It just does the right thing. And if someone else tries to click on one of the links in their email after someone else did, instead of getting a TeamSite pop-up with an error message, my CGI sends them a nice email telling them someone else already acted on the task. Like Jason, I would rather at least have another option in a CCI URL that didn't pop up any TeamSite windows. I'd also like to have better options on grouptasks that would essentially perform the "take task" and also perform the chosen successor option in one fell swoop. My users don't want or need a 2-step process. All they want to do is execute one of the task successor options. I think "Take task" should be optionally hidden anyway - to me it serves little purpose. I can see where someone might want to take ownership of a task then think about it for a while to ensure that no one else in the group acts on the task in the meantime. We don't use grouptasks like that. As soon as someone is able to, they just act on the task, so the "take task" step is really just a nuisance.

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

Migrateduser

> Actually, Jason, I was somewhat agreeing with your point that, "Dropping my users into the UI completely undermines the purpose of URL Commands." It
> would if these were URL commands. But they are not.

Brinko,

What in the world are you talking about? How is the taketask not a URL Command? It's clearly documented in the UICG 1.1 on the top of page 97, in the chapter titled "Using URL Commands." It really bothers me that Interwoven folks are so confused on the purpose of URL Commands (formerly CCI Links) and which commands are URL Commands. The purpose of CCI links (for almost everyone) was to provide functionality within email notifications. These links were originally intended to complete very specific tasks, nothing more, nothing less. You say that URL Commands are not intended to replace CCI Links, but if that's true, why is there a section in the UICG that covers "Legacy URL Commands" which are all exactly what used to be known as CCI's?

I agree that most users do want some sort of feedback after taking a task (unless you do it Smitty's way and don't even make the user know anything about taking the tasks.) I don't think that dropping them in the UI is the right approach and I think that most customers would appreciate you writing one more page (and translating it) to cover the taketask command so that it works the way I described in my earlier posts. I definately don't think most customers would say that one more page, out of the thousands, would make much difference in cost compared to having to write our own taketask CGI to accomplish the same thing.

I'm just asking for some hint of consistency. Every other URL Command works very similarly to the way its corresponding CCI worked. Why are you so reluctant to make the taketask URL Command that way as well? Another option which would be ok (this is based on Smitty's posting) is to give the option for the task to be automatically taken when it's a group task and the user clicks the transitiontask URL Command. That would be acceptable for me, but I'm sure there's some that wouldn't care for that.

- Jason

Migrateduser

I think what Jason's post shows is that, taking a quote from Larry Wall, "there is more than one way to do it". Meaning while Interwoven's intentions are often good, they very often don't see the bigger picture when it comes to how customers use the tools. It always bothers me when Interwoven cites "many companies" in their excuses for doing things a certain way. What I'd like to see is much more flexibility in the tools. Provide options so that people can use the various URLs in different ways. To Interwoven I say take these inputs and bring some better tools to our tables rather than just stick to your guns and say this is how "many companies" want it to be so the rest of you just have to deal with it. Some companies want to utilize the out of the box UI. Some don't want to utilize the out of the box UI at all. Some are in the middle. Make the tools work for all of us. There can not possibly be a clear majority.

Also, to back Jason's main point here - you can't call something a URL and then say it's not a URL. Or is this another case of the engineers not being on the same page as the marketing folks and the documentation team? Who's running the ship over there?

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

Migrateduser

> You say that URL Commands are not intended to replace CCI Links, but if that's
> true, why is there a section in the UICG that covers "Legacy URL Commands"
> which are all exactly what used to be known as CCI's?

In order to make a smoother transition to 6.0 from earlier versions of TeamSite, the old CCI URLs were mapped into the corresponding functionality in ContentCenter. This is not to say that the new public URLs are exactly the same as the CCI URLs. They are not.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

Brinko,

Your short reply indicates to me that I've worn you out with this debate. I tend to do that to people when I really care about what I'm debating about.

My last request is that you put more flexibility into the URL Commands. Stop being so rigid and saying things like, "These are different than CCI's." I don't want them to be different. A lot of people don't want them to be different. Once more people start moving to 6.1, I'm sure that more people will reply to this post in support of what I'm saying.

- Jason

Migrateduser

Jason,

I am not attempting to debate anything with you. I was attempting to reply to your question, "What in the world are you talking about?"

> My last request is that you put more flexibility into the URL Commands. Stop being so rigid and saying things like, "These are different than CCI's." I don't want them to be different.

I'm sorry that the URLs do not do exactly what you want. I am not trying to be rigid. If you would like to see new features in our products, then please send your request to Interwoven Support. They can then associate the customer with the request.

I am not attempting to debate our current design or negotiate on future features. My main purpose in responding to questions on DevNet is to help developers and users make the most of our current products. And I have strong evidence to support that have been helpful on many occasions. Sometimes my explanations of current functionality help users to better understand the product. But other times, unfortunately, they seem to elicit contentious tirades.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

Brinko,

You replied to one of the many questions that were raised in the "What in the world are you talking about?" reply.

It shouldn't be a feature request. It should be a bug. Dropping the user into the interface with these URL Commands isn't right. Especially for something so simple as taking ownership of a task. I can understand your point about the user needing to do something after taking ownership, but I don't think that justfies leaving the user in the UI as the only option. I think it's a bug/design flaw. But, at the very least, make it actually take ownership of the task.

I never said that you're not helpful. I don't know why you felt the need to defend yourself about that. I'm just saying that you're being rigid about this particular issue and I'd like to add that you've also made false premises (such as taketask is not a URL Command and URL Commands are not meant to replace CCI Links). If you'd like to defend against that, I'm interested in listening. If you're going to talk about other people that you've helped, that is not in debate. I'm completely certain that you've helped a lot of people.

- Jason

Migrateduser

Brinko, I think a lot of the frustration from the customer side is based upon what we've been led to believe we are going to get by marketing folks as opposed to what we eventually actually get. There are sometimes misleading or just plain wrong promises made by marketing about what functionality will be available in future releases. Then when we find out that some of the promised features don't work exactly the way they were advertised, it causes a lot of frustration, sometimes more than a lot. There seems to be an admitted divide at times to what marketing thinks will happen and what the developers are actually making happen. That's bad and should be something Interwoven takes very seriously. I have been burned enough times by marketing folks that I will no longer listen to anything they say about specific features coming out in future releases. I would much rather talk to you or Ariel or any of the great engineers about what's really happening. That's why I'm so upset about losing the focus groups. And maybe that's also why marketing stopped the focus groups.

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

Migrateduser

> It shouldn't be a feature request. It should be a bug.

If by "it" you are referring specifically to the taketask URL, then I agree with you. Otherwise the URL is no different than the viewtaskdetails URL. It has been filed as bug #52931. If you would like, you can contact support and have them associate your customer with this bug.

> I'd like to add that you've also made false premises (such as taketask is not
> a URL Command and URL Commands are not meant to replace CCI Links).
> If you'd like to defend against that, I'm interested in listening

I stand by what I said, and I have already given my explanation. I see no value in rehashing that particular topic.

Brinko Kobrin
Interwoven Staff Engineer

Grundy

> I believe that this is the purpose that the optional done_page parameter is intended to server, but I have not used it much myself and I don't know how many of the public URLs support this parameter.

Gotta throw in my two cents on this one, because I have a copy of the slides from the TeamSite 6.1 webcast just a few weeks prior to its release which states that all URL commands will accept the done_page parameter.

But I've already found by experimentation that the logout command does not accept this parameter, and your statement suggests that engineering didn't necessarily plan on having all commands accept it in the first place.

Also, you stated earlier in the thread that the public URLs should not be thought of as "URL commands". But as Jason pointed out, they are documented in a chapter in the UICG entitled "Using URL Commands".

So you can begin to see why your customers are confused and frustrated. I'm not trying to make a big deal about the logout command or any other feature in particular. We can debate forever about how the product "should" function with respect to ease of use versus flexibility, or what should happen by default versus what is accomplished by workaround.

But I think everyone will agree that as a minimum, the product should at least function as advertised. I don't expect perfection -- every product has bugs to be worked out and testing can't cover every possible scenario. But it does alarm me when I open a support case relating to some functionality that marketing, documentation, etc led me to believe was there, and am told "that isn't supported" rather than "yeah, that's a bug, we'll need to fix that".

So just take this as a second to Smitty's plea for consistency. Customers will look for alternatives if they can't be reasonably sure about what they're getting.

nipper

>But I think everyone will agree that as a minimum, the product should at least function as advertised. I don't expect perfection -- every product has bugs
>to be worked out and testing can't cover every possible scenario. But it does alarm me when I open a support case relating to some functionality that
>marketing, documentation, etc led me to believe was there, and am told "that isn't supported" rather than "yeah, that's a bug, we'll need to fix that".

& what planet are you from ?

Obviously you haven't been here very long.

BTW, you may also hear those memorable words, yes it is a bug, in the documentation. Love those.

Andy

Grundy

Yep, I'm an idealist. No argument here.

PaulW

brinko.

Is it also a bug that the done_page command seems to be ignored for this and the other task related commands?

even thought I put the done_page value in the URL - on close or approve or reject - I get redirected to the CCPro UI. If i click on the following URl and just click close when the page opens - i get redirected to CCPro UI.
http://server/iw/webdesk/taketask?taskid=226423&done_page=/iw-cc/custom/index.jsp

The close button url has become:
http://server/iw-cc/command/null?customer.done_page=/iw-cc/custom/index.jsp&customer.full_redirect=true&done_page=/iw-cc/ccpro/workflow/update_handler.jsp%3fcustomer.done_page%3d/iw-cc/custom/index.jsp%26customer.full_redirect%3dtrue%26taskid%3d226423&full_redirect=true&taskid=226423

Also - if i click the URL within the email then manually click take task link then click close. I occasionally get an error saying that "false" is not a valid command descriptor. I realise th eTake Task issue is already a bug - But should I raise a bug/support case for either of these other 2 issues?