Modified By

Hi,
When files are modifed from teamsite GUI, the modified by column is not showing up correctly. From the command line its even worse that field has only one user name for all the files.
Environment is Teamsite 5.5.2 on Solaris.

Can anybody help me out?

TIA

Find more posts tagged with

Comments

pflory

herald10,
What do you mean, more specifically, when you say:

   
    the modified by column is not showing up correctly

?

What is it showing?

Paul Flory

herald10

lets say I modify it as user1 but its showing that field as modified by user2. thats the problem we are facing.

megamala

herald10

We are also facing same problem. Are you still facing this problem. Is it fixed?

thanks
Nagaraj

TIA
MM Guptha

herald10

megamala,
Please contact support. Currently some one else is handling that case at our site. so don't know the exact details. I will try to find out the details.

-H

Hamjam

Did anyone get to know why was this problem occuring??

HAM

Migrateduser

This really looks like a bug in TeamSite, but I don't think Interwoven has confirmed.

792038.txt

nipper

> This really looks like a bug in TeamSite, but I don't think Interwoven has confirmed.

& that surprises you because ?

Migrateduser

oh no, that doesn't surprise me at all - I don't bother contacting support, filing bugs or feature requests, or interacting with interwoven to any extent I can avoid. I just find a workaround, but in this case you just have to accept that any usernames you see on files in teamsite history or other UI should be ignored. It galls me because for legal compliance that info really has to be accurate, but even when it works as it "should" it still shows root/SYSTEM most of the time anyway, and anyway there's nothing that can be done.

AKB

Teamsite: 5.5.2 and also teamSite 6.1
I have tried changing files on Unix and also on NT and it works fine. In both the projects generation of files was automatic and initially iwui/root/System used to come as modified. Later while calling the cgi/ipl file I used the wrapper(iw_cgi_wrapper.cgi) and it works ok. On NT I had issues with the perl script extension (cgi). When I changed it to .ipl it works fine.

civ3

Hi herald10

We're facing the same problem. Have you found out how Interwoven fixed yours?

Regards,

smenon

If you execute Perl CGIs using the TeamSite Web Daemon and you create/modify any files in TeamSite using the filesystem, then the assets pick up the last modified user as the process owner that executed the script - in this case, it would have been the process owner of iw-webd; which is running as iwui on Solaris and SYSTEM on Windows. In order to impersonate the user who requested the CGI from the TeamSite UI, you have to use the iw_cgi_wrapper.cgi that will enable the impersonation by using the user credentials of the logged in user and the script will be run as that user instead of iwui or SYSTEM. This will give you the desired result of having the file modified as the user who requested the CGI.

thanks

--Sunil Menon
Product Manager
Interwoven, Inc.

Migrateduser

What about custom JSPs running in Interwoven's Tomcat? I mean, how can we set last modified correctly in Java?

AKB

Well I dont think there is a solution for that yet. (Menon might correct me). Need to come out with wrapper for JSPs Smiley Happy

smenon

If you have built your own custom JSPs, I am assuming that your servlet is talking to TeamSite using the CSSDK APIs - in which case, when you create a new file or modify an existing file using the APIs, the last modified user is set to be the logged in user. However, if you are planning on writing directly to TeamSite using the file-system, you will encounter the same issues with last modified user.

thanks

--Sunil Menon
Product Manager
Interwoven, Inc.

hessian

In TS 6.1 Windows, files generated by the wizard after a form is saved show "SYSTEM" as the "Modified By" attribute. Is there a "hook" into the wizard process where I can have the "Modified By" set to the ID of the person who saved the DCR? If not, could you suggest something else? Thanks!

Dwayne

I ran into this at one of my former client sites. This is from memory, so it may not be precise

As I recall, this problem ended up being a security conflict with W2K3, at least in their particular instance. I had to go into the policy editor, and grant "Log in Locally" access to the TS users. Well, actually to a group that all the TS users belong to, but it ends up being the same thing. Once I did that, the problem went away.

Many security people are going to have a problem with granting that sort of access. IMO it's not normally that big a deal, because, in most of the instances that I've seen, the average user doesn't have physical access to the server, so the ability to log in locally doesn't present a problem. This doesn't give them the ability to log in via Terminal Services.

There may be a more restrictive access that can be granted to solve the issue, but I was running out of time at that client, so I didn't have time to dig further into it.

Hope this helps.

--

Current project: TS 5.5.2/6.1 W2K

hessian

Thanks for the info. How does this change anything if it is the System is still generating the output HTML file from the DCR via the wizard? And would this still apply to 6.1 under W2K SP4? ?'s ?'s ?'s Hopefully Sunil or someone else from IWOV will chime in.

Dwayne

I think that what's happening is something like this:

hessian

It would be nice if the process runs as you think it might. If getting perms changed wasn't such a big deal around this shop I'd tweak it and throw it up against the wall and see if it sticks. But things like this aren't tweaked nonchalantly here, even on a DEV box, so I'd love it if Sunil or someone else form IWOV would chime in and confirm or deny that this approach is correct and worth pursuing.

Dwayne

Are any of the accounts that you have access to via TS members of the Administrators group? Probably not, based on your earlier statement, but, if they are, then that would be a further test - Administrators, almost by definition, have local machine access. So those users shouldn't have this issue, if I'm right.

--

Current project: TS 5.5.2/6.1 W2K