Re-engineer Property functionality

Idea created by dukecityrebecca on Mar 8, 2016
    Not planned

    The way properties are built in the database doesn't allow for different types of data or easy parsing (all are merely rows of text in a big table).  If properties could be built more like fields to enable field formatting - date, 3-byte integer, 5-byte integer as well as text.  Plus we need more validation rule types, like multiple select.  Multi-select example, a property may need 3 out of 5 of the property rule values on a single request.


    Enable properties to be built apart from the category.  For example, I want to build a set of properties that apply to 20 Request Areas.  I should be able to build 1 set of properties and then attach to however many areas as I want (and of course, I must be able to multiple select those categories 8pt; padding: 0px;"> 

    Finally for reporting in Xtraction, I had to build a table w/ SQL join per Sequence+label to "field-ify" each property.  Unfortunately, any 'date' or 'number' properties are reported as text & unable to take advantage of Xtraction date filtering, etc.  If the properties were built more like fields with formatting, we could enable better reporting.


    And we don't want to create database fields since the properties are more fluid - they change, need relabeling more frequently than a static column.  Plus, we have two sets of customers who want very specific - and different sets of properties, so they really apply to different groups of categories. That would be a lot of SQL fields changing frequently that aren't used globally - not first choice.