Skip to content
This repository was archived by the owner on Nov 6, 2019. It is now read-only.

Free tix_attendee for access via REST API #149

Closed
leobaiano opened this issue Sep 28, 2016 · 7 comments
Closed

Free tix_attendee for access via REST API #149

leobaiano opened this issue Sep 28, 2016 · 7 comments

Comments

@leobaiano
Copy link

Whenever we generate the certificate for the participants of WordCamps here in Brazil we generate an .xls and we set up a PHP script to read the data and automatically generate the certificate.

Today talking to the staff of WordCamp Rio de Janeiro, which is currently working on creating certificates, I made the suggestion to access the json, via REST API, instead of generating the .xls and we are frustrated to see that the CPT is tix_attendee private and because it returns 404 when trying to access the API endpoint.

I would suggest it to be released so that we could build a tool that generates certificates from this json or maybe creating a plugin that can be installed in the WordCamps sites to do this work.

What do you think about this?

@gugaalves
Copy link

gugaalves commented Sep 28, 2016

Adding a note: In Brazil, many colleges have a special rule that every student have to do some additional activities like some internship or attend events related to your course, so every WordCamp in Brazil needs to deliver a certificate to prove that this student had attended an event and how many time he was in the event. So we're trying to create a way too use rest api to get the attendee list to generate this certificates.
Maybe creating an additional module on Camptix (feature request) would simplify this task, or else we'll need to manually create a .org site and install a plugin to achieve this on each brazilian WordCamp.

@iandunn
Copy link
Contributor

iandunn commented Sep 28, 2016

One concern here is the attendee's privacy. We do usually expose their name and a few select meta fields via [camptix_attendees], so that would be fine to do via the API too. However, there is an option for attendee's to opt-out of that, so that would need to be respected via the API.

Which meta fields get exposed is determined in the shortcode, so there isn't a straight-forward way to mimic that in the endpoint; it'd probably require searching for the page(s) with the shortcode and parsing them out via regex.

It seems like supporting authentication would be a better route to go, but I don't think that'll be a trivial amount of work.

Can you describe the benefit of accessing the data via the REST API instead of exporting via CSV? I'm guessing that it's because it allows your script to fetch the data and generate the certificates, instead of having to import the data manually. Is that correct, or are there other benefits that I'm not seeing?

If that is the main benefit, then I'm not sure this would be worth the effort. I think it'd take much longer to deal with oAuth, etc, than it does to manually import the data. I'm not aware of any other camps that have this use case, either.

xref https://wordpress.slack.com/archives/meta-wordcamp/p1475075430000293

@gugaalves
Copy link

gugaalves commented Sep 28, 2016

@iandunn, exporting it via CSV could solve it too.
I think the main issue here is that every WordCamp here at Brazil will have to install a plugin (created to this purpose) on a .org installation just to generate this certificates.
Besides using API for it, can we create an additional module on camptix for this purpose? @claudiosmweb have already created a Pagseguro add-on that we use on Camptix, maybe he can help us to do it if it's possible to add it in Camptix.

@leobaiano
Copy link
Author

You are correct, I wanted the endpoint API to not need to do this work of CSV export and import in a system that would generate the script, I thought it would be simpler to create an endpoint for it. If you have to leave for the solution of the regex and authentication do not seem worth the effort.

And if we do something that runs internally and send email to participants?

@leobaiano
Copy link
Author

@iandunn And it's time to register the CPT set show_in_rest => true and keep private => true.

In my view it would keep the CPT as private, but public API. Then use the filter rest_prepare_ tix_attendee for unset to give the meta data that should not be public?

I believe that in this way could solve.

@iandunn
Copy link
Contributor

iandunn commented Sep 29, 2016

set show_in_rest => true [...] Then use the filter rest_prepare_tix_attendee

@leobaiano, That would be part of it, but are also other things we'd have to consider:

  • We'd also need to install the endpoints plugin, which we're not currently running, and look into any issues that presents in terms of compatibility with v1 of the plugin, and our customizations.
  • We'd need some code to hide attendees who opted-out from being displayed publicly
  • If any meta fields are desired, then we'd need the regex stuff above to determine which fields were declared as public via the camptix_attendees shortcode.

We'd probably need to do it in a WordCamp.org specific addon, because we can't assume that all CampTix sites would want that info public.

I think the main issue here is that every WordCamp here at Brazil will have to install a plugin (created to this purpose) on a .org installation just to generate this certificates. Besides using API for it, can we create an additional module on camptix for this purpose?

@gugaalves, that seems like a better approach to me, rather than exposing the data via the API. This way, the add-on would have access to all the data, but in a private way.

That could even have other purposes beyond generating certificates, like generating invoices, which is something a lot of European camps need for legal reasons. If the add-on allowed the admin to customize the text of the "certificate", then generated a PDF, it could be useful for a lot of purposes.

It'd also be great if it could e-mail the PDF to the attendee, so the organizer doesn't have to manually distribute it. The organizer would need to be able to select which attendees to send to, though - maybe with a filterable JavaScript interface like the Notify tool has.

Since that would be a bigger project, I think it'd be best to start with a proposal on the make/Community p2 to get feedback from deputies and other organizers.

Background on invoicing:

It may also be useful to integrate with the WordCamp Docs plugin

@leobaiano
Copy link
Author

Thanks for returning Ian!

I will close the issue because you've answered the question.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants