Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check if Subgrid is visible #72

Open
mike9182 opened this issue Apr 16, 2020 · 6 comments
Open

Check if Subgrid is visible #72

mike9182 opened this issue Apr 16, 2020 · 6 comments
Labels
enhancement New feature or request
Milestone

Comments

@mike9182
Copy link
Contributor

Is it possible to check whether a subgrid or section is visible on a form?

I saw the form state command. But, it looks like it only returns attributes.

@mVermaat
Copy link
Owner

Correct, this isn't currently implemented. Marking it as an enhancement,

@mVermaat mVermaat added the enhancement New feature or request label Apr 16, 2020
@mike9182
Copy link
Contributor Author

What would you envision the step looking like for this functionality?

@mVermaat
Copy link
Owner

mVermaat commented Apr 17, 2020

I'm thinking about expanding the 'Assert Form State' step by adding extra functionality to check this. This would make the table look like below:

Definition

Type Property State
attribute, subgrid, tab, section fieldname, gridname. tabname, sectionname required, optional, recommended, locked, unlocked, visible, invisible, not on form

Example

Type Property State
attribute First Name visible, locked
subgrid contractgrid visible
section details invisible

@mike9182
Copy link
Contributor Author

I like the format above. I started implementing this and I noticed the only thing that isn't covered is specifying the tab that sections are in. This is covered by the format below. Specifying the tab and section names as separate columns also lays the ground work for checking field visibility when fields are in multiple tabs/sections.

@Chrome @Firefox @Cleanup
Scenario: Check visibility of tab
When an account named TestAccount is created with the following values
	| Property     | Value                   |
	| Account Name | DynamicHands            |
	| Main Phone   | 0612345678              |
	| Website      | https://dynamichands.nl |
	| Industry     | Consulting              |
Then TestAccount's form has the following form state
	| Type      | Tab     | Property | State   |
	| attribute |         | SIC Code | Visible |
	| tab       | Summary |          | Visible |
@Chrome @Firefox @Cleanup
Scenario: Check visibility of section
When an account named TestAccount is created with the following values
	| Property     | Value                   |
	| Account Name | DynamicHands            |
	| Main Phone   | 0612345678              |
	| Website      | https://dynamichands.nl |
	| Industry     | Consulting              |
Then TestAccount's form has the following form state
	| Type    | Tab     | Section             | Property | State   |
	| section | Summary | ACCOUNT INFORMATION |          | visible |

@RemyDuijkeren
Copy link

I would not use an additional tab and section column. It makes things more complex for someone writing tests for normal cases. Explicit testing on which tab and section exist is more an edge case.

Maby a dot-notion would be better, like tab.fieldname or tab.section.fieldname.

@Chrome @Firefox @Cleanup
Scenario: Check visibility of section
When an account named TestAccount is created with the following values
	| Property     | Value                   |
	| Account Name | DynamicHands            |
	| Main Phone   | 0612345678              |
	| Website      | https://dynamichands.nl |
	| Industry     | Consulting              |
Then TestAccount's form has the following form state
	| Type    | Property                    |  State   |
	| section | Summary.ACCOUNT INFORMATION |  visible |

@mVermaat
Copy link
Owner

I agree with the fact to try to make it as simple as possible. The dot way seems to be kind of simple but maybe not really obvious to non developers. Also you need to be able to deal with names that contain dots. I think using a seperate column would be better, but a little more simplified. Also that column must be optional as it won't be used in >90% of the cases.

Either way I'm still not 100% certain yet. I'm also thinking about seperating it in two different steps. One for the state (visible/locked etc) and one for the structure. That would make it very simple, however it won't allow the test case where you use multiple instances of the same field on the form where one is visible and the other is invisible.

Definition

Type Parent (Optional) Property State
attribute, subgrid, tab, section tabname, sectionname of the parent fieldname, gridname. tabname, sectionname required, optional, recommended, locked, unlocked, visible, invisible, not on form

Simple Example

Type Property State
attribute First Name visible, locked
subgrid contractgrid visible
section details invisible

Advanced Example

Type Parent Property State
attribute First Name visible, locked
subgrid contractgrid visible
section General details invisible

Simple

@Chrome @Firefox @Cleanup
Scenario: Check visibility of section
When an account named TestAccount is created with the following values
	| Property     | Value                   |
	| Account Name | DynamicHands            |
	| Main Phone   | 0612345678              |
	| Website      | https://dynamichands.nl |
	| Industry     | Consulting              |
Then TestAccount's form has the following form state
	| Type    | Property                    |  State   |
	| section | ACCOUNT INFORMATION |  visible |

Advanced

@Chrome @Firefox @Cleanup
Scenario: Check visibility of section
When an account named TestAccount is created with the following values
	| Property     | Value                   |
	| Account Name | DynamicHands            |
	| Main Phone   | 0612345678              |
	| Website      | https://dynamichands.nl |
	| Industry     | Consulting              |
Then TestAccount's form has the following form state
	| Type    | Parent |  Property                    |  State   |
	| section | Summary | ACCOUNT INFORMATION |  visible |

@mVermaat mVermaat added this to the 4.0 milestone Jun 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants