Users can't seem to access a newly developed program through portal. They can all access it through LID but not through portal. So it can't be LAUA.

I can access it via portal as a Admin (wide open security).

We've tried recompiling it, doing cache refreshes, ...

Any file permissions I should check?

I should mention this is a UNIX box.

Thanks

Tan,

What happens when users try to access it? Have you run with debug=true to see what's going on? Does the LawSearch servlet not find the program? Have token and program searches been disabled in the Portal role file (look at the TYPE attribute forthe BUTTON tag). Does LawSearch work, but the Xpress servlet is unable to deliver the XML screnn definition? Might you need to do an xscrgen (and subsequent IOSCacheRefresh?_REFRESH=UIDef), because UNIX directory permissions prevented the creation of the XML screen definition?

I had the same problem with a new Quarterly Balancing Report that was delivered in a CTP for Payroll. This is what I did....

cd $LAWDIR/<product_line>/map/default
rm program_name.xml (Only delete the .xml file(s))
and then ran scrgen product_line system_code program_name


Hope that works for you! :D

Thanks for the suggestions guys.
Turns out it was user error.
Oh and ehspears I have tried that before with success too.

Thanks

Okay so it turns out it was only Part user error.
We still have an issue. The custom program is called ZM126 which is almost an exact copy of MA126.

SAME USER

Sec Class APUSER
When in portal I type in the program name in the searchbox and I get "Zero Hits"
And MA126 works great.

Sec Class ADMIN
When in portal I type in the program name in the searchbox and it works great.


The program has been added to both security classes in exactly the same way. The APUSER class contains ZM126 and MA126 which are both almost identical.

Is there any reason why the searchbox would return zero hits when user is assigned to one class vs. another?

Thanks

We're having similar issues.

For some reason we don't understand LAUA security restricting the user just to the one program works fine in LID. In PORTAL, the user can't run the program. We opened a ticket with the GSC.

The workaround we came up with was to open up access to the entire System Code, not just selected screens. Now the user can run the program.

My boss asks, Why do we have to open up access to all of the System Code when running a program through Portal? That's the $64 question. :bonk:

Hey guys,

This is still a big issue, many days later I still can't fix it. PLEASE!!!

We copy an exiting MA126, to lets say ZZ126. Compile it. MA126 shows up in Portal but ZZ126 doesn't. LID works just fine for the SAME user.

I have tried xscrgen, I have tried deleting the files under ...../map/default , I have made all the perms 777, I have done IOSCacheRefresh about a 1000 times, logged out and back in. I've even given access to the entire system code.
We noticed some change when when we bounced RMI and now some ADMIN users can access it but overall still a bust. Still says "0 Hits".

This is driving me mad. I have never seen anything like it.

Oh but in the mean time I found the following cool hacks :)

http://yourserver/servlet/LawSearch?PDL=PR...s.token&q=MA126

and


http://yourserver/servlet/Xpress?_TKN=MA126&_PDL=PROD

Give you some backdoor access to screens you normally wouldn't see, if you deal in this stuff you'll find a way it can help you at some point.

Hi, have you tried running the Rebuild Custom Form Index from the Portal Administration bookmark?

OMG have I. And I would never recommend that to anyone again. It basiclly will destroy all the links to mods you've made in rd69 unless you've followed a good naming convention. And btw, its still unrelated because it works on design studio forms ...

Okay, here's an update though. When we bounce RMI it works. Any ideas what could be setup wrong in RMI to cause this?

Thanks

I'm inclined to suspect an RMI bug. Lawson doesn't allow much in RMI to be configured, other than the basics needed to run the server (e.g., IP address and port) and parameters that control the pooling of the native pts, streamida, and streamdme processes.

Data on whether a token is secured against a particular security class is stored by RMI in a hash. This hash is cleared when you run IOSCacheRefresh for ALL or TOKENS, and repopulated from the USEREXE file in GEN as the information is needed for subsequent security checks.

Might it somehow be that ZZ126 is in USEREXE for the security class you have problems with, even though the security looks fine in laua? I don't know know the RMI tokenMap hash is initially populated, so I suppose that it might be done from someplace other than USEREXE, and that this file is out of sync.

I fix that problem by running the cache refresh command.

http://yourservernamehere/servlet/IOSCache...sh?_REFRESH=ALL