Search options (Page 3 of 6)

The error suggests that it is your 'from' email address of your company that has issues, not the name or email address that you are sending to.  Do you have the full headers of the email that bounced that you can post?  Possibilities are:

- FA is not correctly encoding the from email address in sent mail.
- The remote email server does not support utf8 (very unlikely).

I've got AngularJS and Angular 2.x, 4.x experience.  Its not clear to me that this would be a good idea in the case of FA.  What code would you be looking to keep from FA?

I think it would be better to keep the existing JsHttpRequest (essentially div swapping) and augment with dynamic components like date picker, typeahead etc where those are desirable.  Incorporating the Bootstrap work would also be a good thing IMO.

If you were to do a complete replacement of JsHttpRequest with Angular I think you'd find the architecture to be very different. 

The views would all be replaced, along with requiring a REST (or some kind of) API for the Angular client to talk too.  That would be a lot of work.

Also, this scale of work would be unlikely to be incorporated into FA.

FYI, the old style constructors (same name as class) started to be deprecated in PHP 5.3.3 (in the case that a namespace was used - which is not used in FA).  The new style __construct was introduced in PHP 5.  The old style is deprecated in PHP 7.

See http://php.net/manual/en/language.oop5.decon.php for more info.

PHP 5.3 went end of life nearly 3 years ago.  The Travis Tests are running on PHP 5.4 and are all passing.

If you all were to integrate the test from this PR then you would be able to continually run the tests on Travis against multiple versions of PHP.

There are also additional changes in a subsequent commit.

The original PR was here: https://github.com/FrontAccountingERP/FA/pull/10 Feb 2016.

I had a look at your test site.  The ajax request does result in a 302 redirect to the root '/' which returns a standard apache indexes page. This isn't javascript, so causes the error.

Do you have a .htaccess somewhere in the tree / or /apmuthu or /apmuthu/sales?

Do you or your host have a misconfigured location or directory directive in your apache config.

Does your host use mod-security or something similar?

I can't be sure without actually investigating your server, but I think this is a server configuration issue.

As a bit of a guess, I'd say that your session timed out.  i.e. you tried to do something on a page that uses  ajax to do the save, however the session was timed out, so you should've been redirected to the login.  It seems that / on your installation isn't where FA is, so you got a standard index page which couldn't be parsed by the JsHTTPRequest javascript code - hence this error.

Try Ctrl-R to reload the page and see if it comes right from there.

@Jinkels.  I did my test on the latest 2.4.RC1.  Pretty sure it has the problem I described above.

It seems to me that if you use the Sales | Customer Payments method it works correctly.  However, if you process a Bank | Deposit, then Sales | Customer Allocation the customer allocation process does not process the foreign currency difference correctly (it gets it backward, and doesn't take the difference between the settled amount and the original invoice amount in AR).

@Jlinkels: Note that you should be doing a Bank Deposit Entry for a customer payment (not a Bank Payment Entry which would be for a supplier).  Given your example, I think that's what you mean - and processing the Bank Deposit then Allocation results in this error.

@apmuthu. At that line it would be fine, but the use of POST becomes more consistent now that we've had to assign the $_POST['trans_no'] 2 lines above.  This is because we've introduced an ajax refresh into the page which needs the trans_no to be present in a hidden control which is added on line 155 of the patch (line 822 of the real file).  Your patch is not comparing the correct files I think.  It might pay to note that the first commit in the github repo didn't start with the original sales_order_entry.php, it had already been modified prior to the first commit.  Note also that the patch shown is only for that single file.  All the other files are required also.  Particularly the includes/ui/... which have also been modified.

The order of $path_to_root doesn't matter.  But, this is a recurring sales module, not a proposed change to the core sales module.

If you're looking to backport it to 2.3, there's a bit more work to do that than applying a patch.  As I've indicated above, I've got no interest in doing that myself (sorry).

The main view is taken from a copy of the sales order module in core.  So that file has been updated to v2.4, and I've modified it further from there.  So, to make it work for v2.3 it is necessary to backport the changes to the v2.3 version of the sales order entry file.

I can't imagine the v2.4 sales order entry working with v2.3 out of the box.  As you point out in your second post, it didn't work for you.

This is a PSR-4 autoloader (as specified by the PHP Framework Interop Group), via composer.

This is the current best practice method for producing an autoloader, which then does not need any require statements at all (other than of course including the autoloader).

Developers can recreate the vendor folder entirely by doing 'composer install'.  All other users should use the tarball releases supplied, which include all the required files.

Done. Thanks for that.

The PHP Design Patterns site is good.  I don't recommend the first link on DataMapper ORM.  IMHO that author has conflated the concepts of Object Model and Data Mapper.  A Data Mapper should be able to persist any model.  An object model should not care how it is persisted.  My DataMapper class would be better named FrontAccountingMySQLDataMapper to be more descriptive.