Details
-
Type:
Story
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.4.0
-
Component/s: Staff Interface
-
Labels:None
Description
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.
[
{
"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",
}
]
Abstracting config option display and validation would be nice
1. |
Config option logic database changes |  |
Closed | Jonathan Reissmueller |
|
||||||||
2. |
Config option logic configuration page | |
Closed | Jonathan Reissmueller |
|
||||||||
3. |
Config option logic display | |
Closed | Jonathan Reissmueller |
|
||||||||
4. |
Config option logic validation | |
Closed | Jonathan Reissmueller |
|
||||||||
5. |
Order: Config option logic | |
Closed | Jonathan Reissmueller |
|
Activity
Does this also support pre-selecting a config option value based on the selection of another?
Paul Phillips
added a comment - Does this also support pre-selecting a config option value based on the selection of another? No, I think we discussed adding that in the future since that's an additional layer of complexity.
Cody Phillips (Inactive)
added a comment - No, I think we discussed adding that in the future since that's an additional layer of complexity. 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."
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.