kvvaradha wrote:

Full error details.

Uncaught TypeError: found[k].className.match is not a function
    at HTMLDocument.document.getElementsBySelector (behaviour.js:25)
    at Object.apply (behaviour.js:6)

From the stack trace it looks like in the implementation of getElementsBySelector (behaviour.js:164) the property "className" is not guaranteed to be a string.  If it was a String, then "match" would exist. 

        if (found[k].className && found[k].className.match(new RegExp('\\b'+className+'\\b'))) {
          currentContext[currentContextIndex++] = found[k];
        }

According to MDN there are some cases where className may not be a string.
https://developer.mozilla.org/en-US/doc … /className

A reasonable check for string to use would be

Object.prototype.toString.call(found[k].className) === '[object String]'

There is likely some other error that is causing there to be a non-string DOM element in the className list on the given selector which shouldn't be there.  However, this javascript code should be protected from the error anyway.

Sometimes Chrome gets a little bit 'stuck' if you've done a multiple selection using shift or ctrl keys outside of the Chrome window and then alt-tab or click back.

If this is the problem then a single press of the ctrl key or the alt key will get it unstuck and things will work normally again, you'll then be able to click on a link and it will work.

Try this and see if it works.

3

(1 replies, posted in FA Modifications)

Hi,

I'm wondering if there's any interest in including the PHPUnit tests in the core to test Front Accounting?  The testing can be seen on Travis CI.  See the Pull Request on GitHub for more detail.

There are two types of testing available:

1. PHPUnit 'unit tests' and
2. Chrome headless integration / ui tests.

The PHPUnit tests do not test the UI, but are good for testing the database, and logic of updates and so on.  The Chrome headless tests are good for testing the ui.

4

