Cloned product line for testing and the search box is not working?

Here is the process:

1. run LoadPortalBookmarks :

> cd %LAWDIR%/newprodline/Admin
> cp Portal* %LAWDIR%\logan\Admin
>perl %GENDIR%\bin\LoadPortalBookmarks NEWPRODLINE

2. run LO920:
> cd %LAWDIR%\logan\work\LAWSONLD
> cp LAWSONLD.content.csv LAWSONLD
> lapm logan lo920

3. LoadPortalGroups

> perl %GENDIR%\bin\LoadPortalGroups NEWPRODLINE  
> cd %LAWDIR%/newprodline/Admin
> loadusers -f Portal_Groups.xml

4. IOSCacheRefresh

Thanks John.  We actually don't have bookmarks loaded in our DEV environment.  That isn't a problem though as we normally use the search box to get there. 

I followed the exact same process to create this product line, as I did for another one last month.  And when I do the search on THAT one, I get the same results as on the original. In fact, I tried every other product line in that environment - and all of them were created the same way - and each one, except for the newest one, returns the same 6 hits.

Would that process that you laid out, make sense in this case?

1. Did you do an IOSCacheRefresh after creating/loading the new product line?
2. Are you using LAUA or LS9 for security? The new product line will need to be assigned to the appropriate security classes in order for them to see the forms.

Posted By John Henley on 05/22/2012 10:30 AM
1. Did you do an IOSCacheRefresh after creating/loading the new product line?
2. Are you using LAUA or LS9 for security? The new product line will need to be assigned to the appropriate security classes in order for them to see the forms.

Yes, we did an IOSCacheRefresh.  Several times in fact. 

Also, we have only a single security class in this environment - (keeps things simple right now) and I did add the new product line to that security class. 

Everything in this product line appears to be working just fine...except for the search box issue.
And depending on the search, sometimes there ARE results, but they are always a small subset of the results returned in the other prodlines.  I am attaching 2 screen shots in case that helps.

And just to clarify, I can search on a portal form just fine. For instance - PR13, returns the PR13 form. So those type of searches work. It's just when you search on a term...that is not working properly.

Did you compile the new product line?

Yes, compiling the product line is part of our normal process, and that was done.

The search is done by looking at the bookmarks, so if you don't have the bookmarks set up for that product line, the search won't find them.

We don't have bookmarks loaded - meaning that on the left side of the portal screen, there are no bookmarks - they are not available (well - the self service booksmarks are available to subscribe to, if you wanted them - but nothing else).   Maybe the correct term is portal content?  But for this environment, it's not a big deal - we always type in the form name, such as HR11, and it comes up.   That works in every product line, including this new one. 

What doesn't work is a "text" search.  It will only return a search of a section called "Bookmarks"...and I don't really understand the difference, and why it is only searching there. See the screen shot...

Okay...I was just playing around trying different searches, and got a really weird error.  In this new product line, I get an error when I search on a particular term. But it works fine in the other product lines.  I'm going to put screen shots in so that you can better see what I am talking about.

This first set is from the original product line - two different searches - one for "emp" and one for "employee".   The first one gets 2 hits, the second one gets 212.

Now, I do the exact same searches in the new product line, and here is what happens.  The first search "emp" returns the same results.



But when I search on "employee", I get this:





Something is definitely wacko.  Any ideas?

The search API looks at what bookmarks are accessible to the user. In this case it is getting error on HS10. If you look closely the company and employee are NaN. Make sure HS10 is compiled, you have defined an ESS service EOYROLL_EMPLOYEE for the product line, and assign an identity for it to the user.

The text searches against the bookmarks as well so if you don't have the bookmarks, you can't have them in the results. Why don't you add them and see if that changes the results?

Ah.  Well I know without looking that we don't have an ESS service created - we don't need one for the testing.  Never occurred to me that would affect searches.

What does the NaN mean?

NEver mind. I googled it. Funny...all these years and I've never heard that term before!

NaN, standing for not a number, is a numeric data type value representing an undefined or unrepresentable value, especially in floating-point calculations.

Adding the ESS service did not work.  No change at all. 

Any other ideas?

So after adding the prodline_EMPLOYEE service and assigning a valid company/employee value for the login you use for testing, you are still receiving the exact same HS10 error when searching on the term "employee"? Is this correct?


Is new productline assigned to a Profile ID under the Profile Assignment is Lawson Security Adminstrator?

What PortalRole is assigned to the user used for testing?  Try assigning "default.xml" and see if you get the same results after logging out and back in.

Yes, I added the productline_EMPLOYEE service, assigned my user access.  When I said "no change", I was referring to my original question, and I still cannot get the same search results that I receive in the other product lines. 

As far as the error when I search on "employee"...now I only get the "YOu don't have any direct reports" message.  I am not getting the xml error.

I have not assigned the service in profile assignment as we have not done that for any of the other product lines...it's not something we've ever done, or needed to do, (at least on this box),  and all the others are working fine.  That is why I am so stumped. This is the first time I have experienced this problem with the search.  (We don't have LS turned on...if that makes a difference in what you are suggesting - we are still using LAUA).

I don't know if it addresses your exact concern, but you might ask Lawson for more details on JT-336447 (ListBookmarks does not return all bookmarks) It sounds like it could be related to the problem you've described.

Thanks for the additional info.  I had not tried this in the last few days, and somehow, it has resolved itself. The search box in that product line now returns the same results as the other product lines.    And we've done nothing to afffect a change.