• ed10
  • Senior Member
  • Offline
  • From: USA
  • Registered: 08/26/2010
  • Posts: 132

Topic: selection bug-I think

This is sort of a mix of things. 

itronics wrote:

Regarding the weird exact selection effect, I can't remember why it was leaved as it is. I'm sure there was some (more or less) important reason for implementing such behaviour, but  simply I can't remember what it was. Anyway, I agree this is annoying., and maybe this is good candidiate for improvement.

Janusz

The above is from: https://frontaccounting.com/punbb/viewtopic.php?id=3558

When I go to: /frontaccount/reporting/reports_main.php?Class=0 then select Print Statements (we are still testing our emailing). Then go to Customer to filter the customers, hit space and type in an exact match for a customer it still comes back with No Customer Filter (expected since the code was not changed --discussion in above thread). When I click on the filter again, I then can see and select the exact match customer, print the statement. No problems to print the statement.  But then when I try to email the statement, I get:
======================================
Undefined variable: id in file: /var/www/frontaccount/reporting/includes/doctext.inc at line 256
/var/www/frontaccount/reporting/includes/pdf_report.inc:438:     include('/var/www/frontaccount/reporting/includes/doctext.inc')
/var/www/frontaccount/reporting/includes/pdf_report.inc:948:     (FrontReport Object)->Header2()
/var/www/frontaccount/reporting/rep108.php:121:     (FrontReport Object)->NewPage()
/var/www/frontaccount/reporting/rep108.php:29:     print_statements()
/var/www/frontaccount/reporting/prn_redirect.php:71:     require('/var/www/frontaccount/reporting/rep108.php')
/var/www/frontaccount/reporting/includes/reports_classes.inc:53:     include('/var/www/frontaccount/reporting/prn_redirect.php')
/var/www/frontaccount/reporting/reports_main.php:465:     (BoxReports Object)->getDisplay()
You have no email contact defined for this type of document
/var/www/frontaccount/includes/ui/ui_msgs.inc:14:     trigger_error('You have no email contact defined for this type of document','256')
/var/www/frontaccount/reporting/includes/pdf_report.inc:983:     display_error('You have no email contact defined for this type of document')
/var/www/frontaccount/reporting/rep108.php:168:     (FrontReport Object)->End('1','Statement as of 02/07/2013')
/var/www/frontaccount/reporting/rep108.php:29:     print_statements()
/var/www/frontaccount/reporting/prn_redirect.php:71:     require('/var/www/frontaccount/reporting/rep108.php')
/var/www/frontaccount/reporting/includes/reports_classes.inc:53:     include('/var/www/frontaccount/reporting/prn_redirect.php')
/var/www/frontaccount/reporting/reports_main.php:465:     (BoxReports Object)->getDisplay()
===============================================================
The customer has the email as general and this looks to be at least partly the same error that Joe fixed in last week or two in several reports.

The next problem (I think unrelated to the one just above).  After I print the first statement, I go to the customer filter, hit space bar and type in another exact match customer.  It comes up with No Customer Filter as before but when I click it, the next exact match customer in listed in the drop down.  Then I click that customer, instead of that customer name coming up in the filter text box, No Customer Filter is back in it.  Click filter again, customer name is in the drop down, click and again back to No Customer Filter.  The only customer statement I am able to print is the first customer. I don't think that this is a caching problem because I tried clearing the cache and it made no difference.

It seems that it the same thing as when you enter a Sales Order and come back to enter a new Sales Order, the system 'remembers' the last customer you used.  Seems like the previous customer was in a session var and that gets read as the customer you want to use.

So this post includes 2 problems (the error msgs on the email) and not being able to select another customer for a report (at least the two I checked Account Balance and Print Statement).

I would still like to see the code changed so that when you type in an exact match that customer comes up and if it is not an exact match the first partial match customer is listed.  This is the way most searches work on the net.

Hope I have explained this well enough.

ed10

  • joe
  • Administrator
  • Offline
  • Registered: 03/15/2007
  • Posts: 5,089

Re: selection bug-I think

Hello ed10

We cannot reproduce this bug.

It is not possible to get this error:

Undefined variable: id in file: /var/www/frontaccount/reporting/includes/doctext.inc at line 256

This error should occur on line 239 if in release 2.3.14.

Either you have changed your setup or you have an older release.

/Joe

  • ed10
  • Senior Member
  • Offline
  • From: USA
  • Registered: 08/26/2010
  • Posts: 132

Re: selection bug-I think

Hi Joe:

Yes I have edited doctext.inc as you suggested to me in another thread.  The reason that the line 239  got shoved down is because when I make a change on the core files, I remark the original line and add my line so I can go back and see what did or didn't work.  I made 8 changes go that added 16 lines, may have gotten a extra blank line, didn't count closely. Almost all changes were simply changes in text, one was a footer.

I am using Version 2.3.14 Build 20.01.2013. 

I tried to test the weird search on your demo, but it is not set up for searching so was not possible to test. I have FA running on 3 different boxes and the three are generally not the same.  One is our live server that is used for our real accounting, one on my managers box for her testing new changes and my box for development of things we want to change.  All boxes are Ubuntu 12.04LTS using Firefox 18.0.2. 

I promise you that the search is acting as I described on all three boxes. My manager found it to be acting in this manner when we were testing the emailing of statements.

I seems to have something to do with session/cookies.  I just did a small test.  I went to reports/print statements and printed a statement for a customer.  Then I looked at the cookies both before and after the print. there were four cookies set after the print:
select[108][0]  this one had content 83551 (the debtor_no)
select[108][2]
select[108][3]
select[108][5]
the rest had content 0.  If that means anything to you.

I think typed in a new exact match customer, click on his name then checked the cookies.  No change at all, exactly the same.  Seems that there should be some change.

Next I logged off FA and back on, went to reports, print statement and the customer showing was the customer I printed the statement in the beginning of my test.  Cookies still exactly the same.  I expected the cookies to be removed but were not.  Is that the way it is supposed to be? The cookies are session cookies. The session cookie id was the same also.

I don't know what else I can do to test this.

Thanks for you working on this,

ed10

  • joe
  • Administrator
  • Offline
  • Registered: 03/15/2007
  • Posts: 5,089

Re: selection bug-I think

It looks like you have '$save_report_selections' set to 1 in config.php. Try to set this back to 0 and clear your browser for history, cookies and sessions.

Just to test if the error will go away.

/Joe

  • ed10
  • Senior Member
  • Offline
  • From: USA
  • Registered: 08/26/2010
  • Posts: 132

Re: selection bug-I think

Joe:

Yes that was it.  The value was set to be 30.  I am certain that I didn't set it so don't know why it was 30.  I didn't even know the var was in config.php. 

Been another learning experience smile

Thank you so much,
ed10