(85 replies, posted in Modules/Add-on's)

@boxygen You would need to install this feature (module) that would work for all companies.  I'm assuming that you want to force even valid users to be denied on certain companies.  Currently this would require you to modify util.php in the api_login() function.

Suppose that you only want to allow company number 3, then you would change util.php (Line 25 - 27) from something like this:

        if (!$succeed) {
            $app->halt(403, 'Bad Login For Company: ' . $company . ' With User: ' . $user);
        }

to something like this:

        if (!$succeed || $company != '3') {
            $app->halt(403, 'Bad Login For Company: ' . $company . ' With User: ' . $user);
        }

It would be a nice future feature to add proper access control that can be configured from Setup  | User Access Roles.

5

(85 replies, posted in Modules/Add-on's)

Hi,

An update to the REST API is available here v2.4-1.6:

https://github.com/andresamayadiaz/FrontAccountingSimpleAPI/releases

Changes since v2.4-1.5

22 June 2018

Add full CRUD for Journal entry, update, and delete (void).

21 June 2018

- Add full CRUD for Bank Accounts under bankaccounts endpoint.
- Fix formatting of code under src/ and test/ to conform to PSR-2

20 June 2018

- Add full CRUD for GLAccounts under glaccounts endpoint.
- Add CRUD for Dimensions under dimensions endpoint.
- Add static api generator and sample documentation.

19 June 2018

- Core VARLIB_PATH and VARLOG_PATH inclusions added
- TaxType: Added getById (Apmuthu 24 Nov 2017).
- Sales: Fix #32 Sales transactions Total not returned.
- Stock Adjust: Added unit test.
- Stock Adjust: Return now encoded as json msg.
- Stock Adjust: Missing argument $info fixed (Apmuthu 23 Apr 2018).
- Stock Adjust: add_stock_adjustment parameters fixed for FA 2.4 changes in API (Apmuthu, justapeddler 19 Apr 2018).
- Translated Spanish comments to English (Apmuthu 18 Nov 2017).

6

(6 replies, posted in Modules/Add-on's)

@barbarian the reason for keeping the Slim version on an out dated version was to maintain compatibility with PHP 5.4 which was desired by FrontAccounting users.

There is no reason that it cannot be upgraded, or maintained on a different branch, if the target PHP version is changed to say 7.x

@redcone How did you create the database, user and password?  Perhaps you can test that you can access the database with something like phpmyadmin.

@redcone  The database uses port 3306 not port 81.  3306 is the default, so you can just leave the :80 off the database server setting.  So 127.0.0.1 should be fine.

9

(6 replies, posted in Development)

Dear Janusz and Joe,

I'm still keen to be involved.  I would be keen to implement along the ideas in my email to you of 6 December 2014 where I outlined some possible ideas following the implementation of (now outdated) Bootstrap 3 proof of concept.

However, its not clear that the community want to go in that direction. e.g. use of classes, modest (very modest) use of some design patterns to facilitate unit testing.  Incorporation of unit testing on Travis etc.

I have a day job, and its not accounting.  I'm an enthusiastic user of Front Accounting and professional web developer and I'm willing to contribute where our interests overlap.

Project Governance, I think is an important issue to get sorted out at this point.  It cannot be 'my project' (my being Janusz and Joe) with 'your' contributions.  It has to be 'our' project.

Looking forward to see where this will go. :-)

FA doesn't provide hooks to modify views.  So, if you want to 'modify' a view you need to create an extension, copy the view code, then modify the view code in your extension.  You can then have your extension modify the menu structure to make the menu system reference your extension rather than the core implementation of the view.

One example of this is the recurring sales modules I made a couple of years ago.  The code is on Github here:

https://github.com/saygoweb/frontaccounting-module-sgw_sales

11

(85 replies, posted in Modules/Add-on's)

s4m3shms wrote:

I was testing the sales APIs from your latest repository, none of the methods worked for me.

For example:

http://url/modules/api/sales/
or
http://url/modules/api/sales/5

returns nothing.

@s4m3shms The endpoint for the sales url needs to have a transaction type on the end, and its not optional.  So:

http://url/modules/api/sales/10

Have a look at the Sales_Test file to see an example of how to use the api using php.

https://github.com/cambell-prince/FrontAccountingSimpleAPI/blob/master-upstream/tests/Sales_Test.php


would give you all the sales invoices for example.  To get a particular invoice it would be:

http://url/modules/api/sales/5/10

assuming there was an invoice number 5.

Have a look at the Sales_Test.php file to see an example of using the api in php

https://github.com/cambell-prince/FrontAccountingSimpleAPI/blob/master-upstream/tests/Sales_Test.php

@poncho, yes with some modifications to the core the same method could be used for the ui files.  That is what this pull request implements.  Once this has been done then a theme can override the default 'classic' ui markup by adding a new implementation of the ui files along with the theme.  An example of this technique is shown in this Bootstrap 3 theme.

If this PR were included it would then be possible to have say a Bootstrap 4 renderer and a Material renderer be available as plugins (and then perhaps incorporated in the core once proven) and a whole set of Bootstrap and / or Material themes could then be very easily created.

@poncho1234 bootstrap 4 only uses js for the components which are optional.  All layout / responsive grid is entirely css only.  When using SCSS / SASS to build the styles the framework is not bloated in my opinion.  It provides a clean enough implementation of the grid system using flex box (since BS4 alpha 6).

js would still be required for components, like the date picker for example or tabs.

It would be interesting to hear what the FA devs think about such things.  As you say there's not been much interest in supporting FA on mobile / tablets.

I'm responsible for one of the forks that has morphed FA considerably.  The code is still available on GitHub.

One thing attracted me as a developer to FrontAccounting was the way in which the page views used ui functions to do all (well almost all) their rendering of html.  Because of this, all that is required to change the markup for every view is the 4 (or so) ui files.  To take advantage of current html markup frameworks, like Bootstrap or Material, the html does need to change.  Supporting multiple markup systems is easy, it just needs different implementations of the 4 (or so) ui files.  With a small amount of refactoring multiple markup systems can be supported at the same time.  This is polymorphism using classes, a very ordinary object oriented programming concept.

The modifications really are quite minor, the new ui classes diff very well against the existing ui functions.  Names are the same, parameters are the same so it is quite easy to keep the classes up to date.  I recently brought the code up to date with 2.4.3 and Bootstrap 4.

If that PR were to make it in to the core it then make it possible to safely experiment with new markup for new frameworks without breaking anything. e.g. Support for Bootstrap 4 could be introduced while still having Bootstrap 3 be the default, and so on.

There are two other ways that themes can introduce themes based on modern markup frameworks like Bootstrap.

1. Change the HTML on the fly with Javascript.  Change tags, add classes, remove classes and have a theme that works with the modified html.

2. Change the markup framework so it works specifically with FA's existing markup.  I've seen this done by some FA themes.  This is a lot of work essentially duplicating the work that went into creating Bootstrap (but easier - its based from it).  This is difficult to do well I think, its also difficult to incorporate new features from the ui framework.

I'm available to help (at no cost) should the developers want to incorporate this feature.

15

(2 replies, posted in Report Bugs here)

Sounds good to me.  If the reports could be modified to comply that would be wonderful. All the report files both declare and execute which makes them difficult to call from custom modules.  Currently I hack the input to prevent execution when including the file so that I can then execute from the module.

If core devs are keen to progress with this I'm happy to contribute some time.

16

(85 replies, posted in Modules/Add-on's)

@apmuthu we have the same definition of 'end user'; installers and maintainers of installations of Front Accounting.

For those in the community who want to use my releases I can assure them that they do not need to concern themselves about composer.  They can download a released zip or tar.gz file from:

https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases

17

(85 replies, posted in Modules/Add-on's)

@apmuthu I don't understand why an end user would care about composer?  As @s4m3shms notes it works without any dependency configuration required.  The community does not need to edit my releases for the api to work.

As to the new array declaration the only place that appears is in the not yet complete Purchases.php file.  In your code (being a copy of mine) that is not a callable endpoint either.  In my code the file is not included, where as in your code you include it in line 6 of index.php, I would suggest that you simply delete the file if you aren't planning on working on it.  Currently, for the most part its a copy of the Sales api and doesn't work - again not that its callable.  Its an artifact of work in progress.

I have no objection to you forking the code or releasing it, that's what makes open source tick.  You've contributed testing and feedback, for which I'm thankful, and I've fixed bugs.  However, I do want to make sure that statements made as to the benefits of one over the other are accurate.  You claim that mine "requires composer", I cannot see why the end user would need to be concerned with that.   The installation of my release requires downloading the zip or tarball in the releases page and unpacking into the api folder.  From that point it should "just work".  Yours does have the change to Slim which may reduce the logging noise in some versions of php.

18

(85 replies, posted in Modules/Add-on's)

My releases work without composer also.  composer is a developer tool, not an end user tool.

19

(85 replies, posted in Modules/Add-on's)

I've released version v2.4-1.4 of the Simple API for Front Accounting.  You can download it here:

https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.4

This release ensures consistency in the api parameters between POST (Create) and PUT (Update). Also ensures parameters are named consistently with their use in Front Accounting 2.4.

- Refactor tests to ensure consistency in POST and PUT api.
- Added tests/Crud_Base.php
- Add api_ensureAssociateArray to remove the numeric index elements that come from the Front Accounting functions.
- The category end point now follows the database schema more closely for property names.
- The customers end point now follows the database schema more closely for property names.

Thanks @apmuthu and @s4m3shms for testing and providing feedback.

@s4m3shms Hopefully you will now find the GET, POST and PUT behavior more consistent.

20

(85 replies, posted in Modules/Add-on's)

@s4m3shms I'm working on refactoring the tests and ensuring consistency in GET, POST and PUT for all endpoints based on your feeback (with tests).

@apmuthu.  Thanks! Fixed in https://github.com/cambell-prince/FrontAccountingSimpleAPI/commit/d3d183aa733d562e2de8536bd8f7ce3a672ae781

21

(85 replies, posted in Modules/Add-on's)

A new release of FrontAccountingSimpleAPI is available here:

https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.3

This includes support for json sent in requests using Content-Type: application/json with json encoded data in the body.

22

(85 replies, posted in Modules/Add-on's)

@s4m3shms I've just got the api working accepting JSON input with a Content-Type: application/json, its only working on my machine right now.  I'll code a unit test and hope to ship a release tomorrow.

23

(85 replies, posted in Modules/Add-on's)

@s4m3shms You'll need to use the content-type: application/x-www-form-urlencoded and ensure that your data is form encoded (not JSON).  This is how the SimpleAPI has always been since its beginning.

The unit tests show how to do this with Guzzle in php.  .NET can also do this easy enough I think.

24

(7 replies, posted in Modules/Add-on's)

@fernando_bender The font-size is simply the body font-size of 11px.  So body { font-size: 14px; } in default.css would make it bigger for example.

col-sm and col-md set media break points for different devices. e.g. sm is for phones and md is for tablets.  This controls how the controls and labels are layed out e.g. label side by side with control for desktop vs label on top of control for phone.

25

(85 replies, posted in Modules/Add-on's)

@s4m3shms I have started some documentation here but it is a long way from complete.  It is auto generated from comments in the code and I haven't the time to do that all in one go.  But its a start.

In the mean time you can learn how to use the SimpleAPI from the tests that are in the source (but excluded from the package).

https://github.com/cambell-prince/Front … r-cp/tests

As an example, the sales test shows how to list, create, update, and delete a sale.

If anyone wants to see the source annotations for the documentation you can have a look at the feature/docs branch in GitHub.