Add custom fields for catalog objects (i.e. plans, products)

[bvisonl]

I've been trying to figure out how could I get custom fields on all the entities that are inside the catalog. I've spent quite some time digging around and I think that I get the "why" custom fields are not allowed in Catalog, Product, Plans, etc. However, there may be a lot of use for them.

An easy way out of this that I can see is just updating the schema to allow a section of key/value items that would later be used by the kbcli. I'm thinking that, for example, the Plan entity could have a field called <CustomFields>...</CustomFields> which could end up being just a map[string]string or something like that in the kbcli. That would make it easy enough so that it doesn't break any existing logic related to the catalog and flexible enough so that anyone using the kbcli can extend the functionality of KillBill even more without needing to write a whole plugin.

I think that the schema is so closed and tight in validation that it makes it a little bit hard to build logic around anything catalog-related that's outside the rules / alignments scope.

Right now I am attempting to enable this by modifying the xsd but that doesn't seem to be working when I try to upload the catalog.

Example of what I want in the XSD

    <xs:complexType name="defaultPlan">
        <xs:complexContent>
            <xs:extension base="validatingConfig">
                <xs:sequence>
                    <xs:element minOccurs="0" name="effectiveDateForExistingSubscriptions" type="xs:dateTime"/>
                    <xs:element name="product" type="xs:IDREF"/>
                    <xs:element minOccurs="0" name="recurringBillingMode" type="billingMode"/>
                    <xs:element minOccurs="0" name="initialPhases">
                        <xs:complexType>
                            <xs:sequence>
                                <xs:element maxOccurs="unbounded" minOccurs="0" name="phase" type="defaultPlanPhase"/>
                            </xs:sequence>
                        </xs:complexType>
                    </xs:element>

                   <!-- Note this here -->
                    <xs:element minOccurs="0" name="customFields">
                        <xs:complexType>
                            <xs:sequence>
                                <xs:element maxOccurs="unbounded" minOccurs="0" name="customField" type="defaultCustomField"/>
                            </xs:sequence>
                        </xs:complexType>
                    </xs:element>

                    <xs:element name="finalPhase" type="defaultPlanPhase"/>
                    <xs:element minOccurs="0" name="plansAllowedInBundle" type="xs:int"/>
                </xs:sequence>
                <xs:attribute name="name" type="xs:ID" use="required"/>
                <xs:attribute name="prettyName" type="xs:string"/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
   
   ...

    <xs:complexType name="defaultCustomField">
        <xs:complexContent>
            <xs:extension base="validatingConfig">
                <xs:attribute name="key" type="xs:string" use="required"/>
                <xs:attribute name="value" type="xs:string" use="required"/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

So that later in the catalog I can do:

...
        <plans>
            <plan name="my-plan">
                <product>THE_PRODUCT</product>
                <initialPhases>
                </initialPhases>
                <customFields>
                    <customField key="foo" value="bar" />
                </customFields>
...

Any idea on how to get this done is welcome!

[kakarot-101]

Absolutely! Incorporating custom fields for catalog objects, such as plans and products, enables tailored support for diverse information needs. By adding custom fields, you can enhance the catalog's versatility and accommodate various requirements, ensuring it can efficiently support your business operations. Whether it's capturing unique identifiers, specialized attributes, or specific categorizations, these custom fields empower your catalog to provide comprehensive support for your organization's evolving needs. Let me know if you need further guidance on implementing this enhanced support functionality!

[shaun-forgie]

The team at Bill Rush could also leverage the XML schema catalog extension mechanism to attach a variety of additional data elements including: revenue recognitiion policies that used custom fields for chart of account codes and default tax rate policies that used custom fields for sales tax rates. These could be attached to either product or plan definitions.

The alternative would be to develop separate XML files for both revenue recognition and tax policies that could reference product or plans defined within an existing catalog. The only problem would be that these may be removed in a future version of the catalog invaliding the policies that reference them.