You don't need to assign "self" values here during this process?

Your "search" should be _get_objectclass_filter(extras=search) (From memory).

PLEASE stop re-making this create_user function there is a create_user helper in accounts.py or user.py somewhere. PLEASE PLEASE read the lib389 source and use it. :(

Use Accounts, not DSLdapObjects. DSLdapObjects should never really be called directly, it's absolutely last resort. Use something already defined. Accounts is good here because it's a subset of UserAccount.

Define these only in the tests where they are used. You never need a constant unless it's really really shared between thigs.

Looking at this ... do you understand how the _gen_filter() function set works? I think that's a critical piece of understanding here you may be missing about the right way to implement a filter here ....

@firstyear changes are done , please check

Your "search" should be _get_objectclass_filter(extras=search) (From memory).

You did not apply this comment - and it's the absolute most critical one.

You're search term should be a subset of the objectClass search term term that is generated by the related gen part. This is probably one of the most intense parts of the lib389, so I really really really want you to read the top of _mapped_object.py, look at the _gen() functions, and then please talk to me about it if you have questions.

Your "search" should be _get_objectclass_filter(extras=search) (From memory).

You did not apply this comment - and it's the absolute most critical one.
You're search term should be a subset of the objectClass search term term that is generated by the related gen part. This is probably one of the most intense parts of the lib389, so I really really really want you to read the top of _mapped_object.py, look at the _gen() functions, and then please talk to me about it if you have questions.

def _get_objectclass_filter(self):
    return _gen_and(
        _gen_filter(_term_gen('objectclass'), self._objectclasses)
    )

How its is going to take _get_objectclass_filter(extras=search)

and again if i create a new function

def _get_objectclass_and_filter(self, search):
    return _gen_or(
        _gen_filter(_term_gen('objectclass'), self._objectclasses, extra=search)
    )

It will yield bad search filter error

If your filter for "search" is:

search = "(mail=*)"

then

search_filter = _gen_and([
    self._get_objectclass_filter(),
    search
])

That will create:

(&(<objectclass filter>)(mail=*))

Which is what you want.

No need to make new functions here.

If you look on line 886, _get_selector_filter, you can see _gen_and used with a list.

If your filter for "search" is:
search = "(mail=*)"

then
search_filter = _gen_and([
self._get_objectclass_filter(),
search
])

That will create:
(&()(mail=*))

Which is what you want.
No need to make new functions here.
If you look on line 886, _get_selector_filter, you can see _gen_and used with a list.

_gen_and([self._get_objectclass_filter(),search])
'(&(|(objectclass=nsAccount)(objectclass=nsPerson)(objectclass=simpleSecurityObject)(objectclass=organization)(objectclass=person)(objectclass=account)(objectclass=organizationalUnit)(objectclass=netscapeServer)(objectclass=domain)(objectclass=posixAccount)(objectclass=shadowAccount)(objectclass=posixGroup)(objectclass=mailRecipient))mail=*)'

which is a bad search filter

Which is your mistake because you are setting the filter to 'mail=' not "(mail=)".

@firstyear all changes are done as per your suggestion

You only use these values once, so they can be inline in the 'filter()' call.

To make this readable, spread it out:

accts = Accounts(...)
r = accts.filter(' ..... ')
assert len(r) == 2

Is this used?

It should match the objects with filter "X ..."

I think this is pretty over complex for a user create when all you need is the normal UserAccounts (plural). create_test_user(), and then to filter on what they make.

@firstyear all changes are done as per your suggestion

TEST_USER_PROPERTIES isn't used now that you did the code clean up :)

After that, I think this is mergeable. Yay!

@firstyear all changes are done as per your suggestion

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

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.