`forgejo_team`: Refactor `permission` & `units_map` attributes

[acch]

forgejo_team has two related attributes permission and units_map. There are certain dependencies between these two attributes, which are not properly documented and not validated during terraform plan.

permission is currently optional, with a default value of read. This does not cover all use cases, see #147 for an example.

We need to:

1. Understand the exact dependency between these two parameters.
2. Refactor the schema to prevent this from becoming a footgun. (e.g. combine into a single attribute, add custom validation logic, etc.)

For reference, here's how the UI presents team permissions/units:

[acch]

The more I think about it, the more I'm wondering if we even need permission as a (writable) attribute at all...

It appears to me that we can derive all valid configurations from units_map alone. permission could be changed to a read-only (computed) attribute. This would sort out much of the headaches we currently have with the dependency between these two parameters...

@kad-hollac1: what are your thoughts on this? Am I missing something?

[kad-hollac1]

Sorry for the late response, I was on holiday. :)
I'll dive into what the permission does. But on a glance, you are correct.

[kad-hollac1]

The permissions/units for a team are handled here [0]. It shows a few things.

• If the permission is set to owner, then the unit map is ignored and admin permissions are given to all units.
• If the permission is set to admin, idem.
• If the permission is set to something lower than admin (e.g. write), but the units map has at least one read permission, the permission is set to read.

So to me it would seem logical to have either permission set to admin (or owner) or use the units_map. So if units_map is defined, permission may not be. If the units_map is not defined, permission must be admin or owner.

[0] codeberg.org/forgejo/forgejo/src/branch/forgejo/routers/api/v1/org/team.go#L310-L336

[acch]

@kad-hollac1 Thanks much for your analysis. It starts making more sense now... what about the following:

• permission and units_map are mutually exclusive. Only exactly one of the two must be defined.
• valid values for permission are admin and owner (no more read and write)
• valid keys and values for units_map remain unchanged

Would this address all valid use cases, while restricting misuse (ref. #147)? What do you think?

[kad-hollac1]

I think that solves it, indeed! :) The hard part is the documentation. ;)

(I'm very much willing to work on this, but I like to limit my # of open PRs, so after #167.)