Please add @pytest.mark.bz1589144 and rename the test function to have human readable title.

Please break it into two lines

This step is after step2

You can use UserAccounts DSLdapObject for the user creation. And it's actually recommended over legacy Entry object.
Check this - https://lib389.readthedocs.io/en/latest/user.html

Also, you can use users.create_test_user(uid=1004) for the generic user creation (in case when you don't need specific attributes)

Better to use 'search_s(USER4_DN, ldap.SCOPE_BASE, "(objectclass=*)"' here in stead of legacy getEntry() method. Or you can use UserAccount object and do the bind through it. The link I sent has the example

@spichugi
I have been rewriting the test to use UserAccounts but a user created this way ignores password policy for some reason.

Steps:
1) Set global password policy
2) Add user to instance:
users = UserAccounts(topology_st.standalone, DEFAULT_SUFFIX)
testuser = users.create_test_user(uid=1004)
3) Set password for user: testuser.set('userPassword', USER_PW)
4) Modify passwordWarning to value 86400.
5) You said I should bind through the user (testuser.bind(USER_PW)) but what would be the correct way to check shadowWarning attribute?
Because if I use testuser.present('shadowWarning'), then it won't find anything whether I am bound to the testuser or not and shadowWarning attribute should be generated with these settings.

Could you please point me to the right direction how object UserAccounts works with password policy? Because using legacy Entry object worked correctly.
Also the documentation says that I should consider using nsUserAccounts object instead of UserAccounts.

@spichugi
I have been rewriting the test to use UserAccounts but a user created this way ignores password policy for some reason.
Steps:
1) Set global password policy
2) Add user to instance:
users = UserAccounts(topology_st.standalone, DEFAULT_SUFFIX)
testuser = users.create_test_user(uid=1004)

Okay, I see. You have additional objectClass there - shadowAccount. You can add it to the user.

test_user.add("objectClass", "shadowAccount")

3) Set password for user: testuser.set('userPassword', USER_PW)
4) Modify passwordWarning to value 86400.
5) You said I should bind through the user (testuser.bind(USER_PW)) but what would be the correct way to check shadowWarning attribute?

I didn't say you should bind exactly like this. :)
If you will though, it will work like this:

conn = testuser.bind('password') # It will create a new connection
users = UserAccounts(conn, DEFAULT_SUFFIX)
test_user_bound = users.get(test_user.dn) # test_user is still bound as DM because topology_st.standalone is DM
test_user_bound.present()

Because if I use testuser.present('shadowWarning'), then it won't find anything whether I am bound to the testuser or not and shadowWarning attribute should be generated with these settings.

So I'd say it is okay to bind with topology_st.standalone.simple_bind_s(USER4_DN, USER_PW)
and then you can use testuser.present('shadowWarning')

Also the documentation says that I should consider using nsUserAccounts object instead of UserAccounts.

If your test case will be run only on DS 1.4.0 and above - you should use nsUserAccounts.
Otherwise, I think it is okay to use just UserAccounts.
The methods are the same any way.

And let's put the test case to 'dirsrvtests/tests/suites/password/pwdPolicy_warning_test.py' for example.
We plan to get rid of dirsrvtests/tests/tickets/ soon one day :)

@spichugi
Please review. Thanks!

You only using this value twice, it may be clearer for the reader to just hardcode "shadowWarning" in these two locations (it tripped me up reading it ...)

@firstyear
Thanks, I corrected the value.
I am used to assigning constant/variable if I use the value more than once to have clearer code but it might not be necessary this time.

Ack from me! @spichugi since I've been away for so long can I get you to sanity check this for me too?

LGTM!

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3151

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.