[4.x] Allowing adding a blueprint to user groups

[ryanmitchell]

Ok be gentle as I've not worked with Vue a whole lot.

This PR adds the ability to modify the blueprint associated with a user group by adding some new routes, controllers and borrowing from the existing user blueprint approach for this. This would allow developers to add new fields to the groups, such as images, descriptions or whatever they want.

The only 'breaking' change I can see is adding data() to user groups and how that would affect eloquent - would love to hear your thoughts on this.

I will definitely have missed some things here, so marking as a draft for now. But I would value feedback at this stage.

Closes: statamic/ideas#798

[jasonvarga]

Looks like a good addition to me. What more feedback were you looking for at the moment?

[ryanmitchell]

That’s probably enough - just wanted to know if it was worth spending time on or if there was a reason it wasn’t there already. If there’s anything approach wise that looks wrong to you do let me know.

[jasonvarga]

I think you're looking good! We haven't added the feature because no one wanted it yet. 🤷

[ryanmitchell]

I think this is good to go, but the tests are failing due to a segmentation fault (something on Github's side?)

[jasonvarga]

Nice. Some things I noticed:

• When you save the user group in the CP, the page title disappears.
• When you save the user group in the CP, no custom field data is added to the file.
• The blueprint should be added to the blueprint index. (/cp/fields/blueprints)
• UserGroup's augmentedArrayData will probably need to be updated in order for the custom fields to be used in templates, Add user_groups tag #6505, etc.

[ryanmitchell]

Thats really helpful thank you. Ive got them all fixed now.

[jasonvarga]

I'm not sure why the tests are failing like that. I pulled the suite down locally, used the same PHP version and composer deps, and it all passes. 🤔

[ryanmitchell]

Same! No idea what’s going on.

[ryanmitchell]

I've got all the tests passing by specifying a min version of phpunit (8.5.23) on the PHP8 mockery action. Hope this is an acceptable solution.

[jasonvarga]

Yeah I'm fine with that.

Looks like Orchestra requires 8.5.21 at a minimum, and 8.5.23 fixes a memory leak. Segfault seems like that's probably what it is. sebastianbergmann/phpunit#4799

[jasonvarga]

This is in a good spot. I think there's just one more thing to sort out.

The handle. Before this PR, you'd get red warning text if you try to change the handle, telling you that references won't be updated.

Now that handle becomes just a basic blueprint field, that feature is gone. I'm fine with putting that text just into the instructions, but then it's also possible to not include the handle field at all. In that case, the handle gets updated based on the title, which is awkward.

I'm thinking this:

• Leave off the handle field from the user group blueprint
• Explicitly add it in the "create" route
• Remove the handle-from-title fallback behavior - if you don't submit the handle, it just doesn't get updated.
• If you want to add a handle field, it becomes the user's responsibility to put instructions saying that it could mess things up.

(Just putting these as notes to ourselves to sort out. You don't need to do anything, @ryanmitchell)

[ryanmitchell]

Thanks for the work on this. Its genuinely appreciated.

[jasonvarga]

We can't inject the handle field directly after the title field (we can add it to the top or bottom of the form, but that's awkward), and adding a feature to do so would require a fair bit of work. So we're just going to remove the handle field. At least for now.

So, by default, the handle will get snake_cased from the title on creation.
If you want control over the handle, you can add it to your blueprint.

[ryanmitchell]

Amazing. So good to see this merge, thank you!