RSS and restrictions

Try putting a trim() around user.getRequesterId(). I would also recommend moving this to the form itself rather than the POR-PO-NUMBER field.

John/others: I've tried that as well (the trim around user.get...) I think I had tried it on the form itself, but was getting other strange errors. Maybe I need to try again? And maybe this should be in the security forum?

OK... just tried it on the form itself. Waiting for the reload time to the server, and then I'll test. Will update you more when I know more.

Is it possible that the attached screen shot is just a web-page-generated one, that would require customizations to a javascript, or other to enable this feature? Whooops..... I don't have an attachment button here??

Thanks for noticing that I didn't have attachments enabled.

Moved to S3 security forum.

Is it possible that the attached screen is a javascript screen and not "actually" PO30.1 controlled?

Now I understand why you're so frustrated RSS uses a combination of javascript/XML/XSL that calls Data/DME and AGS/Transaction. This particular screen is using Data, and probably pulling from the PURCHORDER table I guess. There is a tracing/debug function in RSS/RQC that you enable by appending &DEBUG=TRUE to the RSS URL (or pressing Ctrl+Shift+T), and it will show the calls as they are made.

So, if I understand what you are saying, John is that this is NOT LSF security controlled. Correct? And I'm sure if we'd like it modified, it would be billable and customized. We have a group of users here that should see everything, and a group of users that should ONLY see their "stuff".

Posted By Greg Moeller on 09/13/2011 04:52 PM So, if I understand what you are saying, John is that this is NOT LSF security controlled. Correct? And I'm sure if we'd like it modified, it would be billable and customized. We have a group of users here that should see everything, and a group of users that should ONLY see their "stuff".

It is under LSF control.  It's a mix of putting rules on the tables to control drill around, select lists, etc. as well as rules on the forms (e.g. RQ10) to control transactions (i.e. if a user enters directly without a select list).  It can ALL be done with security rules (I know because I've done it).  

OK, John. I'm sorry if I seem short with anyone... it's been an extremely LONG month for me already. I'll just have to try more rule-writing. Thanks for all of your help so far! I'm sure I'll be asking for more.

All: Sorry if I seem to be beating a dead horse here... I got the security restriction to work by restricting the LOCATION = Requester ID, but am now told that will not work for us here. So I'm back to trying to make RequesterID=Requester on the PO. Just can't seem to get the rule correct. I've got the rule set on the PO-NUMBER field of the PURCHORDER table... like this: trim(user.getRequesterId())==trim(getDBField('POLINESRC','REQUESTER','COMPANY','PO-NUMBER')) What am I doing wrong, or missing here?

Question: Am I using the key fields correctly in my rule (10/18/2011 @ 8:51 AM)?

No, when using getDBField, you need to pass in the key values for the primary index. Are you trying to get the requester for the purchase order?

Yes, John. Trying to match the requester id to the requester on the PO.

How would I write the rule correctly?

Let's go back a step. What object are you trying to secure -- PO20 ?

no, actually that screen that I uploaded earlier... from Fiddler, I got that it was accessing the PURCHORDER table... So, I'm trying to write the rule on the PO-NUMBER field.

Well, that could be a problem, depending on how requisitions are entered and POs are generated. The *easy* thing to do would be to look at the "default" requester (PCR-DFLT-REQUESTER) on the PO, since you already have PURCHORDER record. However, be aware that it's on the default requester. So scenarios could exist with multiple requisitions/reqlines result in a single PO, in which case you'd need to look at each POLINE one the PURCHORDER record, then POLINESRC, which has the REQUESTER field. So, I'd start simple and see if you can assume one req to one PO (I think that was one of the changes in RSS->RQC), and in that case you can just look at the PCR-DFLT-REQUESTER on the PURCHORDER record.

Which means that on the PURCHORDER table, your rule is simply: if(trim(user.getRequesterId())==trim(table.DFLT-REQUESTER)) 'ALL_ACCESS,' else 'NO_ACCESS'

I'll see if that will work for our users. I've already asked the 'can we assume...' question. Haven't heard anything back yet. Thanks as always!!

Our Lawson is set to combine reqs to PO's to cut down on the number of PO's processed so if they have the same ship to vendor and purchase from there would be multiple reqs and requesters on some PO's. -- on the multiple requesters PO's, you can't see them with just the DFLT-REQUESTER rule in place.

I'm not sure if we "need" to see those PO's or not. My "guess" is that the users will want to see those PO's as well. I think I'll need more help in rule-writing.

Would it be easier to just have whomever is logged in see everything in that initial Receiving screen, but only be allowed to receive their own stuff? So, would that then be PO30 that I'd need to secure?