Trying to get a feel for plugin flow...

[seebs]

So I'm looking at possibly implementing some additional functionality, and I'd rather do it as a plugin than modify the base code, but I'm not quite sure I understand the plugin flow.

I have two things I'd like to add, both of which would be adding additional fields to things which currently don't have them. One is a mechanism for adding custom fields which can have unique values per invoice, so, similar to client custom fields, but invoice-based. Another would be a per-line-item discount amount. (So, a thing that shows up on the same line, rather than as a separate coupon.) In both cases, it looks like I'd need to add columns to the database.

Looking at the developer docs, it appears that a plugin's install/uninstall can modify tables, so I could add columns. But when I get to actually using the data, it's not as obvious what I'd do. Looking in models/invoices.php, there's a specific list of fields that will be updated:

$fields = [
    'client_id', 'date_billed', 'date_due', 'date_closed', 'date_autodebit',
    'status', 'previous_due', 'currency', 'note_public', 'note_private'
];

I don't see any general mechanism for adding additional fields, so I'm not sure how a plugin would modify this. Event handler? But even then, I can't actually change this code from a plugin, so the best I could do would be to make a separate query to update my fields. Am I missing something obvious?

[Paul]

I would highly recommend not modifying existing tables. Plugins are designed to be able to create or modify their own tables, but modifying core tables could prove very problematic. In terms of tying into existing functionality, you might look at Event Handlers also known as hooks. Tying into the Invoices.add event, would allow you to edit an invoice right after it's created and add additional line items or make other modifications to it before it's emailed out.

If you need to display additional information on an invoice that's not there now, or can't be added by modifying an existing invoice, you should create your own tables for this data. It then may be necessary to create a custom invoice template that one could use instead of the default, that could fetch the information from those new tables for display.

[seebs]

Okay, fair enough. So if we need extra fields for invoices or line items, we should make new tables with a foreign key pointing at the built-in tables, and add data there?

Is it practical to intercept/alter the actual computation-of-cost for line items, or services? The goal here is to end up with a single line which displays the line item, its normal base price, and any discount all as one thing, rather than with a second line for the coupon. (I'm also not sure about the coupon thing, because it looks like users can decide which coupons to apply, and the goal here would be to have admin/staff control over these discounts.)