net/freeradius: Add more attributes to users and remove radiusd.conf

[mimugmail]

• remove radiusd.conf since it's not used/touched by the plugin and the libdir is always changed with every update of the freeradius3 package, so not compatible with managing via plugins (needs a reinstall of freeradius3).

• add ChilliSpot and WISPr attributes. Here I need some help from @AdSchellevis
  You did some magic for @fraenki and the acmeclient:
  https://github.com/opnsense/plugins/blob/master/security/acme-client/src/opnsense/mvc/app/views/OPNsense/AcmeClient/validations.volt#L51-L76
  https://github.com/opnsense/plugins/blob/master/security/acme-client/src/opnsense/mvc/app/controllers/OPNsense/AcmeClient/forms/dialogValidation.xml#L39

What I want to achieve is:

• In Tab "General" a checkbox for en- or disabling additional attributes:
  https://github.com/mimugmail/plugins/blob/freeradius_att/net/freeradius/src/opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/general.xml#L14-L19
• If checkbox in General is checked, display the specfic attributes in popup when adding a user
  https://github.com/mimugmail/plugins/blob/freeradius_att/net/freeradius/src/opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/dialogEditFreeRADIUSUser.xml#L45-L67

I asked fraenki but he didn't really remembers what all the JS magic is actually doing :)

If it's not possible or your time too limited I would pack everything too specific in <advanced> so the dialog is not overloaded with many input fields.

Thanks for any hints! :)

[mimugmail]

@AdSchellevis Did you have the time to look at this? If not I'd like to move everything beside standard to <advanced> cause I don't like hacky solutions I dont understand myself :)

[AdSchellevis]

@mimugmail I was some days away, haven't seen the question. The JS stuff should be quite simple, I can do it for you if the rest of the code is in the master branch and I know what to show/hide.

The "magic" in the JS code lies in hooking the "onShow" event from the dialog and handling the hidden fields from there. But if the rest of the code is finished and this can be pulled I don't mind adding it for you.

[mimugmail]

@fichtner Please review
@AdSchellevis Thanks for your offer! I renamed some fields get a logic:

When field in general is enabled (e.g general.wispr) then show every field in user with _ (e.g. user.wispr_XXX).
I did this also with chillispot and it would pretty scale.

[AdSchellevis]

@mimugmail ok, sounds good, can you open an issue when this code is in for me? (just to make sure I won't forget)

[fichtner]

LGTM, but assigned to @AdSchellevis for follow-up core thingy

[mimugmail]

@AdSchellevis please merge, very exited how you solve this one :)

[AdSchellevis]

@mimugmail this should do the trick 6105bf5

Since your form is bound to the general settings, we need to fetch them first, after which we can hide what isn't needed.

This could potentially mess up the zebra stripes, but should keep values of the fields when saving a user again. Another option is to drop the tr tags, keeps zebra intact, but trashes previously saved values if not enabled in the general section anymore.

[mimugmail]

@AdSchellevis works great, thanks! Only problem is that disabling the section in general keeps the settings in users in DB. So this logic is only be allowed if the tick in general has no other meaning and does not en-/disable a feature the attributes in users rely on. Anyway, it keeps the view short and simple, I'll add a info to the help and hopefully all are happy.

Thank you! :)

[AdSchellevis]

@mimugmail you're welcome :)

If you want to ignore old settings on save, you can remove the tr tag, which stops the save from sending the data to the controller.... but settings for other users will obviously remain in the file.

[mimugmail]

@AdSchellevis I decided to keep the values and add a note. Otherwise a false tick disabling in general would squeeze a bigger user setup :)

[AdSchellevis]

@mimugmail sounds good to me