Skip to content
  • homotechsual @homotechsual ·

    I love this idea - it'd be nice if it used extensions/action-provider to allow configuration of the link actions a-la DataProcessor/FormProcessor

    Edited by homotechsual
  • Rich @artfulrobot ·

    So for the uninitiated, which bits could action-provider do? Can you give examples of how that might be used to do cool things that people need to do?

  • homotechsual @homotechsual ·

    Action Provider can provide the framework to perform the actions e.g. Create/Update ENTITY. Send Email etc. I believe it also bundle an angular framework for configuring the actions.

  • Rich @artfulrobot ·

    yeah, ok. It's always a trade off between actually being useful and having an amazing but bewildering selection of nuts and bolts. (that's why I think real world use cases are important here)

    e.g. the once per contact bit - I imagine this gets more tricky once we're not talking about adding an activity. But then maybe that could be part of a new "action provider action" that creates an activity if one doesn't already exist.

    Another thing is kick CiviRules into action instead of creating an activity. Would that be better?

    Edited by Rich
  • Rich @artfulrobot ·

    Jon suggested that his Fast Action Links extension could be extended to provide these features. I'll take a look.

  • Rich @artfulrobot ·

    Fast Action Links comparison

    • a "location", this could be extended, adding "remote" or "external" link.
    • An action type, one of add/remove tag, add to group, trigger civirule. I could add a type here "add activity", or learn about how to integrate action-provider actions
    • Profile ID: N/A
    • Hover text: N/A
    • Success Message: N/A
    • Dim on use: N/A
    • Confirm: N/A
    • Order: N/A
    • Is active: Y/N

    Fast Action Links takes action on a GET request (i.e. clicked link) from an authenticated user. The overlap seems to be that my idea here and this extension both provide configurable links that do something.

    The differences would be:

    • this idea's links are headless; they have no user UI; Fast Action Links is a UI improvement.
    • need a redirect action
    • need an add activity action
    • need various conditions to determine the actions taken.
    • need links to include authentication tokens as typically users would not be authenticated.
    • need to record metadata on use.

    I don't immediately see that Fast Action Links could be sensibly extended to cover these extras. They both provide GET routes, but that's about the end of the similarities!

    Edited by Rich
  • Rich @artfulrobot ·

    Form Processor integration - idea ammendment

    The "Activity Links" extension idea could be renamed as the more generic "Action Links" extension. It would then let admins create links - as in the original idea post, but without the activity bits, instead it would call a specific Form Processor, passing in the query string data and also the Action Link entity data. The Form processor would then need to spit out a redirect URL, which this extension would send on to the browser.

    So an "Action Link" would have these properties:

    • name string
    • active bool
    • success_url NULL|string (if no URL, an empty response is issued)
    • denied_url NULL|string (if no URL, an empty response is issued)
    • contact_required bool (possible that we don't need a specific contact)
    • form_processor string name of a configured Form Processor.
    • form_processor_params pairs of params to add to the data going to the form processor.
    • use_count int
    • use_limit NULL|int (after this number of uses requests are rejected, and the denied_url is returned)
    • use_contacts_limit NULL|int (denied if this number of unique contacts have used link)
    • use_per_contact_limit NULL|int (denied if this contact has used the link more than this many times)
    • use_by NULL|datetime (denied after this)

    So the flowchart would be as follows. (AL: means functionality provided by this new extension)

    • Browser requests URL
    • AL: provides endpoint for the URL
    • AL: loads the Activity Link.
      • 404, no content if not found
      • 302 with Location: denied_url if disabled
    • AL: validate contact if required.
      • 302 with Location: denied_url if invalid (or possibly 400 would be better?)
    • AL: increment use_count
    • AL: if use_count > use_limit return 302 → denied_url
    • AL: also handle the other use_* limits. (We will use a minimal action_link_contact table.)
    • AL: add the query string params to any preset AL form_processor_params and call the FormProcessor API.
    • Form Processor: does its thing.
    • AL: return success_url (possibly check output of Form Processor and return denied?)

    Then the only bit that's missing is recording the activity. This logic is left to the form processor.

    I'm quite keen on this idea with Form Processor. Thoughts? @mikeymjco

  • homotechsual @homotechsual ·

    I like the idea as well - though calling the formprocessor API seems a bit odd but I guess it's a better option than rewriting your own integration code with the activity_provider?

    I'm assuming the activity type etc will be passed as query string params to allow them to be easily overridden with tokens - it'd be nice to be able to configure defaults so it's not required to pass parameters which aren't configurable - i.e if I'm always using activity type A for a link it's superfluous and untidy to pass "activity_type=A" with every link.

    Updates/Edits:

    This is neat in that it would provide not just "activity links" but "anything form processor does" links. I'm thinking of a really neat "Refer a Friend" link which could track the referral process and perform actions based on the referral.

    Edited by homotechsual
  • Rich @artfulrobot ·

    @mikeymjco

    "anything form processor does" links

    Quite.

    calling the formprocessor API seems a bit odd

    I suggest calling the API so that form processor can do it's full thing. If I start offering action_provider things and giving people a UI to add conditionals etc, I'm massively duplicating somethign that's already there ... was my thinking.

    The reason for having a form_processor_params list on the action link is so that those don't need to be in the actual URL given to the public. But -as I understand- Form Processor doesn't seem to allow you to specify constants, so you have to feed those in and map them. With the exception of things that Form Processor thinks have to be constants (like Activity Type!).

    So, to use the original example: record downloads of a resource,

    {
   success_url: 'https://secret.link.com/action-guide.pdf',
   denied_url: 'https://exapmle.com/soz-you-missed-it',
   form_processor: 'the_one_i_made_to_record_an_activity',
   form_processor_params: {
      subject: 'Downloaded action guide'
   },
   contact_required: true
}

    The form processor would need to:

    • find an existing activity with that subject and that contact ID and the "downloaded resource" activity type.
    • create it if it doesn't exist, with today's date.

    "Refer a Friend" link

    sounds interesting.

    Edited by Rich
  • Rich @artfulrobot ·

    Please see, test, comment on it at https://lab.civicrm.org/artfulrobot/actionlinks

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment