[CORE-1708] Add support for config option logic - Blesta

Paul Phillips created issue - 12/Jun/15 12:23 PM

Hide

Permalink

Cody Phillips (Inactive) added a comment - 16/Jun/15 5:58 PM - edited

Rules for creating conditionals will become very complex very quickly (there's a reason we don't manipulate GUIs to create code). GUIs aren't (currently) capable of implementing the type of business logic that would be required to do something like this.

I think we're going to need scripting of some kind for this. Probably javascript.

Show

Cody Phillips (Inactive) added a comment - 16/Jun/15 5:58 PM - edited Rules for creating conditionals will become very complex very quickly (there's a reason we don't manipulate GUIs to create code). GUIs aren't (currently) capable of implementing the type of business logic that would be required to do something like this. I think we're going to need scripting of some kind for this. Probably javascript.

Cody Phillips (Inactive) made changes - 04/Aug/15 1:55 PM

Field	Original Value	New Value
Description	There is a case for displaying config options based on the selection of another. Add support for configurable option conditionals. Consider the following case: We are selling a dedicated server and one of the configurable options is RAID. Let's say the options are RAID 1 (mirroring), RAID 5 (stripe with parity), and RAID 10 (stripe with mirroring). If the user selects RAID 1 we may want to show 2 fields for hard drives. Hard Drive 1, and Hard Drive 2. If they select RAID 5, we may want to show Hard Drive 1, Hard Drive 2, and Hard Drive 3. If RAID 10, all of the above including Hard Drive 4. Conditionals would be set on a specific configurable option such that "If Option Name" is set to, then (Hide, Show, or Set Value) for "dropdown of other config options in the group". Since config options can belong to more than one group, this option may need to be tied to the config option group so that it doesn't reference a config option in another group. This item requires more information.	There is a case for displaying config options based on the selection of another. Add support for configurable option conditionals. An option can only control other options that share its same group(s). \|\|FIELD TYPE\|\|If FIELD NAME Set to\|\|Then\|\|This Field\|\| \|select, radio, checkbox\| Select menu of possible options \| Select menu of 'show', 'hide' \| Select menu of all other options in any of the groups this option is in \| \|quantity\| Select menu of '>', '<', '=' \| Select menu of 'show', 'hide' \| Select menu of all other options in any of the groups this option is in \| The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD. The DB would be something like: package_option_logic \|\|id\|\|option_id\|\|condition\|\|value\|\|trigger\|\|trigger_option_id\|\| \|auto increment Primary Key\|Key 1\|enum(>,<,=)\|varchar(255)\|enum(show,hide)\|Key 2

Cody Phillips (Inactive) made changes - 04/Aug/15 1:57 PM

Description

There is a case for displaying config options based on the selection of another. Add support for configurable option conditionals.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

There is a case for displaying config options based on the selection of another. Add support for configurable option conditionals.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

Cody Phillips (Inactive) made changes - 04/Aug/15 1:57 PM

Summary

Add support for config option conditionals

Add support for config option logic

Cody Phillips (Inactive) made changes - 04/Aug/15 2:28 PM

Description

There is a case for displaying config options based on the selection of another. Add support for configurable option conditionals.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

There is a case for displaying config options based on the selection of another. Add support for configurable option logic.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

