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

URL commands oddity

Lex

I've written a custom web app that uses some of the custom URL commands supplied with ContentCenter. The URL commands work fine for me and other users - they perform exactly the way I would expect them to. However, some users who have tested the web app get an extra window (when using the "submit" command) and a window that won't close (when using the "newjob" command).

Regarding the extra window with the "submit" command
Here is an example command URL: http://teamsite.weyer.com/iw-cc/submit?vpath=/default/main/Internal/Intranet/20yearclub/WORKAREA/20yearclub/templatedata/site/site administration/data/siteinfo&iw_sessionstring=[...]

When I use this URL it goes straight to the workflow selection screen where I can choose which workflow to use for submission. However, some users get an intermediary screen where you can choose to "Submit", "Submit Additional Files" or "Keep as Work in Progress" as well as create a new job or add it to an existing job. Once complete, they get a "Submission succeeded" screen with a checkbox allowing them to add the file to their "My Favorites" and a "Done" button. The worst part is that if there are multiple files submitted using a URL like this, it works fine for me, but for these other users it strips off all but the first file and only submits that one. I cannot for the life of me figure out why they get these extra screens and I do not. Obviously I would prefer that they do not get these screens.

Regarding the window that doesn't close with the "newjob" command
Here is an example command URL: http://teamsite.weyer.com/iw-cc/newjob?vpath=/default/main/Internal/Intranet/20yearclub/WORKAREA/20yearclub/templatedata/site/site administration/data/siteinfo&iw_template_file=wfb/Intranet_Delete.wft&iw_sessionstring=[...]

When I use this URL it fires off the job and the window closes. However, some users get a window with the message:

[highlight]Operation Successful
The operation has completed successfully but was unable to close this window. Please close it manually.[/highlight]

And it has "Next >>" and "Cancel" buttons on it which is thoroughly confusing to the users. I would prefer that they not see this window.

In both cases I have specifically not assigned a done_page because the windows opened are new ones and I want them to close when the command is complete. I've gone through the IE settings and compared mine to these users hoping to find some difference, but they are identical. Does anyone have any idea what could be causing the difference in the way these URL commands behave? Thanks.

Find more posts tagged with

Comments

Lex

Update: I've had several users test it and out of 10, only 3 are experiencing the issue of the extra screen and the window that won't close by itself. Very odd.

Lex

Update #2: I've done a little more testing and I've narrowed this down to a user-specific issue, but I still have no idea what the actual issue is. I went to the PC of one of the users experiencing this extra "start job" screen and, with the user still logged on as themselves to the local box, I opened and logged on to the web application. I still do not get the extra screen when using the "submit" command URL and the window properly closes when I use the "newjob" command URL. So my theory that it was an IE setting or JRT difference is shot.

I decided that rather than opening the command URLs in a new window I would just open them in the same window and use the "done_page" querystring parameter to redirect the user to the default page of the web application I wrote. This works fine for me, but for these other users (and this is where it gets really odd) it takes them back to the CC Standard UI on the TeamSite server! Wha...? The "done_page" parameter specifies the URL of my web application and yet they are taken to a completely different page on a different server! What on earth could possibly be causing this? I am truly baffled.

jbum

Lex,

We've previously encountered this error when using Firefox. IE and firefox behave different with using window.close(). Please confirm what browsers the 3 out of 10 users is using. Hopefully, it's as simple as that.

John

Lex

Lex,

We've previously encountered this error when using Firefox. IE and firefox behave different with using window.close(). Please confirm what browsers the 3 out of 10 users is using. Hopefully, it's as simple as that.

John

Hey, thanks for the reply. Unfortunately (or fortunately, depending on how you look at it) we have a corporate standard of IE6 for all browsers and, indeed, these users are all using IE6.

The part that continues to baffle me is that if I walk over to one of the user's PCs with them still logged on to it and log on to the web application as myself, I do not see the extra screen when submitting - it goes straight to the workflow selection screen. I also do not get the window that remains open and won't close.

I have a case open on this, but now this issue is holding up us rolling out this web application to the entire company for use in maintaining our intranet sites. I really hope we can get this resolved soon. Thanks again.

jbum

Hey, thanks for the reply. Unfortunately (or fortunately, depending on how you look at it) we have a corporate standard of IE6 for all browsers and, indeed, these users are all using IE6.

The part that continues to baffle me is that if I walk over to one of the user's PCs with them still logged on to it and log on to the web application as myself, I do not see the extra screen when submitting - it goes straight to the workflow selection screen. I also do not get the window that remains open and won't close.

I have a case open on this, but now this issue is holding up us rolling out this web application to the entire company for use in maintaining our intranet sites. I really hope we can get this resolved soon. Thanks again.

I'm currently working on this support case that was filed. To address the "extra" screens, it's due to the fact that some users are logged in CCPro versuse CCStd. They behave differently and that is what you are seeing.
CCStd has a wizard like series of steps the user goes through. CCPro is more direct and only has one screen.

As for the window not closing, it's due to the way the "done page" is calculated. When no done page is specified (Content Center always specifies it), it will default to the "window close" mode for your use cases.

In the case of a CCPro UI, this works fine. In CCStd, I believe the code trying to close the window sits inside a frame and cannot close itself. That in itself is a bug.

Nothing you're seeing is really a problem. You may want to figure out if you indeed intentionally made some users CCStd users or not. That's the real issue at hand.

Lex

I'm currently working on this support case that was filed. To address the "extra" screens, it's due to the fact that some users are logged in CCPro versuse CCStd. They behave differently and that is what you are seeing.
CCStd has a wizard like series of steps the user goes through. CCPro is more direct and only has one screen.

