Submit.cfg issue

I'm having a problem getting my submit filters to work. I've created a sub-branch called 'Training' under a parent branch called 'CorpIntranet'. I've tried touching a file under '/templatedata' and submitting it. However, the permissions on that file do seem to take effect. Below is a snippet from our submit.cfg file:

###################################
## Corp Intranet Training Branch ##
[^/]/CorpIntranet/Training/.
{
.
{
setaccess = {
"TSSERVER\\Administrator:ALL",
"TSSERVER\\Administrators:ALL",
"TSSERVER\\tsadmin:ALL",
"TSSERVER\\TSMaster:ALL",
"TSSERVER\\TSIntra-Training:CHANGE",
"TSSERVER\\TeamSite Web Preview:ALL"}
}
[/*]templatedata[/*].*
{
setaccess = {
"Everyone:Read",
"TSSERVER\\Administrator:ALL",
"TSSERVER\\Administrators:ALL",
"TSSERVER\\tsadmin:ALL",
"TSSERVER\\TSMaster:ALL",
"TSSERVER\\TSIntra-Training:CHANGE",
"TSSERVER\\IUSR_TSSERVER:CHANGE",
"TSSERVER\\TeamSite Web Preview:ALL" }
}
}

Any help would be greatly appreciated.

Thanks

Derek

Edited by seeDerekNow on 12/23/02 01:35 PM (server time).

Find more posts tagged with

Comments

Migrateduser

Where did you get that syntax from? That looks nothing like my submit.cfg. When I look in the docs, I don't see any "setaccess" attribute for submit.cfg.

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

seeDerekNow

The syntax came out of the box when we installed TS 5.01. It should be fairly standard. Perhaps I should have mentioned that this is on a Win2k box. The syntax on our Solaris machine is slightly different (doesnt use the 'setaccess' attribute). Sorry about the confusion.

Derek

Migrateduser

OK, that explains it. Your regex's look funny. Not haha funny but just wrong. Here's an example of how you could set up your submit.cfg and distinguish between your main branch and its subbranch:

rules
{
^/default/main/CorpIntranet/WORKAREA/.*$
{
/$ {gid=corpint perm=775} #All directories must be executable
.+ {gid=corpint perm=775} #All files
}
^/default/main/CorpIntranet/Training/WORKAREA/.*$
{
/$ {gid=train perm=775} #All directories must be executable
.+ {gid=train perm=775} #All files
}

I think if you fix your regex's, you'll have it working.

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

seeDerekNow

Well, if my regex looks funny, you can thank Interwoven because that was the recommended setup. We had an IWOV consultant down here just last week helping us with the conversion to 5.5. He didnt seem to have a problem with way the submit.cfg was written. In fact, he created a new one just with the exact same format! However, the snippet you provided is pretty much identical to the submit.cfg on our Solaris box. It's our windows machine that's got the 'funny' regex. If I have to rewrite our submit.cfg, so be it. But I'm hope the problem is not as deep as that, especially since this is the format that Interwoven is telling everybody to use.

Thanks

Derek

Migrateduser

Well maybe I should just shut up then since I'm only familiar with a Solaris setup. Although I don't think regex's would be that radically different on a Windows environment. I'm sure someone who is familiar with Windows will set us straight. Sorry if I threw you off track.

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

seeDerekNow

I wouldnt think the syntax would be that different either. But for some reason, it is. Go figure.

RyanS

Ok.. fact is.. the regex itself is not different, but the submit.cfg usage is. As for how we use our regex, we're simplifying things by putting [/*] at the beginning to take the place of "/default/main".. that's all.. neither is wrong, we're just doing it differently...

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." -Albert Einstein

Migrateduser

That's bizarre syntax to represent "/default/main". The regex syntax [/*] represents the character class containing the characters "/" and "*". While it may work, it is very strange syntax.

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

RyanS

meaning, the string starts with a "/" and then has any number of characters between it and the next segment.. and by all accounts, that's what "/default/main" consists of. I'm not a regex expert, but it works for us with no problems...

The original issue turned out to be we had the segment in the wrong place.. our more general "CorpIntranet" definitions were in the way... so we moved the "CorpIntranet\Training" definitions up above the more general definitions, and it works fine.

Problem solved... fin

Migrateduser

meaning, the string starts with a "/" and then has any number of characters between it and the next segment..

It's actually not doing that at all. What it's looking for is either a "/" character OR a "*" character followed immediately by your string "CorpIntranet/" and then followed by any character (where you have a "." at the end of your regex). That's why it works. It's not doing what you think it's doing but it works for how you need it to work. It would also work for any other branch, subbranch or workarea named CorpIntranet, which is why we like to use the full pathname in case anyone uses any duplicate names anywhere.

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

Adam Stoller

If you look closely at the syntax of the regex used, you'll see that it really doesn't do what was said.Smitty's regex's are anchored:
^/default/main/CorpIntranet/WORKAREA/.*$

This will match only against the branch "/default/main/CorpIntranet/"

Whereas the seeDerekNow's regex's are not anchored:
[^/]/CorpIntranet/Training/.

This will match "/CorpIntranet/Training/ anywhere it might appear within the path.

All the leading "[^/]/" does is say that there's some character other than a slash that comes before the slash.

Likewise, the other regex:
[/*]templatedata[/*].*

Only says that there might be zero-or-more slashes before and or after the word "templatedata" - which while it works right now, it could accidently match some time later in the future if you create a "templatedata2" or "old_templatedata" directory or some such - as those will be matched also.

I stronly recommend that use of the CLT iwtestcfg when working on configuring your submit.cfg file - and remember that you have to do an iwreset before any changes can be tested.

Happy Holidays

--fish
(Interwoven Senior Technical Consultant)

Edited by ghoti on 12/23/02 07:34 PM (server time).