Proposal: Add url field to all action types

[j-ro]

We'd like to propose adding a url field to action types -- for now, that would mean events, but in the future it would also include petitions, donation pages, and the like (all of which we'll be proposing at some point).

The field would point to a URL of the page representing the action, so in the case of events, the online RSVP page. Of course, like other fields, it's optional, so systems would disregard it if it wasn't present.

Here's an example event with the field:

{
  "identifier": [
    "action_network:e0b68fa0-c9f2-426b-828e-1142998d1421"
  ],
  "status": "confirmed",
  "created_at": "2014-02-18T20:54:16Z",
  "modified_at": "2014-02-20T14:00:37Z",
  "summary": "This is an event with an Online RSVP form",
  "url": "https://system.com/events/event-rsvp-form",
  "start": "2014-02-22T17:45:00Z",
  "transparence": "opaque",
  "visibility": "public",
  "guestsCanInviteOthers": true,
  "reminders": {
    "method": "email",
    "minutes": "1440"
  },
  "total_accepted": 4,
  ...
}

[joshco]

I like this idea in principle. However, could we pick an attribute name that indicates this is a user facing page? URL may be confusing since the API resource itself has its own URL

[j-ro]

Sure, open to suggestions! Maybe "public_url"?

[joshco]

how about "browse_url"

[j-ro]

Sure, that's fine too -- really whatever works for folks. We can discuss on the call when it comes up in the agenda.

[joshco]

OK. my thinking was that the attribute should indicate that it is something you interact with a web browser. It's UI rather than API.

[j-ro]

Maybe even browser_url then might be better. I agree with the thinking though.

[BrianVallelunga]

I think we have "url" in a few of the other places throughout the spec. If we're going to adopt "browse_url" we should change it in those as well. Just having "url" seems clear enough to me since it won't be in the _links section ever, but I don't care much other than to make them consistent.

[mpaquette1]

Our nonprofit clients often have multiple signup forms for the same event, e.g., one for students/seniors, one for regular individual members, and one for organizations and sponsors. They need to feed into the same event so we can get an accurate chair count across the types of attendees. In addition there can be separate forms for earlybird registrations vs regular registrations, again for the same event. The client generally sends an email to the identified group containing a personalized link to the appropriate form. The relationship between signup forms and events can be one-to-one, one-to-many, or many-to-many, as one form can handle many events, and one event can be fed by many different signup forms.

My suggestion is that the signup url be a property of the rsvp, not the event itself. I the group decides the url is better off living with the event record and not the attendance record, we should make it into an array of urls rather than a single string.

Mark Paquette Co-founder & CTO thedatabank, inc 612-455-3502 mark@thedatabank.com

http://www.thedatabank.com/

https://www.facebook.com/thedatabank http://twitter.com/#!/thedatabank http://www.linkedin.com/company/thedatabank

On Wed, Mar 19, 2014 at 7:59 AM, Brian Vallelunga notifications@github.comwrote:

I think we have "url" in a few of the other places throughout the spec. If we're going to adopt "browse_url" we should change it in those as well. Just having "url" seems clear enough to me since it won't be in the _links section ever, but I don't care much other than to make them consistent.

Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/107#issuecomment-38047207 .

[j-ro]

My view would be stuff like that is more appropriate for a sources array or something similar than url -- the idea here is a connonical url for a page. If you don't have one (or have more than one) than this would likely be blank.

Sources needs more work, though, not sure it's ever a pull request yet...

[joshco]

browse_url

[BrianVallelunga]

@mpaquette1 I agree with Jason that the sort of form -> signup tracking you're looking for should probably be done in a sources field. My suggestion would be to create a convention that for a URL like: http://site/events/bigevent/studentsignup you add a source to the sign-up such as "form:studentsignup". I think this accomplishes what you're after.

That said, we should probably take a look at which models would need the "sources" and "attributions" arrays. This isn't a pull request, because I'd like to agree on the terms and definitions first (https://github.com/wufm/osdi-docs/issues/124) and then go back and look at where we can apply the fields.

[joshco]

add attr to petition, events, forms, fundraising_page

[itsdrewmiller]

I'm gonna go with browser_url here (per @j-ro 's suggestion) since I think it has less implication that this is a place where you view vs signup for these things.

[itsdrewmiller]

There actually was already a "url" property for the same thing on everything but events - I'm converting that and adding it for events. We don't have very good examples for fundraising pages interactions.

[itsdrewmiller]

https://github.com/opensupporter/osdi-docs/pull/164 is the pull request for this.