search

Denhac / denhac-webhooks

This repo holds some of our membership automation stuff. It listens to webhooks from the main wordpress site
7 stars 2 forks source link

Persist trainer id in EquipmentAuthorization UserMemberships #40

Open chungl opened 5 months ago

chungl commented 5 months ago

It is potentially valuable to know who authorized (trained) a member to use a piece of equipment.

We should extend the appropriate endpoint and model at denhac.org, and pass this information through when adding UserMemberships for equipment authorization.

If you want $actorId to carry over into the metadata, we can do that too as a separate PR.

_Originally posted by @Jnesselr in https://github.com/Denhac/denhac-webhooks/pull/38#discussion_r1446023065_

Jnesselr commented 5 months ago

I'm gonna explain a bunch of stuff and then give a recommendation.

The user membership object supports a meta_data key. You can see it in this section here. For "private" metadata fields, we prefix with a _, for public we don't. Essentially this means that in wp-admin a metadata field prefixed with `` will not show up automatically on the edit post view. You can see us update that field via api here.

Now some pages don't by default show any post meta and the admin pages we're dealing with are one of them. There's action hooks all over this page in the admin, we can absolutely just place it somewhere. We can also use it in the public view if we wanted and link to that trainer's public member page. Only caveat to that is of course people might think "I need to poke that person to get trained" which wouldn't be the best.

The other option is to make an admin only profile field. We'd want to check there that the api keys we're using for the rest api would be able to populate that field.

We also will probably want to make sure that we can somewhere do a hook when displaying these fields on denhac.org, even if admin only. That way we don't get "trained by user id 7", we get the name/user link. Doesn't seem like there's a hook in there per field in the admin view, but there is a hook for before and we could just add it there:

do_action( 'wc_memberships_before_user_membership_profile_fields', $this->user_membership, $profile_fields, $this );

The last somewhat annoying thing is profile fields are very much global. So even if "trained by" isn't valid for that membership plan type, it will show up in the admin panel. That's the other reason I haven't really used them yet and why I generally recommend using the meta_data here.