@firstyear , this one is also ready to review .

typo in function name

Another typo in function name - in fact all the function names have typos

indentation looks off of above aci string

Besides those minor issues this looks okay to me.

@mreynolds all changes are done as per your suggestion

The same here.
Please, run pytest-pylint using the suggestion from https://pagure.io/389-ds-base/pull-request/50180#comment-75994

"his membership"

Don't use gendered language. It's "their membership".

As before: don't have the "useraccount(conn, ....)" in the .raises clause.

Worse, you even copy paste the line to the line below, and do it again.

ua = UserAccount(conn, ...)
with pytest.raises:
    ua.replace(...)
assert ua.get_attr_val_utf8() == '...'

I have made this comment before in multiple cases now, please please please please improve this.

Why is it undefined?

This is not coherent

This says there is a not(undef(attr) OR false attr), where is the OR in the aci?

You need to describe the structure of the objects and how this works.

I didn't make it to the end of the file to review. I think you need to work on commenting for clarity and explanation, and re-view all my past comments on what you are doing code wise.

I don't know why you keep doing this. Use userAccountS (note the S on the end). Then you can do:

uas = UserAccounts(topo.standalone, basedn) # Here basedn would be ou=nestedgroup,DEFAULT_SUFFIX
for i in [list ...]: 
    uas.create(properties={
    ....
})

Much cleaner.

I also have no idea what this group stuff is you are doing, but it looks like you could do:

grp = UniqueGroup(...)
uas = UserAccounts(topo.standalone, basedn) # Here basedn would be ou=nestedgroup,DEFAULT_SUFFIX
for i in [list ...]: 
    user = uas.create(properties={
    ....
    })
    grp.add_member(user.dn)

Most of lib389 is designed so you never need to add or think about ldap stuff, or handle it too manually. Mainly because everything about LDAP is an un-usable confusing nightmare disaster show.

So if you find yourself in this pattern with lots of dns, and using attributes manually, it probably is an indicator that you are missing some of the nice functions of lib389.

Don't use UserAccount when it's not user accounts. At least use "DSLdapObject", OR in this case, you could use delete_branch_s, but it's wildly dangerous and violates my "no _s function rule".

Leftover debugging stuff?

See comments above.

I don't know why you keep doing this. Use userAccountS (note the S on the end). Then you can do:
uas = UserAccounts(topo.standalone, basedn) # Here basedn would be ou=nestedgroup,DEFAULT_SUFFIX
for i in [list ...]:
uas.create(properties={
....
})

Much cleaner.
I also have no idea what this group stuff is you are doing, but it looks like you could do:
grp = UniqueGroup(...)
uas = UserAccounts(topo.standalone, basedn) # Here basedn would be ou=nestedgroup,DEFAULT_SUFFIX
for i in [list ...]:
user = uas.create(properties={
....
})
grp.add_member(user.dn)

Most of lib389 is designed so you never need to add or think about ldap stuff, or handle it too manually. Mainly because everything about LDAP is an un-usable confusing nightmare disaster show.
So if you find yourself in this pattern with lots of dns, and using attributes manually, it probably is an indicator that you are missing some of the nice functions of lib389.

User part has been corrected, but group part !! You cant create group entry with UserAccounts.

*** ldap.UNWILLING_TO_PERFORM: Attribute uid must not be None

Groups does not have 'uid', 'cn', 'sn' , uidNumber, gidNumber, homeDirectory which is required by UserAccounts

Seriously ... please stop. Think about the problem you just had, and why it happened. I've been trying for weeks, literally weeks that types in lib389 are typed, and won't create things that don't match. If you have something that isn't a UserAccount ... like a Group, and you try to make it of course it will fail. Please please please stop and think about the types and the exception you ahve here.

I'll check this in a few days, I'm a bit unwell at the moment and can't do this right now.

I'll check monday if that's okay.

@firstyear , changes are done , please check

I'll check this tomorrow, I'm writing some tests today sorry.

I reckon there are still issues here, and it's ineffecient, but I can't see them, it's too long, so merge and I'll just fix it later.

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/3227

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.