Added support to collection for named urls

[john-westcott-iv]

SUMMARY

With this change awx.awx colleciton modules can used named URLs. For example:

---
- name: Test a named URL
  hosts: localhost
  connection: local
  gather_facts: False
  tasks:
    - name: Create a job template
      awx.awx.job_template:
        name: named_url_test
        job_type: "run"
        inventory: "Demo Inventory++Default"
        project: "Demo Project++Default"
        playbook: "hello_world.yml"
        credentials:
          - "Demo Credential++Machine+ssh++"
        state: "present"

ISSUE TYPE

• New or Enhanced Feature

COMPONENT NAME

• Collection

AWX VERSION

ADDITIONAL INFORMATION

[AlanCoding]

Organizations are vanilla name-unique. So you would have to do organization: Default++? I don't know if this is useful or intended...

[sean-m-sullivan]

Vanilla names should still work, What I've been trying to do is make it so it takes the output of export out of the box, and using that as the metric, if we could an output for export to put out the named urls... well that would be /chefskiss

[ericzolf]

It might make sense to make it clear that get_one remains the entry point by prefixing the two new functions with underscore? i.e. _get_by_name and _get_by_named_url

[john-westcott-iv]

I found a bug playing around with this and will be providing an update to the code.

[john-westcott-iv]

@AlanCoding items with just a single named reference (i.e. Orgs) would skip the named reference task in this current implementation. Since a named reference is a pretty simple git we could remove the check on ++ and always try the GET for a named reference first and then fall back to the lookup method. This should be much easier in the new implementation of the code. Let me know if you think its worth it, I'm currently debating if it would be "faster" since we already say to use "Name" but that would only apply to named lookups where they only have one part for the name so maybe not?

[AlanCoding]

How should we document features like this? We have plugin-level docs with examples, but because this is general that's not effective. For stuff like authentication, there are parameters that correspond to features so those options can be documented on their own.

To me that leaves the README. Maybe we need a general feature overview that covers stuff like this. Otherwise, how do users find it?

[john-westcott-iv]

@AlanCoding I did open an issue for updating all of the docs to say: "name, ID or named URL" #14208. Which would help but yea, we could also do something in the root readme.

[john-westcott-iv]

I put a place holder in the readme which will need a last minute replacement once we know what version this will be released with.

[AlanCoding]

so it's either going to be 22.5.1 or 22.6.0 or 23.0.0?

[AlanCoding]

so surprised no linter could pick this up

[AlanCoding]

This seems complete, I just want to look for some feedback that people see this and use it and it doesn't mess them up.