As for the window not closing, it's due to the way the "done page" is calculated. When no done page is specified (Content Center always specifies it), it will default to the "window close" mode for your use cases.

In the case of a CCPro UI, this works fine. In CCStd, I believe the code trying to close the window sits inside a frame and cannot close itself. That in itself is a bug.

Nothing you're seeing is really a problem. You may want to figure out if you indeed intentionally made some users CCStd users or not. That's the real issue at hand.

Ah, good...I suspected the difference was between CCPro and CCStd. The thing is, some of these users have never logged on directly to the TeamSite server. All of their access is via the web application I wrote. There doesn't seem to be anywhere I can specify which UI to use via the web service methods exposed in the AccessServiceBinding object. I use beginSessionUsingPassword the first time a user signs on and then store the session string value in a cookie to use with beginSessionUsingSessionString on subsequent uses (I know, hardly a secure method since anyone who gained physical access to a PC would be able to log on to the web app, but there's not much damage that can be done). Neither of those methods allow me to pass a parameter indicating which UI should be used so I think it's just defaulting to CCStd on the TeamSite server itself. If there were some way I could flag all these users as CCPro users I'd be golden, but we're on 6.5 SP3 and it doesn't support setting up local users on the TeamSite server. It's not really a very workable solution, but would having the users log on to the CCPro UI prior to using my web app flag them as CCPro users somehow? Or is there another way to flag users on 6.5 SP3? Or am I using an outdated version of the CSSDK? I'm rambling now...

Bill Klish

Interwoven passes around a cookie called in_which_ui that has the value of ccstd or ccpro. I know it is not supported, but that is what we use to detect activity and then just default to ccpro if not.

Can you just set a similar cookie?

Lex

Interwoven passes around a cookie called in_which_ui that has the value of ccstd or ccpro. I know it is not supported, but that is what we use to detect activity and then just default to ccpro if not.

Can you just set a similar cookie?

Hmm, good idea. I found the cookie on my PC (dluther@teamsite.weyer[1].txt) that contains an entry for iw_which_ui, but there's more data in there than just ccpro:

iw_which_ui
ccpro
teamsite.weyer.com/
1088
1552787328
29893982
284569136
29889959

I checked with another user and the first 4 lines are the same, but the last 4 numbers are different so I'm not sure what would happen if I tried to set that cookie value myself, but I guess it's worth a try.

jbum

Lex,

Yes, you can use the iw_which_ui. Just pass this into the CCI url as a parameter like this (iw_which_ui=ccpro).

That should change it.

Lex

Lex,

Yes, you can use the iw_which_ui. Just pass this into the CCI url as a parameter like this (iw_which_ui=ccpro).

That should change it.

Oh man...I could swear I tried this before and it didn't work, but adding that query string parameter has removed the extra submission screen. Thank you! This is a major weight off my shoulders. We'll do a little more testing and I'll let Manny know to close the support case.

jbum

Awesome! Please make sure the change is permanent/persistent for the users after logout. Hope this works.

Lex

Awesome! Please make sure the change is permanent/persistent for the users after logout. Hope this works.

So far it seems to be working just fine. We've done testing with the users who were previously affected with the extra job submission screen as well as the window that wouldn't close when no "done_page" parameter was supplied and that's all working perfectly.

However, now the only item left is that the "done_page" parameter, when passed with an actual value, is not behaving as I expect it to. When I run the application locally, on my PC, passing "&done_page=http://localhost/contentcenter" properly redirects the browser window to the web application when the CCI URL command is done. However, when this same code base is moved to our development web server and I pass "&done_page=http://webdev.weyer.com/contentcenter" the browser window does not redirect to the URL and instead goes to "http://teamsite.weyer.com/iw-cc/command/iw.ui" (that's our TeamSite server). It's the strangest thing. I'm wondering if anyone would be able to suggest any troubleshooting steps we might take. Thanks!

Grundy

Here's a similar problem with a twist:

I'm using TS 6.7.1 on Windows Server 2003.

Like Lex, I'm building a web app that utilizes a URL command (import, in my case). And like Lex, I've run into problems with the extra screens involved when a user is logged in under CC Std, which can be addressed by adding the iw_which_ui=ccpro parameter.

The added complication for me, though, is that we do have some users who prefer to stick with CC Std, and some who prefer to stick with CC Pro. So the logic for my import step needs to be something like this:

Determine the user's current interface (ccpro or ccstd).
Call the import URL command, switching to ccpro as we go.
After the import is done, reset the UI to whatever was determined in step 1.
Call the next screen of my app.

Two issues are making this tricky right now:

My iw_which_ui cookie isn't getting populated (perhaps no longer used in TS 6.7.1?), so I don't have an easy way to determine the UI prior to calling launching import window.
Step 3 seems to require the use of a "dummy" URL command -- so I can pass it iw_which_ui and done_page and have it transparently reset the UI then return to my app. But I'm not finding anything like that in the documentation -- all URL commands seem to involve some kind of user interaction.

While I can probably find some kind of hack to deal w/ the second issue, it won't matter much if I can't determine the user's UI in the first place.

So...
Is it normal that I'm not seeing a value in my iw_which_ui cookie? Does TS 6.7.1 provide another way to obtain this info?

Are there any best practices (or even just "previously shown to work" practices) which might address my scenario in general?

Thanks in advance,
Nutt

Grundy

I've always simply used the server-relative part of the path for done_page, as in:

&done_page=/contentcenter

Have you tried that?