pmgr/site/models at d2d1bb3fc48346f5e9df0272e0c036738c9ae60a - pmgr

Fixed yet another bug in the merging of actions & options

2009-07-25 07:57:56 +00:00

account.php

Added the ability to edit a tender. I've locked this down to just editing the data1-4 fields at the moment, since there are accounting ramifications if we were to change the tender type.

2009-08-10 22:23:47 +00:00

contact_address.php

Finished implementation of contact edit. This is now saving everything to the database. I hope to now leverage it for a new contact. This checkin includes a bit of code in the sitelink2pmgr script that sets the customer display name. It should have been checked in several revisions ago.

2009-07-05 23:43:35 +00:00

contact_email.php

Moved the customer edit page to include address and email fields. This is largely all the work on the presentation side, now I just need to take the data and update the database.

2009-07-05 20:01:06 +00:00

contact_phone.php

Finished implementation of contact edit. This is now saving everything to the database. I hope to now leverage it for a new contact. This checkin includes a bit of code in the sitelink2pmgr script that sets the customer display name. It should have been checked in several revisions ago.

2009-07-05 23:43:35 +00:00

contact.php

Many, many changes, and yet still much to do. Many things are working, but certainly nothing beyond simply data retrieval (no editing or adding of any data). Also, some work is still required to ensure the grids have the right columns; we can strip out certain columns for some views (such as removing customer from the leases grid of the customer view... completely redundant). And of course, there are still many bugs and lots to clean up.

2009-07-23 01:49:46 +00:00

contacts_customer.php

Implemented edit functionality for customer. Like with contacts, the interface leaves much to be desired, since it's limited in functionality. Namely, you can add a contact, but you can't add contact methods (phone/mail/email). Also, it doesn't use jqGrid to present the selection choices, and so the user is stuck with the fields we've chosen to display, as well as the sort order we've chosen. Enhancement is possible someday, but for now, it gets the job done.

2009-07-06 02:06:23 +00:00

contacts_method.php

Finished implementation of contact edit. This is now saving everything to the database. I hope to now leverage it for a new contact. This checkin includes a bit of code in the sitelink2pmgr script that sets the customer display name. It should have been checked in several revisions ago.

2009-07-05 23:43:35 +00:00

customer.php

Added cached fields for charged_through and paid_through dates of a lease. Also, added the ability to dynamically determine whether a unit is late or not. In reality, we really need this to be part of the lease, not one of the status types for unit. The sitemap, however, is driven from unit information, so it's not clear whether we should move that information or not.

2009-08-13 02:37:37 +00:00

double_entry.php

Changed the deposit to use a grouped double entry instead of individual ones for each tender deposited

2009-07-29 10:10:11 +00:00

lease_type.php

Significant changes to work with the new account/ledger structure. Removed much of the auto-generated model association code. Added helper functions into the models to perform model related work, such as model 'stats' (a bad name for a function to return a summary of pertinent financial information from a given model instance). There is a ton of cleanup to do, but first I want to get it all captured.

2009-06-10 02:41:23 +00:00

lease.php

Got rid of LATE as a unit status, as it did not represent an physical condition. The logic was moved to Lease, where it is a much better fit. The sitemap still presents LATE units, as it is a useful view, but the underlying logic is driven from Lease, not Unit. This checkin also includes a small feature change to how late charges are assessed, as well as a menu item to kick off the charge assessments (both accidentally wedged in to this changeset).

2009-08-13 20:55:19 +00:00

ledger_entry.php

Added support for deleting (destroying) a transaction. This is strictly development/super-admin type functionality.

2009-08-14 20:58:50 +00:00

ledger.php

In the cleanup of r423, some code accidentally got squashed. This checkin undoes that problem

2009-07-30 06:09:05 +00:00

map.php

Significant changes to work with the new account/ledger structure. Removed much of the auto-generated model association code. Added helper functions into the models to perform model related work, such as model 'stats' (a bad name for a function to return a summary of pertinent financial information from a given model instance). There is a ton of cleanup to do, but first I want to get it all captured.

