Fog Creek Software
Discussion Board




Only one user can integrate with Perforce?

I'm completely stymied. I set up Perforce integration just as indicated in the online documentation, and it works fine. For me.

I am a Perforce super and a FogBUGZ admin. The other chap in my office who is both these things cannot get the integration to work. His submissions never result in the proper links appearing in FogBUGZ records, while mine do so with no fuss, no muss.

The VB file on the Perforce server has full permissions for everyone.

I am by now means an expert administrator of Windows and would appreciate any help anyone could suggest.

Thanks!

Corey Reid
Tuesday, May 11, 2004

Can you add some error logging to the VB script?  See if it is getting called even?

Dim fso: Set fso = creatobject("scripting.filesystemobject")
Dim f: Set f = fso.opentextfile("c:\logfile.txt")
f.writeline "log stuff here"

f.close

?

Michael H. Pryor (fogcreek)
Fog Creek Software
Tuesday, May 11, 2004

Well, what we have worked out is that Perforce users who have set their password cannot get their clientspec via

p4 -p (server) -c (clientname) -u (username) client -o

So the attempt to set the bug report fails at that point since it later tries to use the clientspec to set the HOST.

Looking like a Perforce issue at this point. If anyone has any thoughts, glad to hear them.

And thanks!

Corey Reid
Wednesday, May 12, 2004

Is there a -p flag for p4? :)

Michael H. Pryor
Fog Creek Software
Wednesday, May 12, 2004

Yes there is. It specifies the server's listen address. The script makes use of it.

It's possible I'm misunderstanding your question. I do that a lot.

Corey Reid
Thursday, May 13, 2004

Nope, you understood correctly... I was making a joke that there should be a password flag too.. since there is a username flag, but I don't know if the trigger allows for passing the password through...

Michael H. Pryor
Fog Creek Software
Thursday, May 13, 2004

Yeah, I don't think we can even GET the password. It would be a little alarming if we could.

Now I can get the client spec if I just drop the -u flag with the username -- is there any reason to use that flag? If I just call

p4 -c (clientname) client

it works fine.

But I bet that -u flag is there for a reason, huh?

Corey Reid
Thursday, May 13, 2004

Okay, I fixed it, though I'm not very happy with the solution. Turns out that it DOESN'T work without the -u flag, for reasons I don't understand, except that the WshShell.Exec call appears to behave differently from just typing straight into the command prompt.

In any event, the solution that worked was to hardcode a username and password into the script, and use those to request the clientspec.

Which means I have a password coded in my VB script.

Better solutions are welcome.

Corey Reid
Thursday, May 13, 2004

Just for completeness' sake, I'll point that the Perforce manual makes it pretty clear that trigger scripts on Windows do require a real userid in order to work:

http://www.perforce.com/perforce/doc.022/manuals/p4sag/06_scripting.html#1044570

So I took the long way around -- RTFM is my lesson for today.

Anyways, thanks very much for all the help.

Corey Reid
Friday, May 14, 2004

Would appreciate some more guidance on this. It appears that the script is spawning numerous "p4" and "cscript" processes that never get killed and end up chewing through resources on the server.

Any thoughts as to why this might be happening?

Thanks!

Corey Reid
Wednesday, June 09, 2004

>>
In any event, the solution that worked was to hardcode a username and password into the script, and use those to request the clientspec.
<<

That's what I ended up doing.  Not very happy about that at all.  The FogBugz website has screenshots of all this great integration - but the directions are wrong if you just happen to use passwords for source control.  Am I missing something?  Why wouldn't passwords be enabled?

Has anyone tried using the rest of the recommendations made by FogBugz for Perforce integration?  In particular, the use of perfbrowse?
Works fine if you hardcode user and password, but that unfortunately means that anybody with access to the bug server has (readonly) access to the source depot (even if they don't normally have access to it).

Sean Echevarria
Wednesday, June 16, 2004

Actually, that's not entirely true. Here's how we've solved the problem:

We have a "visitor" user for Perforce that is used to assign permissions to temporary employees, guest developers or whatever. I have given this user "list" permissions for the entire depot

list user visitor * //...

"List" means the user can see the names of every file, but does not include permission to read the contents of any file.

I updated the Perforce integration script to include the username and password:

Dim DEFAULT_USER: DEFAULT_USER = "visitor"
Dim DEFAULT_PASSWORD: DEFAULT_PASSWORD = "password"

Now the script can always run the "describe" and "opened" commands (since those only require "list" permission) and my source code remains unviewable.

The primary gotcha is that you need this "visitor" user -- and the line provided the "list" permissions needs to be the LAST line that affects that user. Otherwise, later permissions that deny, say, "read" access to a file, will also deny "list" access -- that's Perforce.

Hope that helps somebody out.

What I want now is to get the script to read multiple instances of "BugzID: ###" in the submission comments and create links in each bug listed.

Corey Reid
Tuesday, June 29, 2004

> Has anyone tried using the rest of the recommendations
> made by FogBugz for Perforce integration?  In particular,
> the use of perfbrowse?

Now, as far as perfbrowse goes, I couldn't find any way to get the current username and password into that script, either, so it currently DOES allow full access. Sub-optimal, but perl scripts like this are FAR beyond my ken. I hardcoded the "p4open" routine to contain a username and password:

sub p4open {
    local( $handle, @command ) = @_;
    #print "currently on p4open";
    open( P4, "c:/perforce/p4 -u username -P password @command" ) || &bail( "p4 @command failed" );
    #while (<FH>) {
    #    print $_; }
    #close(FH);
}

Which is definitely sub-optimal. Anyone with better perl skills might be able to find a superior solution. But that's really a question for the good people at Perforce, I reckon.

Corey Reid
Tuesday, June 29, 2004

Well, the good people at Perforce pretty much said, "Write your own Perl script to handle user authentication, why don't you?"

Okay, I guess they're not a Perl development company. so fair enough. If I manage to cobble together something that works I will post it here. But don't hold your breath...

Corey Reid
Thursday, July 08, 2004

*  Recent Topics

*  Fog Creek Home