Login or Sign up with: More »
Home Search Stats FAQ Feedback
You are here: { Home / issue: Expose drupal_recurly_account via services views module };
+Sponsor new issue +Propose new issue

[ Issue ] 2035975: Expose drupal_recurly_account via services views module

  • Description
  • Sponsors (1)
  • Developers (1)

We are using drupal/recurly as the front end for our users to manage their accounts. But ultimately the status of their account is validated by our PC client software. The software uses the Recurly API and the Drupal services +services views module (REST server).

In order to accurately match up the accounts between Drupal and Recurly, we are interested in getting the data found in drupal_recurly_account table to be exposed via the REST server. If it was available to the “views” then we could then expose that view in that manor.

Maybe this is already possible and I'm missing it.

We did assume that user-xx where “xx” is equal to the entity id. But maybe that assumption doesn't work in all cases. I feel like maybe dotting our i's and crossing our t's by relying on the actual data would be smart.

Any thoughts?

patchranger

In about a day I am going to present my solution by posting a patch to the appropriate drupal.org issue.

Thu, 18/Jul/2013
Permalink

jayshoemaker75

PatchRanger,

Thank you. I look forward to seeing it. By the way - I am already using the “Services” module, and “Views” module. You were mentioning some other ideas. But I wanted to let you know that I kinda already have my app communicating with these modules in this way. Hopefully you understand. Thanks!

Jay

Thu, 18/Jul/2013
Permalink

patchranger

Don't worry, the solution does fully match your requirements: check it at https://drupal.org/node/2035975#comment-7659532 .

Fri, 19/Jul/2013
Permalink

patchranger

Hello Jay,

Do you have any questions how to set up testing environment? There are quite a lot of patches included into the proposed solution and they don't look trivial though the instruction from https://drupal.org/node/2035975#comment-7659532 is quite descriptive - so in case of any difficulty I am willing to help.

Dmitry.

Wed, 24/Jul/2013
Permalink

jayshoemaker75

Hello Patchranger. I'm still testing this out. I reached a snag running the complete test install with your included make file. I'm still working on seeing what I can figure out. I don't want to just send a note such as “it doesn't work” because I hate when users do that to me! So I'm still trying to figure out what I need help on!!!

I am concerned however… I feel horrible - I should have been more specific. But we are using a different versions of the “services” module. Our software is already communicating with it and I think it would be a bear for us to change it now. I also do not know if this is a problem or not. Still testing.

The version that you are using requires a LOT of patches, etc. I think the version that I'm using is a little more stable - but also might not be as cutting edge. The last commit was a long time ago - but that tells me that it works in some ways too….

The module we are using will expose anything created by views. So all I really needed was the recurly_accounts table exposed via views. Then it would be available on our services for our other apps to use and work with. It sounds like you went above and beyond and that's great - as long as it fits with our project requirements.

Again - I'm still testing but I also wanted to get that out on the table about my concerns. Here are some links.

https://drupal.org/project/Services
https://drupal.org/project/services_views

Fri, 26/Jul/2013
Permalink

patchranger

Hello Jay, nice to hear a word from you!

I'm still testing this out. I reached a snag running the complete test install with your included make file. I'm still working on seeing what I can figure out. I don't want to just send a note such as “it doesn't work” because I hate when users do that to me! So I'm still trying to figure out what I need help on!!!

Me too: I don't like to hear such uninformative reports as 'HELP ME!!!11' :) Thanks for clarifying current situation a bit. I am still available for help. I did my best making patch instructions as clear and easy to understand as possible. Here is my additional effort: I have re-rolled the patch to make it apply automatically using drush make: https://drupal.org/node/2035975#comment-7689871 - enjoy!

I am concerned however… I feel horrible - I should have been more specific. But we are using a different versions of the “services” module. Our software is already communicating with it and I think it would be a bear for us to change it now. I also do not know if this is a problem or not. Still testing.

Please don't worry, there is absolutely nothing to be concerned about. Your existing infrastructure is not endangered or going to be replaced by that patch. As I tried to explain in https://drupal.org/node/2035975#comment-7659532 , the proposed solution is fully compatible with any software, which uses Services.
Well, let me describe it that way. The communication between any pieces of software is based on two, which are not the same:

  • Client: who makes a request, asking for some resource.
  • Server: who waits for requests and gives an answer.

Services module turns any Drupal site into a Server: it could begin accept requests in some specified format (JSON, XML,..) using specified protocol (REST, SOAP,..). But in order to get data from Recurly, we need to be a Client, making requests to their public API. It makes clear that services_views is not related to the task - because it can't request any data. That is what patched version of Recurly does: during execution of specially configured view (which is regular Views-plugin, you could find it among others at admin/structure/views/add) it sends a request to Recurly API and turns the response into Views output.

The module we are using will expose anything created by views. So all I really needed was the recurly_accounts table exposed via views. Then it would be available on our services for our other apps to use and work with. It sounds like you went above and beyond and that's great - as long as it fits with our project requirements.

Yes, your requirement was a lot more concrete and humble: expose recurly_accounts table to Views. I dared to re-think it and to offer you much more flexible and powerful solution.

  • Could you imagine: it can get any data, available by Recurly API, and output via Views?
  • It doesn't suffer from sync problems (I mean the problem of discordance: some data is at local machine, some - is inside Recurly account): everything is got directly from its source in real-time; literally “what-you-see-is-what-you-get”.
  • … and other end user features, listed in the original posting.

Again - I'm still testing but I also wanted to get that out on the table about my concerns. Here are some links.
https://drupal.org/project/Services
https://drupal.org/project/services_views

Your concerns have been heard. Please continue testing - I am sure you'll be pleased with the result.
Let me remind about lifehack that I've created for you: https://drupal.org/node/2035975#comment-7689871 .

Cheers,
Dmitry (aka PatchRanger).

Fri, 26/Jul/2013
Permalink
Sponsor
Offer
Acceptance
Status
Date
Expire Date
jayshoemaker75

US$ 50.00

No forking
Release required
[More...]

PAID

Jul/06/2013

{[{ current_offer.author }]}'s acceptance criteria
Close
Developer
Status
Date
patchranger

IN_PROGRESS / Accepting payments

Thu, 18/Jul/2013

Overview

Recurly
linefix

US$ 100.00

Paid

Sponsor this issue Work on this issue
{[{ actionmodal.title }]}
Offer value:
in Days

FreedomSponsors will charge a 3% fee on top of your payment. For offers in US$, Paypal's fees will also apply. Learn more!

Cancel {[{ actionmodal.buttonlabel }]}
Created by
jayshoemaker75

Help fund this issue. Share on:

FAQ Developers Project list Facebook JavaScript license information FreedomSponsors, Copyright © 2012-2013