Added CLI test for local and global password policy CLI commands...

With this search, is there a way you could use the DSLdapObjects to achieve this? It'll trigger the _s usage warning.

If this is absolutely required, is it possible to have it use the server_controls and the escapehatch flags?

For my own curiosity, why do do we remap these attribute names to different values?

For my own curiosity, why do do we remap these attribute names to different values?

They are actually the alias names of the attributes in the schema, but the idea was: less to type, slightly easier to read.

Isn't there a .exists you could use instead?

Could reset be a seperate function instead of an argument here? I think that's better design and clearer about when and how reset is applied relative to the check.

What's this for?

What's this for?

This is required for LogCapture, and things like check_output()

Isn't there a .exists you could use instead?

There is not, not for DSLdapObjects, so I added one...

All changes applied, please review...

Weird question but is this function idempotent? IE given a "full policy state", "partial state", or "removed", does it "always succeed"? I think that would be good in the case of a partial error, we can re-run and have it still succeed. This will be important for command line later ....

I think this isn't quite what I had in mind. I was thinking more:

blah = logs.check_output()
logs.reset_output()

I think this isn't quite what I had in mind. I was thinking more:

Well you clearly stated create a new function that does have not that option :-p

blah = logs.check_output()
logs.reset_output()

So "check_output" actually has nothing to do with LogCapture. I thought they were related in regards to the IO.string stuff, but they are not (my bad). So it doesn't make sense to move it to LogCapture.

The most common use case is a one time read of the output, only in special situations do you need to check for multiple values. So I think I will just change the function to accept a list of values to check (and then always clear the buffer). So no new args, and no new functions.

Weird question but is this function idempotent? IE given a "full policy state", "partial state", or "removed", does it "always succeed"? I think that would be good in the case of a partial error, we can re-run and have it still succeed. This will be important for command line later ....

Well it always succeeds assuming everything is already correctly set up. For existing deployments this is not a guarantee. So I will make sure it will work on partial set ups...

@firstyear, okay I rewrote check_output to optionally accept a list or string, and I made the create user/subtree policy & delete local policy functions to be idempotent.

Niiccee! Looks great, ack from me :)

(I will leave you the happy satisfaction of clicking merge though)

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

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.