actions on child/related views (multiple childs exist) not working properly

[schrecksim]

Environment

Flask-Appbuilder version: 4.3.9

pip freeze output:

• aiohttp==3.8.4
• aiosignal==1.3.1
• alembic==1.11.1
• apispec==6.3.0
• async-timeout==4.0.2
• attrs==23.1.0
• Babel==2.12.1
• black==23.3.0
• blinker==1.6.2
• boto3==1.28.83
• boto3-stubs==1.26.151
• botocore==1.31.83
• botocore-stubs==1.29.151
• certifi==2023.5.7
• cffi==1.15.1
• charset-normalizer==3.1.0
• click==8.1.3
• colorama==0.4.6
• coverage==7.2.7
• cryptography==41.0.1
• Deprecated==1.2.14
• dnspython==2.3.0
• docker==6.1.3
• email-validator==1.3.1
• exceptiongroup==1.1.1
• flake8==6.0.0
• Flask==2.3.2
• Flask-AppBuilder==4.3.9
• Flask-Babel==2.0.0
• Flask-JWT-Extended==4.5.2
• Flask-Limiter==3.3.1
• Flask-Login==0.6.2
• Flask-Migrate==4.0.4
• Flask-SQLAlchemy==2.5.1
• Flask-WTF==1.1.1
• freezegun==1.2.2
• frozenlist==1.3.3
• ghp-import==2.1.0
• greenlet==2.0.2
• griffe==0.29.0
• idna==3.4
• importlib-resources==5.12.0
• iniconfig==2.0.0
• invoke==2.2.0
• isort==5.12.0
• itsdangerous==2.1.2
• Jinja2==3.1.2
• jmespath==1.0.1
• jsonschema==4.17.3
• limits==3.5.0
• Mako==1.2.4
• Markdown==3.3.7
• markdown-it-py==2.2.0
• MarkupSafe==2.1.3
• marshmallow==3.19.0
• marshmallow-sqlalchemy==0.26.1
• mccabe==0.7.0
• mdurl==0.1.2
• mergedeep==1.3.4
• mike==1.1.2
• mkdocs==1.4.3
• mkdocs-autorefs==0.4.1
• mkdocs-gen-files==0.5.0
• mkdocs-literate-nav==0.6.0
• mkdocs-material==9.1.15
• mkdocs-material-extensions==1.1.1
• mkdocs-section-index==0.3.5
• mkdocstrings==0.22.0
• mkdocstrings-python==0.10.1
• moto==4.1.11
• multidict==6.0.4
• mypy==1.3.0
• mypy-boto3-cloudformation==1.26.149
• mypy-boto3-dynamodb==1.26.115
• mypy-boto3-ec2==1.26.147
• mypy-boto3-lambda==1.26.147
• mypy-boto3-rds==1.26.144
• mypy-boto3-s3==1.26.127
• mypy-boto3-sqs==1.26.148
• mypy-boto3-ssm==1.26.97
• mypy-boto3-stepfunctions==1.26.21
• mypy-boto3-sts==1.26.136
• mypy-extensions==1.0.0
• ordered-set==4.1.0
• packaging==23.1
• pathspec==0.11.1
• platformdirs==3.5.3
• pluggy==1.0.0
• prison==0.2.1
• psycopg2-binary==2.9.9
• pycodestyle==2.10.0
• pycparser==2.21
• pydantic==1.10.9
• pyflakes==3.0.1
• Pygments==2.15.1
• PyJWT==2.7.0
• pymdown-extensions==9.11
• pyrsistent==0.19.3
• pytest==7.3.2
• pytest-cov==4.1.0
• python-dateutil==2.8.2
• python-dotenv==0.21.1
• pytz==2022.7.1
• PyYAML==6.0
• pyyaml_env_tag==0.1
• regex==2023.6.3
• requests==2.31.0
• responses==0.23.1
• rich==13.4.1
• s3transfer==0.7.0
• six==1.16.0
• SQLAlchemy==1.4.48
• SQLAlchemy-Utils==0.41.1
• tomli==2.0.1
• types-awscrt==0.16.19
• types-PyYAML==6.0.12.10
• types-s3transfer==0.6.1
• typing_extensions==4.6.3
• urllib3==1.26.16
• verspec==0.1.0
• watchdog==3.0.0
• websocket-client==1.5.3
• Werkzeug==2.3.6
• wrapt==1.15.0
• WTForms==3.0.1
• xmltodict==0.13.0
• yarl==1.9.2

Describe the expected results

Actions on child list views should be handled correctly, when all records are selected, and only update its records. In addition, it should not only work on the first child view hats displayed but also the second and so on.

@action('set_ready', 'status ready', single=False)
    def set_ready(self, items):
        """
        set selected records status to 'ready'
        """
        for item in items:
            try:
                item.status = 'ready'
                self.datamodel.edit(item)
                self.update_redirect()
            except:
                pass
        return redirect(self.get_redirect())

The try addition in the code fixes the problem that if I'm selecting all records on the first related view, the records on the second view get selected as well. This causes an error in the application.

Describe the actual results

The records of the first related view get updated as expected when selecting all records. If I'm selecting all records of the second child and execute the action, the records of the first child get updated, but the ones of the second don't change.

Steps to reproduce

1. Have a main view, with several child views
2. select all records with the check bock on top
3. execute the action to modify those records

[ThomasP0815]

I think this problem is related to issue #1302

[schrecksim]

Thanks, I'll take a look on the possible solution provided and keep you up to date.