abijah 3953e1dbf3 Added stats summary to the top level for lease. For consistency, I want all stats to be summarized at the top. ...

git-svn-id: file:///svn-source/pmgr/branches/ledger_transactions_20090605/site@175 97e9348a-65ac-dc4b-aefc-98561f571b83

2009-06-22 17:55:32 +00:00

..

accounts_controller.php

Moved the ledger_entries controller/view to jqGrid.

2009-06-15 19:41:20 +00:00

contacts_controller.php

Fixed a bug in which jqGrid would fetch data from the current controller, not the controller responsible for populating the data. Added the ability to fetch data based strictly off of an ID list, which is useful for lists that are embedded in other pages, where the list conditions are entirely foreign to the controller responsible for providing the data. To assist with this one jqGrid virtual function needed the model added as a parameter, so I added it to them all and modified the jqGrid functions in the existing derived controllers. Right now the elements (such as contacts.ctp, the only working one) receive a full list of data to populate themselves. I could have simply taken this and passed it directly to jqGrid, with no need for further server interaction. However, this could result in some very large lists, and although pagination will ensure the user is not overwhelmed, the connection or the browser could be. Unless we have a strong performance need, I'll keep it this way. In the meantime, I'll leave the underlying data available to each element, in case I have to switch over. When all is proven out, I can simplify all the queries such that the extra data is never requested in the first place.

2009-06-14 22:05:44 +00:00

customers_controller.php

Further progress on payment entries. There is an outstanding charges grid, but it doesn't have amounts due to the way I designed the ledger_entries element. I'll do a bit of rework on that next.

2009-06-18 00:49:40 +00:00

leases_controller.php

Added stats summary to the top level for lease. For consistency, I want all stats to be summarized at the top.

2009-06-22 17:55:32 +00:00

ledger_entries_controller.php

Although I'm not too happy with the modifications, I do have a working version that minimizes the columns need to display ledger entries. The logic feels screwy to me, but I've beat my head on it long enough. I'll move on to something else and come back to it when my head clears.

2009-06-18 03:57:43 +00:00

ledgers_controller.php

Yet another place where Ledger.name was being used.

2009-06-16 08:38:31 +00:00

maps_controller.php

Moved map listings to jqGrid, and fixed cut/paste error in the comments of the transactions controller.

2009-06-15 21:34:35 +00:00

monetary_sources_controller.php

Added an element for monetary_sources. Not sure if it will get used, but it was easy enough to do.

2009-06-15 21:45:07 +00:00

pages_controller.php

Load pmgr into branches/initial_20090526/site.

2009-05-27 04:18:23 +00:00

transactions_controller.php

Checking in completely non-working code, as I'm just trying to get a full checkin before the weekend. I cannot yet seem to get the Reconcilation entries to save.

2009-06-19 16:22:28 +00:00

units_controller.php

Fixed a bug in which jqGrid would fetch data from the current controller, not the controller responsible for populating the data. Added the ability to fetch data based strictly off of an ID list, which is useful for lists that are embedded in other pages, where the list conditions are entirely foreign to the controller responsible for providing the data. To assist with this one jqGrid virtual function needed the model added as a parameter, so I added it to them all and modified the jqGrid functions in the existing derived controllers. Right now the elements (such as contacts.ctp, the only working one) receive a full list of data to populate themselves. I could have simply taken this and passed it directly to jqGrid, with no need for further server interaction. However, this could result in some very large lists, and although pagination will ensure the user is not overwhelmed, the connection or the browser could be. Unless we have a strong performance need, I'll keep it this way. In the meantime, I'll leave the underlying data available to each element, in case I have to switch over. When all is proven out, I can simplify all the queries such that the extra data is never requested in the first place.

2009-06-14 22:05:44 +00:00