Decluttering configuration


Hi, wanting to explore an idea here about decluttering the configuration of iDempiere.

Thinking about and the way how I implemented it.
SysConfig is an option to configure those exceptions, but anyways in the end is a bad option.
Also I don't like adding a new column for an exception case where 99% of records in AD_Tab will have that field empty and there are a few exceptions with the value filled.

I think we add too much columns in application dictionary for exceptional cases (cluttering the configuration). In the end we have a system that just experts can configure, and some of the options make the system too brittle. There are options that if somebody changes inadvertently can mess the system up.

So, I was thinking if would be easier to have some tables to define exceptions.

I mean, for example the specific case of is to configure a different DetailPagingSize for a few tabs, instead of adding AD_Tab.PagingDetailSize we have the following structure:

Table AD_TabNDC (NDC means non-default-configuration - but we can think a better name)


  • AD_Tab_ID -> for example the tab Calendar Year and Period > Period

  • Property -> PagingDetailSize

  • Value -> 12

So, the whole system has a default and we define the exceptions in that table. This can be similar to SysConfig (system and client) but more focused on specific properties of the system.

Maybe we can have a table itself for the properties and their system-wide default values.

AD_PropertyDC (Property default configuration)

  • Property -> PagingDetailSize

  • Value -> 10 -> system-wide default value (or we can make it client+system in some cases same as SysConfig)

And in future, when needing to add an option that is exceptionally configured, we can simply add it as a default property and allow to fine-grain configure it in the exception tables, instead of adding a new direct field in dictionary, or a new cryptic SysConfig.

Also, some actual SysConfig are candidates to move to this new approach. And maybe the concept can be extended also to some client-side tables where you need a new column with a default value and rare exceptions configured in some records.



I think we have a lot of candidates for this approach, and we can clean up some configuration from dictionary, for example:


  • WinWidth and WinHeight (I think this is not used in zk, maybe we can simply remove it)

  • System Color doesn't work -> can be removed

  • TitleLogic (mostly empty and just a few windows will have this filled)

  • Image? -> we have 20 windows with image from 424 (less than 5%) - in this case the property would be an ID - would need to think how to model it

  • IsBetaFunctionality -> could be made a property - we basically don't use this in core


  • IsSingleRow -> just 21 from 1081 has 'N' - and probably is a misconfiguration

  • MaxQueryRecords

  • CommitWarning? -> just 9 from 1081

  • AD_Image_ID -> I think this is not being used


  • ObscureType? -> 5 from 19958 records have configured this

  • IsHeading -> zero in core

  • IsFieldOnly -> 8 from 19958

  • IsDefaultFocus -> zero in core

  • IsEncrypted -> 33 from 19958
    Some of the options in "Overwritten From Column" group are also applicable here, like "Allow Copy" or "Value Format"


  • IsChangeLog -> this is maybe also better to have a system-wide default and people configure exceptions

  • IsHighVolume -> 37 from 961 different from default


  • Version -> we don't use this

  • IsAutoComplete?

  • VFormat

  • IsHtml

  • FormatPattern


  • AllowMultipleExecution

  • ExecutionType

  • IsBetaFunctionality

  • ShowHelp

  • IsServerProcess


  • VFormat

  • IsEncrypted




Deepak Pansheriya
September 3, 2020, 1:56 PM

To me solution is to store data in EV model. And our attribute set instance is one example.

This may be solution for GUI, and possible design.

  1. We Apply and introduce Attribute Set Type as Application Dictionary Extension (ADX)

  2. On AD_Table we add flag, isAttributeEnabled (Allow Additional Attribute).

  3. When Attribute set type is ADX, We allow to attach Table which has marked isAttributeEnabled=True.

  4. When AD_Table has isAttributeEnabled flag marked, we show toolbar button which launch attribute update dialog where a value can be provided for available attributes of attached ASI

  5. We store values added in this editor in table AD_ExtraProperty or AD_PropertyExtension or AD_ExtensionAttribute having AD_Table_ID, AD_Record_ID, M_Attribute_ID, Value (all field as we have in attribute instance)

  6. We create cashed method which bring all Key value pair for given table id and record id.

Alternative to #1, 2 and 3 below can be done too.

  1. on Attribute tab, add flag isADExtension (Extension Attribute).

  2. Add sub tab to Attribute to provide all applicable tables.

Also we apply which is presents in logiliteERP and patch on ticket. This let support all reference types supported on AD_Column.

Carlos Ruiz
September 3, 2020, 3:11 PM

Hi , has a pending pull request - the integration from the patch was not possible and has been working on that ticket - would be great to have your peer review and help.

Same for - if it can be converted in a pull request would be great.

I'm not sure if I understand completely your idea to use attributes as user configuration - but it can be because I haven't seen those two tickets working.


Carlos Ruiz

Deepak Pansheriya
September 3, 2020, 3:40 PM

IDEMPIERE-2955, we added AttributeSet_Type on Attribute set and set current all attribute set as Material Management = MM type. Purpose was to use Attribute Set model on different purpose. iDempiere default usage is in Material Management.

I am suggesting new type as Application Dictionary Extension. other then that we are using same in our DMS plugin as document metadata.


I am adding reviewing changes of IDEMPIERE-2999, and comparing to one we have which are attached as patch to ticket.

Heng Sin Low
September 21, 2020, 6:41 AM

One issue with the proposal above to add AttributeSet_Type to the M_AttributeSet table is it breaks iDempiere’s table name convention where C_ is for common tables and M_ is for material management tables.

Deepak Pansheriya
September 21, 2020, 6:51 AM

Agree. Should we plan to rename them?




Carlos Ruiz



Tested By