The client should request the logic for a particular package group (i.e. http://host/blesta/optionlogic/5), which would return a JSON object containing the logic for all options in the supplied package group.

{noformat}
{
"id":
}
{noformat}

Cody Phillips (Inactive) made changes - 04/Aug/15 2:32 PM

Description

There is a case for displaying config options based on the selection of another. Add support for configurable option logic.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

The client should request the logic for a particular package group (i.e. http://host/blesta/optionlogic/5), which would return a JSON object containing the logic for all options in the supplied package group.

{noformat}
{
"id":
}
{noformat}

There is a case for displaying config options based on the selection of another. Add support for configurable option logic.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

The client should request the logic for a particular package group (i.e. http://host/blesta/optionlogic/5), which would return a JSON structure containing the logic for all options in the supplied package group.

{noformat}
[
  {
    "id": 1,
    "option_id": 1,
    "condition": "=",
    "value": "1024",
    "trigger": "show",
    "trigger_option_id": 2
  },
  {
    "id": 1,
    "option_id": 2,
    "condition": "=",
    "value": "option value",
    "trigger": "show",
    "trigger_option_id": 3
  }
]
{noformat}

Cody Phillips (Inactive) made changes - 04/Aug/15 2:37 PM

Description

There is a case for displaying config options based on the selection of another. Add support for configurable option logic.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

The client should request the logic for a particular package group (i.e. http://host/blesta/optionlogic/5), which would return a JSON structure containing the logic for all options in the supplied package group.

{noformat}
[
  {
    "id": 1,
    "option_id": 1,
    "condition": "=",
    "value": "1024",
    "trigger": "show",
    "trigger_option_id": 2
  },
  {
    "id": 1,
    "option_id": 2,
    "condition": "=",
    "value": "option value",
    "trigger": "show",
    "trigger_option_id": 3
  }
]
{noformat}

There is a case for displaying config options based on the selection of another. Add support for configurable option logic.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

The client should request the logic for a particular package group (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package group.

{noformat}
[
  {
    "id": 1,
    "option_id": 1,
    "condition": "=",
    "value": "1024",
    "trigger": "show",
    "trigger_option_id": 2
  },
  {
    "id": 1,
    "option_id": 2,
    "condition": "=",
    "value": "option value",
    "trigger": "show",
    "trigger_option_id": 3
  }
]
{noformat}

Cody Phillips (Inactive) made changes - 09/Oct/15 3:34 PM

Fix Version/s

Short Term [ 10800 ]

Hide

Permalink

Paul Phillips added a comment - 09/Nov/15 5:22 PM

Does this also support pre-selecting a config option value based on the selection of another?

Show

Paul Phillips added a comment - 09/Nov/15 5:22 PM Does this also support pre-selecting a config option value based on the selection of another?

Hide

Permalink

Cody Phillips (Inactive) added a comment - 09/Nov/15 5:27 PM

No, I think we discussed adding that in the future since that's an additional layer of complexity.

Show

Cody Phillips (Inactive) added a comment - 09/Nov/15 5:27 PM No, I think we discussed adding that in the future since that's an additional layer of complexity.

Paul Phillips made changes - 17/Dec/20 2:21 PM

Fix Version/s		Sponsored [ 11113 ]
Fix Version/s	Short Term [ 10800 ]

Jonathan Reissmueller made changes - 23/Dec/20 2:41 PM

Rank

Ranked higher

Jonathan Reissmueller made changes - 23/Dec/20 2:54 PM

Rank

Ranked lower

Jonathan Reissmueller made changes - 23/Dec/20 7:04 PM

Rank

Ranked higher

Jonathan Reissmueller made changes - 28/Dec/20 11:45 AM

Story Points

8

Jonathan Reissmueller made changes - 28/Dec/20 12:37 PM

Rank

Ranked higher

Paul Phillips made changes - 28/Dec/20 1:53 PM

Assignee

Cody Phillips [ cody ]

Jonathan Reissmueller made changes - 28/Dec/20 3:02 PM

Description

There is a case for displaying config options based on the selection of another. Add support for configurable option logic.

An option can only control other options that share its same group(s).

||FIELD TYPE||If *FIELD NAME* Set to||Then||This Field||
|*select*, *radio*, *checkbox*| Select menu of possible options | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |
|*quantity*| Select menu of '>', '<', '=' | Select menu of 'show', 'hide' | Select menu of all other options in any of the groups this option is in |

The config option would need to be in a saved state, as the storage of the conditional logic would require that the option and all values be stored. So how the UI is implemented is TBD.

The DB would be something like:

*package_option_logic*
||id||option_id||condition||value||trigger||trigger_option_id||
|auto increment Primary Key|Key 1|enum(>,<,=)|varchar(255)|enum(show,hide)|Key 2

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

The client should request the logic for a particular package group (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package group.

{noformat}
[
  {
    "id": 1,
    "option_id": 1,
    "condition": "=",
    "value": "1024",
    "trigger": "show",
    "trigger_option_id": 2
  },
  {
    "id": 1,
    "option_id": 2,
    "condition": "=",
    "value": "option value",
    "trigger": "show",
    "trigger_option_id": 3
  }
]
{noformat}

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||*FIELD NAME*||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_logic*
||id||option_group_id||option_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "id": 1,
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "id": 1,
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Jonathan Reissmueller made changes - 28/Dec/20 3:32 PM

Description

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||*FIELD NAME*||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_logic*
||id||option_group_id||option_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "id": 1,
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "id": 1,
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||*FIELD NAME*||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_condition_sets*
||id||option_group_id||option_id||
|auto increment Primary Key|Index 1|Index 2|

*package_option_group_conditionals*
||id||condition_set_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Jonathan Reissmueller made changes - 28/Dec/20 3:34 PM

Description

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||*FIELD NAME*||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_condition_sets*
||id||option_group_id||option_id||
|auto increment Primary Key|Index 1|Index 2|

*package_option_group_conditionals*
||id||condition_set_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||Field Name||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_condition_sets*
||id||option_group_id||option_id||
|auto increment Primary Key|Index 1|Index 2|

*package_option_group_conditionals*
||id||condition_set_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Jonathan Reissmueller made changes - 28/Dec/20 3:57 PM

Description

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||Field Name||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_condition_sets*
||id||option_group_id||option_id||
|auto increment Primary Key|Index 1|Index 2|

*package_option_group_conditionals*
||id||condition_set_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||Field Name||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_condition_sets*
||id||option_group_id||option_id||
|auto increment Primary Key|Index 1|Index 2|

*package_option_group_conditionals*
||id||condition_set_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Abstracting config option display and validation would be nice

Jonathan Reissmueller made changes - 05/Jan/21 11:29 AM

Description

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Display Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||Field Name||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_condition_sets*
||id||option_group_id||option_id||
|auto increment Primary Key|Index 1|Index 2|

*package_option_group_conditionals*
||id||condition_set_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Abstracting config option display and validation would be nice

Create a new option for Configurable Option Groups after 'Edit' and label it "Edit Option Dependencies".

The linked page should control settings for displaying config options based on the selected value of another (we'll call this configurable option logic). This page should contain a tab for each configurable option assigned to the group. Each of these tabs should contain at least a button labeled "Add Condition Set". When clicked a new instance of the following table should be created before the button:

||Field Name||Condition||Value||Then||Options||
| Select menu of config options in this group | Select menu of '>', '<', '=', 'In List' | Select menu of values for the selected option OR text field | Select menu of 'show', 'hide' | Add, Remove|
* Lists of values should be comma separated, add a tooltip mentioning this.
* Value select menu should be should IFF the source field is a select or radio type
* A link should be displayed just bellow the table "Remove Set"
* A text block should be displayed under the table (before the button but after the link) "OR..."

The DB would be something like:

*package_option_group_condition_sets*
||id||option_group_id||option_id||
|auto increment Primary Key|Index 1|Index 2|

*package_option_group_conditionals*
||id||condition_set_id||trigger_option_id||condition||value||trigger||
|auto increment Primary Key|Index 1|Index 2|enum(>,<,=,in)|varchar(255)|enum(show,hide)

*Option logic* would be evaluated client side (javascript) and server side when saved to ensure no invalid options are provided.

When options are fetched for configuration we should also fetch a list of conditionals for the current package (i.e. http://host/blesta/package_options/logic/5), which would return a JSON structure containing the logic for all options in the supplied package.

{noformat}
[
  {
    "option_id": 1,
    "trigger_option_id": 2
    "condition": "=",
    "value": "1024",
    "trigger": "show",
  },
  {
    "option_id": 2,
    "trigger_option_id": 3
    "condition": "=",
    "value": "option value",
    "trigger": "show",
  }
]
{noformat}

Abstracting config option display and validation would be nice

Hide

Permalink

Jonathan Reissmueller added a comment - 05/Jan/21 11:30 AM

A couple things are not covered by the task description yet.

We should be able to show/hide not only whole options, but also particular values in the case of radio and dropdown
We should have a setting on the config option group "Hide disable options/values" that is checked by default. It should have a tooltip "When a configurable option or value is disabled via option dependencies, hide it from the user entirely."

Show

Jonathan Reissmueller added a comment - 05/Jan/21 11:30 AM A couple things are not covered by the task description yet. We should be able to show/hide not only whole options, but also particular values in the case of radio and dropdown We should have a setting on the config option group "Hide disable options/values" that is checked by default. It should have a tooltip "When a configurable option or value is disabled via option dependencies, hide it from the user entirely."

Jonathan Reissmueller made changes - 05/Jan/21 11:31 AM

Fix Version/s

5.1.0-b1 [ 11703 ]

Jonathan Reissmueller made changes - 05/Jan/21 11:31 AM

Sprint

5.1.0 Sprint 3 [ 127 ]

Jonathan Reissmueller made changes - 05/Jan/21 11:31 AM

Rank

Ranked higher

Jonathan Reissmueller made changes - 19/Mar/21 12:11 PM

Assignee

Jonathan Reissmueller [ jonathan ]

Jonathan Reissmueller made changes - 19/Mar/21 12:14 PM

Issue Type

New Feature [ 2 ]

Story [ 7 ]

Jonathan Reissmueller made changes - 19/Mar/21 12:40 PM

Status

Open [ 1 ]

In Progress [ 3 ]

Jonathan Reissmueller made changes - 23/Mar/21 6:34 PM

Remaining Estimate		0 minutes [ 0 ]
Time Spent		1 hour, 7 minutes [ 4020 ]
Worklog Id	14820 [ 14820 ]

Jonathan Reissmueller made changes - 25/Mar/21 5:37 PM

Time Spent	1 hour, 7 minutes [ 4020 ]	1 day, 1 hour, 13 minutes [ 33180 ]
Worklog Id	14825 [ 14825 ]

Jonathan Reissmueller made changes - 09/Apr/21 4:04 PM

Status	In Progress [ 3 ]	In Review [ 5 ]
Resolution		Fixed [ 1 ]

Jonathan Reissmueller made changes - 12/Apr/21 11:16 AM

Sprint

5.1.0 Sprint 3 [ 127 ]

5.1.0 Sprint 4 [ 131 ]

Jonathan Reissmueller made changes - 12/Apr/21 11:16 AM

Rank

Ranked lower

Jonathan Reissmueller made changes - 16/Apr/21 10:26 AM

Time Spent	1 day, 1 hour, 13 minutes [ 33180 ]	1 day, 4 hours, 1 minute [ 43260 ]
Worklog Id	14869 [ 14869 ]

Jonathan Reissmueller made changes - 16/Apr/21 11:43 AM

Status

In Review [ 5 ]

Closed [ 6 ]

Jonathan Reissmueller made changes - 14/May/21 4:00 PM

Resolution	Fixed [ 1 ]
Status	Closed [ 6 ]	Reopened [ 4 ]

Jonathan Reissmueller made changes - 14/May/21 4:23 PM

Status	Reopened [ 4 ]	In Review [ 5 ]
Resolution		Fixed [ 1 ]

Jonathan Reissmueller made changes - 18/May/21 11:09 AM

Sprint

5.1.0 Sprint 4 [ 131 ]

5.1.0 Sprint 4, 5.1.0 Sprint 6 [ 131, 133 ]

Jonathan Reissmueller made changes - 18/May/21 11:09 AM

Rank

Ranked higher

Abdy Franco made changes - 18/May/21 12:22 PM

Time Spent	1 day, 4 hours, 1 minute [ 43260 ]	1 day, 4 hours, 55 minutes [ 46500 ]
Worklog Id	14936 [ 14936 ]

Jonathan Reissmueller made changes - 18/May/21 3:41 PM

Status

In Review [ 5 ]

Closed [ 6 ]

Add support for config option logic

Details

Description

Sub-Tasks

Activity

People

Dates

Time Tracking

Agile