Search options (Page 1 of 6)

Hi,

As far as I know this cannot be done with existing core functionality.  I've done this in one of my modules though. I've created a PagerInterface and there are two implementations one for query data, and one for "Model" data (my code has data in several 'Model' classes).  Here's a link to that:

https://github.com/saygoweb/frontaccounting-module-sgw_sales/tree/master/includes/common/Pager

This did require a few changes in the core to support.  These changes are here.

https://github.com/cambell-prince/frontaccounting/commit/60a6218858ae6a5d7793ab180a62f0deed57b951

Those changes are based off a fork that I use, not based off the current core.  So, you'd need to adapt as necessary to fit the current core.

Hi,

@DrCard

To "delete" an invoice you need to void the invoice.  In src/Journal.php you'll see the implementation of delete which voids a transaction.  This is on the endpoint '/modules/api/journal/'.

The tests are in tests/Journal_Tets.php which demonstrates a full Create Read Update Delete test cycle.

You'll need to do a little research on the $type parameter.  I think "10" is for invoice from memory - not sure.

BTW, I was a contributor to the api back in 2018.

I recommend fail2ban on the server side for bruteforce detection and rejection via iptables. It can detect repeated access of the login page and x accesses in n seconds will trigger the ban.

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.

@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.

@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  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.

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

@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.

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.

@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

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