Permission handling additions

[LBegnaud]

Desired Behavior

Adding onto the discussion in #146 , I would like to include the ability to make the permission_codename search function customizable

Contrast to Current Behavior

currently you must explicitly set all permissions you'd like on a group/user in the yml file. Would like to include the option to change this via the config file (and keep the default as codename=

Changes Required

I can submit a PR with the changes, but essentially, add the option to check for a custom function for each permission entry. I.E in the groups.yml

NetBox - Add:
    permissions:
    - add_
      - codename_startswith

would cause the permissions loop to use Permission.objects.filter(codename_startswith='add_')

Discussion: Benefits and Drawbacks

Preserves the current functionality and introduces the benefit of being able to make a clean groups.yml file that defines some generic groups:

  NetBox - Add:
    permissions:
    - add_
      - codename_startswith

  NetBox - Change:
    permissions:
    - change_
      - codename_startswith

  NetBox - Delete:
    permissions:
    - delete_
      - codename_startswith

  NetBox - View:
    permissions:
    - view_
      - codename_startswith

I haven't started the process of building this out, so i'm unsure if this is the exact syntax, maybe it would just be

  NetBox - View:
    permissions:
    - view_: codename_startswith

but i believe this is possible regardless.

[LBegnaud]

decided on using the codename filter function as a key in the permissions section of a group or user yml file. I'm finalizing a PR but basically instead of specifying an optional codename filter function for each codename, The original permissions yaml syntax will assume filter function codename and otherwise will loop through all codnames specified for a codename filter function.

Will submit the PR shortly

[cimnine]

Thank you for this idea. I have some reservations about this though, as I explain below. Just to be clear, this is my personal opinion so far, it's not a strong opinion yet and I welcome other opinions.

What I like: This is a very flexible feature and could make handling permissions in the initializer scripts easier.
What I dislike: The proposal is a very technical feature that requires knowledge about the inner workings of Netbox, Django and/or Python. If codename_startswith is the only feature that is relevant anyway, I would rather see us implement an asterisk-style matching:

• if there is an asterisk at the end of the permission's name (e.g. permission_*), then strip the asterisk and treat the permission name as codename_startswith=permission_
• else do the regular matching.

On a more general level, I wonder how far we should go with those initializer scripts. They were initially thought to be used to ease local development, i.e. to bootstrap an empty Netbox instance quickly; an instance that does not have many users or other entities and that is eventually destroyed anyway.
And that's also the quality level these scripts have in my opinion. So I wonder how many features we should pack on top of them, or if we should rather try to get those scripts upstream somehow, where they could be properly maintained.

This is merely a brain-dump and as I said initially, I would love other opinions. Also on how and for what people use the initializer scripts.

[LBegnaud]

I quite like the idea of simplifying it using asterisks. Should be trivial to determine the codename filter based on placement of the asterisk. I must admit, however, that this PR was stretching my python abilities as is...

Speaking to your general comments, I'm using these catchall permission definitions to keep my group permissions up-to-date through the changing netbox schema, so i suspect that would be useful for others as well. I agree that the rest of the initializers probably aren't terribly useful after an initial creation.

[LBegnaud]

...that was much easier than expected. I've updated the PR to utilize codename if the permission doesn't have a wildcard (*) and utilize codename__iregex if it does include the wildcard. Let me know what you think!

[cimnine]

@LBegnaud can you have a look at #236 ? I've taken your work in #200 and made some minor changes to it, particularly to avoid the use of eval. (Because eval is evil 🙈.) If you agree, I would close your PR when I merge mine and proceed to include this enhancement with the next release.

[cimnine]

This feature is included in the just released version 0.22.0.