2009-06-10 02:41:23 +00:00

site_area.php

Significant changes to work with the new account/ledger structure. Removed much of the auto-generated model association code. Added helper functions into the models to perform model related work, such as model 'stats' (a bad name for a function to return a summary of pertinent financial information from a given model instance). There is a ton of cleanup to do, but first I want to get it all captured.

2009-06-10 02:41:23 +00:00

site.php

Significant changes to work with the new account/ledger structure. Removed much of the auto-generated model association code. Added helper functions into the models to perform model related work, such as model 'stats' (a bad name for a function to return a summary of pertinent financial information from a given model instance). There is a ton of cleanup to do, but first I want to get it all captured.

2009-06-10 02:41:23 +00:00

statement_entry.php

Change to how reversals are handled. In the process, I've tried to solidify _exactly_ what addTransaction will do, since it was becoming a house of cards of sorts. It was using special logic to decide things like whether to add ledger entries, statement entries, or both, whether to assignCredits afterwards, whether the generated receipt was to be considered a credit, and so on. Consequently, modifications to any calling function (addInvoice, addWaiver, etc) would often require addTransaction modifications, which would turn around and break all of the other calling functions. So, that embedded logic has been removed from addTransaction, and the rules of what addTransaction should do are now defined by the callers. This change is DEFINTELY not complete, as it probably has several bugs, and it DOES NOT YET WORK for reversals. I need a clean baseline to move forward from though, and this checkin approximates where we need to go.

2009-08-14 21:31:56 +00:00

tender_type.php

Discovered that the use of the term 'Payment' has been a misnomer. A company uses the term payment to indicate the monies it pays to _others_. Changing this leaves us without a good replacement term, but disbursement really seems to fit the bill. As comfortable as the term payment was, it was odd in many respects and disbursement does seem more appropriate. I'm sure there are several lingering bugs from this massive search/replace exercise, but this is a decent baseline for the change.

2009-08-05 01:00:09 +00:00

tender.php

Added support for deleting (destroying) a transaction. This is strictly development/super-admin type functionality.

2009-08-14 20:58:50 +00:00

transaction.php

Change to how reversals are handled. In the process, I've tried to solidify _exactly_ what addTransaction will do, since it was becoming a house of cards of sorts. It was using special logic to decide things like whether to add ledger entries, statement entries, or both, whether to assignCredits afterwards, whether the generated receipt was to be considered a credit, and so on. Consequently, modifications to any calling function (addInvoice, addWaiver, etc) would often require addTransaction modifications, which would turn around and break all of the other calling functions. So, that embedded logic has been removed from addTransaction, and the rules of what addTransaction should do are now defined by the callers. This change is DEFINTELY not complete, as it probably has several bugs, and it DOES NOT YET WORK for reversals. I need a clean baseline to move forward from though, and this checkin approximates where we need to go.

2009-08-14 21:31:56 +00:00

unit_size.php

Significant changes to work with the new account/ledger structure. Removed much of the auto-generated model association code. Added helper functions into the models to perform model related work, such as model 'stats' (a bad name for a function to return a summary of pertinent financial information from a given model instance). There is a ton of cleanup to do, but first I want to get it all captured.

2009-06-10 02:41:23 +00:00

unit_type.php

Significant changes to work with the new account/ledger structure. Removed much of the auto-generated model association code. Added helper functions into the models to perform model related work, such as model 'stats' (a bad name for a function to return a summary of pertinent financial information from a given model instance). There is a ton of cleanup to do, but first I want to get it all captured.

2009-06-10 02:41:23 +00:00

unit.php

Got rid of LATE as a unit status, as it did not represent an physical condition. The logic was moved to Lease, where it is a much better fit. The sitemap still presents LATE units, as it is a useful view, but the underlying logic is driven from Lease, not Unit. This checkin also includes a small feature change to how late charges are assessed, as well as a menu item to kick off the charge assessments (both accidentally wedged in to this changeset).

2009-08-13 20:55:19 +00:00