Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persist trainer id in EquipmentAuthorization UserMemberships #40

Open
chungl opened this issue Jan 10, 2024 · 1 comment
Open

Persist trainer id in EquipmentAuthorization UserMemberships #40

chungl opened this issue Jan 10, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@chungl
Copy link
Collaborator

chungl commented Jan 10, 2024

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 #38 (comment)

@chungl chungl added the enhancement New feature or request label Jan 10, 2024
@Jnesselr
Copy link
Member

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 meta_data 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants