path: root/python-edc-auth.spec

%global _empty_manifest_terminate_build 0
Name:		python-edc-auth
Version:	0.3.60
Release:	1
Summary:	Authentication for clinicedc/edc projects
License:	GPL license, see LICENSE
URL:		https://github.com/clinicedc/edc-auth
Source0:	https://mirrors.aliyun.com/pypi/web/packages/df/5a/6c4c73b8f378b82d5ae1d050ec23c65b63892e7ffe70d0b01350d0b16aeb/edc-auth-0.3.60.tar.gz
BuildArch:	noarch

Requires:	python3-mempass

%description
Authentication and permissions for the Edc
Default Groups
++++++++++++++
The default groups are required for the normal operation of an EDC deployment. The default groups are:
* ``ACCOUNT_MANAGER``: members may add/change and delete user accounts
* ``ADMINISTRATION``: members may view the Administration page
* ``AUDITOR``: members may view all forms but have no add/change permissions.
* ``CLINIC``: members may add/edit/delete all CRFs, Requisitions, Actions and other required clinic trial data entry forms. They may also view the Requisition page of the Lab section;
* ``EVERYONE``: members may access the EDC;
* ``LAB``: members may perform all functions in the Lab section (Edit requisitions, receive, process, pack, manage manifests, etc);
* ``PHARMACY``:
* ``PII``: members may view all personally identifiable data and edit forms that manage such data (Screening, Consents, Patient registration);
* ``PII_VIEW``: members may view personally identifiable data but have no add/edit permissions for any of the forms that store such data.
Permissions
+++++++++++
Permissions use Django's permission framework,  therefore, all permissions are linked to some model.
Permissions don't always naturally link to a model. In such cases, a dummy model is created.
For example, with Navigation bars from `edc_navbar`. Permissions to follow an item on a
navigation bar are associated with model `edc_navbar.Navbar`. A similar approach is used for
`listboard` permissions using `edc_dashboard.Dashboard`.
Extending permissions with `site_auths` global
++++++++++++++++++++++++++++++++++++++++++++++
A module can add new or update existing groups and roles and even add custom codenames.
The ``site_auths`` global ``autodiscovers`` configurations from ``auths.py`` in the root of your module.
The ``site_auths`` global gathers but does not validate or change any data in django's
``group``/``permission`` models or the Edc's ``role`` model.
The ``site_auths`` global gathers data:
* to ADD new groups,
* to update codenames for an existing group,
* to add a new role
* to update the group list for an existing role
* to add to the list of PII models
* to specifiy custom functions to run before and after groups and roles have been updated
For example,
    # auths.py
    from edc_auth.auth_objects import CLINICIAN_ROLE, STATISTICIAN_ROLE
    from edc_auth.site_auths import site_auths
    from edc_protocol_violation.auth_objects import (
        PROTOCOL_VIOLATION,
        PROTOCOL_VIOLATION_VIEW,
        protocol_violation_codenames,
        protocol_violation_view_codenames,
    )
    # add a new group specific to models in this module
    site_auths.add_group(*protocol_violation_codenames, name=PROTOCOL_VIOLATION)
    # add a new group specific to models in this module
    site_auths.add_group(*protocol_violation_view_codenames, name=PROTOCOL_VIOLATION_VIEW)
    # update the existing role CLINICIAN_ROLE to add the group PROTOCOL_VIOLATION
    site_auths.update_role(PROTOCOL_VIOLATION, name=CLINICIAN_ROLE)
    # update the existing role STATISTICIAN_ROLE to add the group PROTOCOL_VIOLATION_VIEW
    site_auths.update_role(PROTOCOL_VIOLATION_VIEW, name=STATISTICIAN_ROLE)
As a convention, we define group names, lists of codenames and custom functions ``auth_objects.py``.
In the above example, the ``auth_objects.py`` looks like this:
    # auth_objects.py
    # declare group names
    PROTOCOL_VIOLATION = "PROTOCOL_VIOLATION"
    PROTOCOL_VIOLATION_VIEW = "PROTOCOL_VIOLATION_VIEW"
    # add/change/delete/view codenames
    protocol_violation_codenames = (
        "edc_protocol_violation.add_protocoldeviationviolation",
        "edc_protocol_violation.change_protocoldeviationviolation",
        "edc_protocol_violation.delete_protocoldeviationviolation",
        "edc_protocol_violation.view_protocoldeviationviolation",
    )
    # view only codename
    protocol_violation_view_codenames = (
        "edc_protocol_violation.view_protocoldeviationviolation",
    )
AuthUpdater
+++++++++++
The ``AuthUpdater`` class runs in a post_migrate signal declared in ``apps.py``.
The ``AuthUpdater`` reads and validates the data gathered by ``site_auths``. Once all
validation checks pass, the ``AuthUpdater`` updates Django's ``group`` and ``permission``
models as well as the Edc's ``Role`` model.
Validation checks include confirming models refered to in codenames exist. This means that
the app where models are declared must be in your ``INSTALLED_APPS``.
During tests having all codenames load may not be ideal. See below on some strategies for testing.
Testing SiteAuths, AuthUpdater
++++++++++++++++++++++++++++++
An app sets up its own groups and roles using the ``site_auths`` global in ``auths.py``. To test just your apps
configuration, you can prevent ``site_auths`` from autodiscovering other modules by setting::
    EDC_AUTH_SKIP_SITE_AUTHS=True
You can prevent the ``AuthUpdater`` from updating groups and permissions by setting::
    EDC_AUTH_SKIP_AUTH_UPDATER=True
You can then override these attributes in your tests
    @override_settings(
        EDC_AUTH_SKIP_SITE_AUTHS=True,
        EDC_AUTH_SKIP_AUTH_UPDATER=False
    )
    class TestMyTests(TestCase):
Above the ``site_auths`` global ``autodiscover`` is still disabled but the ``AuthUpdater`` is not.
In your test setup you can update ``site_auths`` manually so that your tests focus on the
add/update or groups/roles/codenames/tuples relevant to your app.
You can emulate ``autodiscover`` behaviour by explicitly importing ``auths`` modules needed for your tests.
For example:
    from importlib import import_module
    from django.test import TestCase, override_settings
    from edc_auth.auth_updater import AuthUpdater
    class TestAuths(TestCase):
        @override_settings(
            EDC_AUTH_SKIP_SITE_AUTHS=True,
            EDC_AUTH_SKIP_AUTH_UPDATER=True,
        )
        def test_load(self):
            import_module(f"edc_dashboard.auths")
            import_module(f"edc_navbar.auths")
            AuthUpdater(verbose=True)
You can ``clear`` the ``site_auths`` registry and add back specific items need for your tests.
For example:
    # taken from edc-dashboard
    @override_settings(EDC_AUTH_SKIP_SITE_AUTHS=True, EDC_AUTH_SKIP_AUTH_UPDATER=False)
    class TestMyTests(TestCase):
        def setUpTestData(cls):
            site_auths.clear()
            site_auths.add_group("edc_dashboard.view_my_listboard", name=CLINIC)
            site_auths.add_custom_permissions_tuples(
                model="edc_dashboard.edcpermissions",
                codename_tuples=(("edc_dashboard.view_my_listboard", "View my listboard"),),
            )
            AuthUpdater(verbose=False, warn_only=True)
            return super().setUpTestData()
        def test_me(self):
Importing users
+++++++++++++++
You create user accounts by importing a specially formatted CSV file. Once an account is created a "Welcome" email may be sent.
Import users from a CSV file with columns:
    username
    is_staff
    is_active
    first_name
    last_name
    job_title
    email
    mobile
    alternate_email
    site_names: a comma-separated list of sites
    role_names: a comma-separated list of roles
Then import the users from your application commandline
    python manage.py import_users --csvfile=/Users/erikvw/meta_users.csv --notify-to-test-email=ew2789@gmail --resource-name=meta.clinicedc.org --resend-as-new
Legacy notes
++++++++++++
**Important:** If you are upgrading from edc_base.auth:
The ``userprofile`` table is now in ``edc_auth``. ``edc_auth`` has one migration for this table.
Copy the same table from ``edc_base`` and fake the ``edc_auth`` migration.
	CREATE TABLE edc_auth_userprofile LIKE edc_base_userprofile;
	INSERT edc_auth_userprofile SELECT * FROM edc_base_userprofile;
	python manage.py migrate edc_auth --fake
You can now run the ``edc_base`` migration safely.

%package -n python3-edc-auth
Summary:	Authentication for clinicedc/edc projects
Provides:	python-edc-auth
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
%description -n python3-edc-auth
Authentication and permissions for the Edc
Default Groups
++++++++++++++
The default groups are required for the normal operation of an EDC deployment. The default groups are:
* ``ACCOUNT_MANAGER``: members may add/change and delete user accounts
* ``ADMINISTRATION``: members may view the Administration page
* ``AUDITOR``: members may view all forms but have no add/change permissions.
* ``CLINIC``: members may add/edit/delete all CRFs, Requisitions, Actions and other required clinic trial data entry forms. They may also view the Requisition page of the Lab section;
* ``EVERYONE``: members may access the EDC;
* ``LAB``: members may perform all functions in the Lab section (Edit requisitions, receive, process, pack, manage manifests, etc);
* ``PHARMACY``:
* ``PII``: members may view all personally identifiable data and edit forms that manage such data (Screening, Consents, Patient registration);
* ``PII_VIEW``: members may view personally identifiable data but have no add/edit permissions for any of the forms that store such data.
Permissions
+++++++++++
Permissions use Django's permission framework,  therefore, all permissions are linked to some model.
Permissions don't always naturally link to a model. In such cases, a dummy model is created.
For example, with Navigation bars from `edc_navbar`. Permissions to follow an item on a
navigation bar are associated with model `edc_navbar.Navbar`. A similar approach is used for
`listboard` permissions using `edc_dashboard.Dashboard`.
Extending permissions with `site_auths` global
++++++++++++++++++++++++++++++++++++++++++++++
A module can add new or update existing groups and roles and even add custom codenames.
The ``site_auths`` global ``autodiscovers`` configurations from ``auths.py`` in the root of your module.
The ``site_auths`` global gathers but does not validate or change any data in django's
``group``/``permission`` models or the Edc's ``role`` model.
The ``site_auths`` global gathers data:
* to ADD new groups,
* to update codenames for an existing group,
* to add a new role
* to update the group list for an existing role
* to add to the list of PII models
* to specifiy custom functions to run before and after groups and roles have been updated
For example,
    # auths.py
    from edc_auth.auth_objects import CLINICIAN_ROLE, STATISTICIAN_ROLE
    from edc_auth.site_auths import site_auths
    from edc_protocol_violation.auth_objects import (
        PROTOCOL_VIOLATION,
        PROTOCOL_VIOLATION_VIEW,
        protocol_violation_codenames,
        protocol_violation_view_codenames,
    )
    # add a new group specific to models in this module
    site_auths.add_group(*protocol_violation_codenames, name=PROTOCOL_VIOLATION)
    # add a new group specific to models in this module
    site_auths.add_group(*protocol_violation_view_codenames, name=PROTOCOL_VIOLATION_VIEW)
    # update the existing role CLINICIAN_ROLE to add the group PROTOCOL_VIOLATION
    site_auths.update_role(PROTOCOL_VIOLATION, name=CLINICIAN_ROLE)
    # update the existing role STATISTICIAN_ROLE to add the group PROTOCOL_VIOLATION_VIEW
    site_auths.update_role(PROTOCOL_VIOLATION_VIEW, name=STATISTICIAN_ROLE)
As a convention, we define group names, lists of codenames and custom functions ``auth_objects.py``.
In the above example, the ``auth_objects.py`` looks like this:
    # auth_objects.py
    # declare group names
    PROTOCOL_VIOLATION = "PROTOCOL_VIOLATION"
    PROTOCOL_VIOLATION_VIEW = "PROTOCOL_VIOLATION_VIEW"
    # add/change/delete/view codenames
    protocol_violation_codenames = (
        "edc_protocol_violation.add_protocoldeviationviolation",
        "edc_protocol_violation.change_protocoldeviationviolation",
        "edc_protocol_violation.delete_protocoldeviationviolation",
        "edc_protocol_violation.view_protocoldeviationviolation",
    )
    # view only codename
    protocol_violation_view_codenames = (
        "edc_protocol_violation.view_protocoldeviationviolation",
    )
AuthUpdater
+++++++++++
The ``AuthUpdater`` class runs in a post_migrate signal declared in ``apps.py``.
The ``AuthUpdater`` reads and validates the data gathered by ``site_auths``. Once all
validation checks pass, the ``AuthUpdater`` updates Django's ``group`` and ``permission``
models as well as the Edc's ``Role`` model.
Validation checks include confirming models refered to in codenames exist. This means that
the app where models are declared must be in your ``INSTALLED_APPS``.
During tests having all codenames load may not be ideal. See below on some strategies for testing.
Testing SiteAuths, AuthUpdater
++++++++++++++++++++++++++++++
An app sets up its own groups and roles using the ``site_auths`` global in ``auths.py``. To test just your apps
configuration, you can prevent ``site_auths`` from autodiscovering other modules by setting::
    EDC_AUTH_SKIP_SITE_AUTHS=True
You can prevent the ``AuthUpdater`` from updating groups and permissions by setting::
    EDC_AUTH_SKIP_AUTH_UPDATER=True
You can then override these attributes in your tests
    @override_settings(
        EDC_AUTH_SKIP_SITE_AUTHS=True,
        EDC_AUTH_SKIP_AUTH_UPDATER=False
    )
    class TestMyTests(TestCase):
Above the ``site_auths`` global ``autodiscover`` is still disabled but the ``AuthUpdater`` is not.
In your test setup you can update ``site_auths`` manually so that your tests focus on the
add/update or groups/roles/codenames/tuples relevant to your app.
You can emulate ``autodiscover`` behaviour by explicitly importing ``auths`` modules needed for your tests.
For example:
    from importlib import import_module
    from django.test import TestCase, override_settings
    from edc_auth.auth_updater import AuthUpdater
    class TestAuths(TestCase):
        @override_settings(
            EDC_AUTH_SKIP_SITE_AUTHS=True,
            EDC_AUTH_SKIP_AUTH_UPDATER=True,
        )
        def test_load(self):
            import_module(f"edc_dashboard.auths")
            import_module(f"edc_navbar.auths")
            AuthUpdater(verbose=True)
You can ``clear`` the ``site_auths`` registry and add back specific items need for your tests.
For example:
    # taken from edc-dashboard
    @override_settings(EDC_AUTH_SKIP_SITE_AUTHS=True, EDC_AUTH_SKIP_AUTH_UPDATER=False)
    class TestMyTests(TestCase):
        def setUpTestData(cls):
            site_auths.clear()
            site_auths.add_group("edc_dashboard.view_my_listboard", name=CLINIC)
            site_auths.add_custom_permissions_tuples(
                model="edc_dashboard.edcpermissions",
                codename_tuples=(("edc_dashboard.view_my_listboard", "View my listboard"),),
            )
            AuthUpdater(verbose=False, warn_only=True)
            return super().setUpTestData()
        def test_me(self):
Importing users
+++++++++++++++
You create user accounts by importing a specially formatted CSV file. Once an account is created a "Welcome" email may be sent.
Import users from a CSV file with columns:
    username
    is_staff
    is_active
    first_name
    last_name
    job_title
    email
    mobile
    alternate_email
    site_names: a comma-separated list of sites
    role_names: a comma-separated list of roles
Then import the users from your application commandline
    python manage.py import_users --csvfile=/Users/erikvw/meta_users.csv --notify-to-test-email=ew2789@gmail --resource-name=meta.clinicedc.org --resend-as-new
Legacy notes
++++++++++++
**Important:** If you are upgrading from edc_base.auth:
The ``userprofile`` table is now in ``edc_auth``. ``edc_auth`` has one migration for this table.
Copy the same table from ``edc_base`` and fake the ``edc_auth`` migration.
	CREATE TABLE edc_auth_userprofile LIKE edc_base_userprofile;
	INSERT edc_auth_userprofile SELECT * FROM edc_base_userprofile;
	python manage.py migrate edc_auth --fake
You can now run the ``edc_base`` migration safely.

%package help
Summary:	Development documents and examples for edc-auth
Provides:	python3-edc-auth-doc
%description help
Authentication and permissions for the Edc
Default Groups
++++++++++++++
The default groups are required for the normal operation of an EDC deployment. The default groups are:
* ``ACCOUNT_MANAGER``: members may add/change and delete user accounts
* ``ADMINISTRATION``: members may view the Administration page
* ``AUDITOR``: members may view all forms but have no add/change permissions.
* ``CLINIC``: members may add/edit/delete all CRFs, Requisitions, Actions and other required clinic trial data entry forms. They may also view the Requisition page of the Lab section;
* ``EVERYONE``: members may access the EDC;
* ``LAB``: members may perform all functions in the Lab section (Edit requisitions, receive, process, pack, manage manifests, etc);
* ``PHARMACY``:
* ``PII``: members may view all personally identifiable data and edit forms that manage such data (Screening, Consents, Patient registration);
* ``PII_VIEW``: members may view personally identifiable data but have no add/edit permissions for any of the forms that store such data.
Permissions
+++++++++++
Permissions use Django's permission framework,  therefore, all permissions are linked to some model.
Permissions don't always naturally link to a model. In such cases, a dummy model is created.
For example, with Navigation bars from `edc_navbar`. Permissions to follow an item on a
navigation bar are associated with model `edc_navbar.Navbar`. A similar approach is used for
`listboard` permissions using `edc_dashboard.Dashboard`.
Extending permissions with `site_auths` global
++++++++++++++++++++++++++++++++++++++++++++++
A module can add new or update existing groups and roles and even add custom codenames.
The ``site_auths`` global ``autodiscovers`` configurations from ``auths.py`` in the root of your module.
The ``site_auths`` global gathers but does not validate or change any data in django's
``group``/``permission`` models or the Edc's ``role`` model.
The ``site_auths`` global gathers data:
* to ADD new groups,
* to update codenames for an existing group,
* to add a new role
* to update the group list for an existing role
* to add to the list of PII models
* to specifiy custom functions to run before and after groups and roles have been updated
For example,
    # auths.py
    from edc_auth.auth_objects import CLINICIAN_ROLE, STATISTICIAN_ROLE
    from edc_auth.site_auths import site_auths
    from edc_protocol_violation.auth_objects import (
        PROTOCOL_VIOLATION,
        PROTOCOL_VIOLATION_VIEW,
        protocol_violation_codenames,
        protocol_violation_view_codenames,
    )
    # add a new group specific to models in this module
    site_auths.add_group(*protocol_violation_codenames, name=PROTOCOL_VIOLATION)
    # add a new group specific to models in this module
    site_auths.add_group(*protocol_violation_view_codenames, name=PROTOCOL_VIOLATION_VIEW)
    # update the existing role CLINICIAN_ROLE to add the group PROTOCOL_VIOLATION
    site_auths.update_role(PROTOCOL_VIOLATION, name=CLINICIAN_ROLE)
    # update the existing role STATISTICIAN_ROLE to add the group PROTOCOL_VIOLATION_VIEW
    site_auths.update_role(PROTOCOL_VIOLATION_VIEW, name=STATISTICIAN_ROLE)
As a convention, we define group names, lists of codenames and custom functions ``auth_objects.py``.
In the above example, the ``auth_objects.py`` looks like this:
    # auth_objects.py
    # declare group names
    PROTOCOL_VIOLATION = "PROTOCOL_VIOLATION"
    PROTOCOL_VIOLATION_VIEW = "PROTOCOL_VIOLATION_VIEW"
    # add/change/delete/view codenames
    protocol_violation_codenames = (
        "edc_protocol_violation.add_protocoldeviationviolation",
        "edc_protocol_violation.change_protocoldeviationviolation",
        "edc_protocol_violation.delete_protocoldeviationviolation",
        "edc_protocol_violation.view_protocoldeviationviolation",
    )
    # view only codename
    protocol_violation_view_codenames = (
        "edc_protocol_violation.view_protocoldeviationviolation",
    )
