Angular - Multiselect extensible table

[davidsi02]

feat(extensible-table): Refine selection handling in extensible table

This pull request updates the selection functionality within the extensible table component for improved clarity and consistency.

Key changes:

• HTML Template:

  • Modified the header template for the selection column to only display the "select all" checkbox when the _selectionType is not 'single'.
  • Updated the cell template to conditionally render either a radio button (when _selectionType is 'single') or a checkbox (for other selection types`).

• TypeScript Logic:

  • Added the component logic necessary for this update,, based on ngx-table component features.

These adjustments enhance the user interface by clearly presenting the appropriate selection controls based on the configured selectionType.

Checklist:

• [x] I fully tested it as developer / designer and created unit / integration tests
• [ ] I documented it (or no need to document or I will create a separate documentation issue)

How to test it?

1. Navigate to a page utilizing the ExtensibleTableComponent.
2. Verify that when the selectable input is true:
   • If selectionType is set to 'single', only radio buttons appear in the selection column, and the header does not display a "select all" checkbox.
   • If selectionType is set to any other value (e.g., 'multiClick', the default), checkboxes appear in the selection column, and the header displays a "select all" checkbox.
3. Ensure that the selection functionality (single or multiple) works as expected in both scenarios.

[davidsi02]

Upon approval, is there any indication of the version in which this feature may be integrated? Thank you.

[erdemcaygor]

The dev branch now points to version 9.3, and the 9.3-preview milestone has been added to the PR

[davidsi02]

The dev branch now points to version 9.3, and the 9.3-preview milestone has been added to the PR

Can you give me some more information on how PR works for this repo? Should I target always the dev branch or is there any guidelines we should follow?

[erdemcaygor]

Our Git versioning strategy is structured so that each release version has its own dedicated branch. Any changes or fixes targeting a specific version are merged into that version's branch. For example, if version 9.2 is the latest release, changes intended for that version are merged into the 9.2 branch. Meanwhile, ongoing development for the next version continues on the dev branch, which might point to 9.3-preview.

[davidsi02]

So If I wanted a feature to be released in a specific version already with its own branch I should target that version branch with my PR or is restricted to dev? Thanks for the support and guidance.

[erdemcaygor]

Yes, it is possible to open a PR to a branch other than dev. However, as a general policy, we avoid making changes to previous release branches unless they address critical issues. Therefore, we recommend targeting either the dev branch or the current release branch 9.2. PRs targeting branches older than the current release are unlikely to be accepted unless they resolve a critical bug.

[davidsi02]

Ok. So as this feature had some urgency for us in this situation the best approach was to target the 9.2 version branch since it's the current in-development phase and is fully compatible. My bad 😅

[davidsi02]

Hello. Does this still requires any action from me? Thanks. @erdemcaygor @sumeyyeKurtulus

[sumeyyeKurtulus]

Hello @davidsi02,

Thank you for your contribution! I have reviewed your PR, and aside from a few design-related concerns, everything looks good and it is mergeable. I will coordinate with the design team and follow up with you shortly.

Thanks again for your collaboration!