Add enum / constants classes for Accounting and PayrollAU and a fluent whereDate to query builder

[Healyhatman]

Add constant/enum-like classes for all the Types for Accounting and PayrollAU

I've added them under Enums because one day we can make them actual enums and you call them PROPERTY_TYPE_ENUM anyway. Additionally, they don't belong in Models because they're not models

All the const names are copied directly from Accounting => Types and PayrollAU => Types and Codes

I copy+pasted and did it all manually because I don't have your fancy auto-scraping powers

Mark (some?) old constant classes as deprecated and point to the new classes
Add some "@see" docblock comments pointing to the new classes

Fix return types

• PayrollAU
  • Setting/TrackingCategory
  • Setting

Add more fluent ->whereDate function to query builder.

Usage examples

// Invoices on a particular date
$application->load(Invoice::class)->whereDate(new DateTime('2023-01-01'));

// Invoices between a particular date range
$application->load(Invoice::class)
   ->whereDate(new DateTime('2021-12-01'), '>')
   ->whereDate(new DateTime('2021-12-30'), '<');

[calcinai]

Did you have a suggested migration path for this? There are obviously a couple of braking changes in there, so this will need to be in a major release.

Related: there should be readme updates to use the enums instead.

A lot of work in there though, looks good.

[Healyhatman]

There shouldn't be any breaking changes, except for removing AUSTRALIUM which has been marked deprecated for like 3 years right? Or did I break something else and was just to tired to see it ha

…

Message ID: ***@***.***>

[calcinai]

Yeah although strictly speaking, we shouldn't be (potentially) causing fatals without a major version bump. Even for deprecations..

I see some ORGANISATION_* constants removed and some functions, too.

[Healyhatman]

Sorry about that, right you are.

The functions were removed because that endpoint is GET only so those functions shouldn't be there.

I'd rather save a version bump for something cool like moving to PHP 7.4. If you prefer I can simply discard the breaking changes?

[calcinai]

Yeah probably the best, if that's ok.

I think PHP7.4 might be a waste, given it's EOL...

[Healyhatman]

I'm happy to go straight to 8.1, love that

[Healyhatman]

OK there you go breaking changes removed. Let me know if I missed any.

Could I leave the readme.md bit to you? Or where in it would you want me to make changes and what do you need it to say?

[calcinai]

@Healyhatman just wondering if we're deprecating the constants on the classes themselves, or what the actual forward path is with the enums–and making the sure the Readme.md reflects the usage correctly.

[Healyhatman]

Yes I believe it would be best to deprecate the enums in the model classes and moving forward use the enum classes.

Do you need me to add other enums from the other things?

…

Message ID: ***@***.***>

[Healyhatman]

Because I can if you need me to

[calcinai]

Sorry the last couple of weeks have been pretty hectic over here.

Do you need me to add other enums from the other things?

Which other things do you mean? All I was suggesting is consistency across all models etc

[Healyhatman]

I would like everything everywhere to use the constants I've made, but I didn't want to remove any from the models because people might be relying on them and it'll break their code.

[Healyhatman]

So whatcha reckon, what do you need I'll get it done

[calcinai]

Ok cool, well I think a few things should happen

• Move the whereDate to a seperate PR, and that can go in right away.
• Update the Readme.md to reflect the usage of the enum classes, rather than the model constants
• Add deprecated tags to the class constants

One last thought–why don't we go straight to actual enums, then force PHP8.1 from hereon out?

[Healyhatman]

I'd love that, then we can also enforce types on the functions that warrant it.

[calcinai]

The current version is stable, so we can just put it on a legacy branch and make master PHP8. If you're happy to test that out, just break it up into a few PRs

[bretto36]

This is great. Just noticed a couple that didn't match the docs

[bretto36]

https://developer.xero.com/documentation/api/accounting/types/#organisation

In the docs it has

ACCOUNTING_PRACTICE
CHARITY
CLUB_OR_SOCIETY
COMPANY
INDIVIDUAL
LOOK_THROUGH_COMPANY
NOT_FOR_PROFIT
PARTNERSHIP
S_CORPORATION
SELF_MANAGED_SUPERANNUATION_FUND
SOLE_TRADER
SUPERANNUATION_FUND
TRUST

[bretto36]

You think it's worth putting the rates here as a secondary const BLINPUT_RATE = 0

[bretto36]

these should be uppercase? - https://developer.xero.com/documentation/api/payrollau/types-and-codes#leaveapplications