AuthUpdater
+++++++++++
The ``AuthUpdater`` class runs in a post_migrate signal declared in ``apps.py``.
The ``AuthUpdater`` reads and validates the data gathered by ``site_auths``. Once all
validation checks pass, the ``AuthUpdater`` updates Django's ``group`` and ``permission``
models as well as the Edc's ``Role`` model.
Validation checks include confirming models refered to in codenames exist. This means that
the app where models are declared must be in your ``INSTALLED_APPS``.
During tests having all codenames load may not be ideal. See below on some strategies for testing.
Testing SiteAuths, AuthUpdater
++++++++++++++++++++++++++++++
An app sets up its own groups and roles using the ``site_auths`` global in ``auths.py``. To test just your apps
configuration, you can prevent ``site_auths`` from autodiscovering other modules by setting::
    EDC_AUTH_SKIP_SITE_AUTHS=True
You can prevent the ``AuthUpdater`` from updating groups and permissions by setting::
    EDC_AUTH_SKIP_AUTH_UPDATER=True
You can then override these attributes in your tests
    @override_settings(
        EDC_AUTH_SKIP_SITE_AUTHS=True,
        EDC_AUTH_SKIP_AUTH_UPDATER=False
    )
    class TestMyTests(TestCase):
Above the ``site_auths`` global ``autodiscover`` is still disabled but the ``AuthUpdater`` is not.
In your test setup you can update ``site_auths`` manually so that your tests focus on the
add/update or groups/roles/codenames/tuples relevant to your app.
You can emulate ``autodiscover`` behaviour by explicitly importing ``auths`` modules needed for your tests.
For example:
    from importlib import import_module
    from django.test import TestCase, override_settings
    from edc_auth.auth_updater import AuthUpdater
    class TestAuths(TestCase):
        @override_settings(
            EDC_AUTH_SKIP_SITE_AUTHS=True,
            EDC_AUTH_SKIP_AUTH_UPDATER=True,
        )
        def test_load(self):
            import_module(f"edc_dashboard.auths")
            import_module(f"edc_navbar.auths")
            AuthUpdater(verbose=True)
You can ``clear`` the ``site_auths`` registry and add back specific items need for your tests.
For example:
    # taken from edc-dashboard
    @override_settings(EDC_AUTH_SKIP_SITE_AUTHS=True, EDC_AUTH_SKIP_AUTH_UPDATER=False)
    class TestMyTests(TestCase):
        def setUpTestData(cls):
            site_auths.clear()
            site_auths.add_group("edc_dashboard.view_my_listboard", name=CLINIC)
            site_auths.add_custom_permissions_tuples(
                model="edc_dashboard.edcpermissions",
                codename_tuples=(("edc_dashboard.view_my_listboard", "View my listboard"),),
            )
            AuthUpdater(verbose=False, warn_only=True)
            return super().setUpTestData()
        def test_me(self):
Importing users
+++++++++++++++
You create user accounts by importing a specially formatted CSV file. Once an account is created a "Welcome" email may be sent.
Import users from a CSV file with columns:
    username
    is_staff
    is_active
    first_name
    last_name
    job_title
    email
    mobile
    alternate_email
    site_names: a comma-separated list of sites
    role_names: a comma-separated list of roles
Then import the users from your application commandline
    python manage.py import_users --csvfile=/Users/erikvw/meta_users.csv --notify-to-test-email=ew2789@gmail --resource-name=meta.clinicedc.org --resend-as-new
Legacy notes
++++++++++++
**Important:** If you are upgrading from edc_base.auth:
The ``userprofile`` table is now in ``edc_auth``. ``edc_auth`` has one migration for this table.
Copy the same table from ``edc_base`` and fake the ``edc_auth`` migration.
	CREATE TABLE edc_auth_userprofile LIKE edc_base_userprofile;
	INSERT edc_auth_userprofile SELECT * FROM edc_base_userprofile;
	python manage.py migrate edc_auth --fake
You can now run the ``edc_base`` migration safely.

%prep
%autosetup -n edc-auth-0.3.60

%build
%py3_build

%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
	find usr/lib -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
	find usr/lib64 -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
	find usr/bin -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
	find usr/sbin -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
	find usr/share/man -type f -printf "\"/%h/%f.gz\"\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .

%files -n python3-edc-auth -f filelist.lst
%dir %{python3_sitelib}/*

%files help -f doclist.lst
%{_docdir}/*

%changelog
* Thu Jun 08 2023 Python_Bot <Python_Bot@openeuler.org> - 0.3.60-1
- Package Spec generated