Update on #12446.
@davidtaylorhq A draft for an update on the associated group membership work. It’s been rebased, brought in line with the latest changes and updated in the ways explained below. Let me know if you’re onboard with the approach so far. I’ll finish it off next weekend.
I’ve removed the secondary auth stuff, added a google-hd-specific boolean setting, and moved the group retrieval into a new google oauth2 omniauth strategy. I’ve made a new folder and added a spec for the strategy (something new in the codebase) as I thought it deserved a spec (which is also included). If we add in secondary auth to this strategy that too will need a spec. Some of the existing discourse omniauth strategies, e.g. Discord, may benefit from being seperated out and tested too.
As suggested, I’ve added a
provides_groups? to the
Auth::Authenticator. Using this approach led to a new groups guardian method to use at the various group CRUD points. Speaking of which, I’ve added in support for group_associated_group creation in group creation (i.e.
/g/custom/new). Supporting it in both
manage (update) also led to adding a new site attribute
can_associate_groups. I attempted to make this more group-route specific, however this leads to various clumsy workarounds to determine whether an admin can associate groups in
/g/custom/new. The site attribute approach proved the simplest and most performant (i.e. fewer ajax calls).
I’ve made one change to the data model so far, namely to use
after_commit hooks rather than
after_destroy as using those hooks leads to duplicate record creation in the
create controller. I’ve yet to deal with the edge case you pointed out, i.e. multiple UserAssociatedGroups which link to the same group.