Date   

/getsubgroups change

 

Hi All,

Previously, /getsubgroups would return group aliases in addition to normal subgroups. I've changed it so that it no longer returns group aliases. There is a new endpoint, getgroupaliases that returns the aliases for a given group.

Also, I have changed /directadd so that if you specify a group alias as a subgroup, it no longer generates an error, but instead does the right thing and uses the group the alias points to.

Thanks,
Mark


Doc improvements

 

Hi All,

I just pushed several improvements to the API docs. Much better expand/collapse behavior in the sidebar, and the sidebar is separately scrollable now. Also, long example responses are in fixed height scrollable windows. I've also made various other smaller tweaks. Hopefully it should be easier to navigate and find what you need now.

Thanks,
Mark


Re: Unparseable JSON http response on updategroup invalid_value

 

Hi Eric,

On Fri, May 17, 2019 at 3:21 PM Eric Searcy <eric@...> wrote:
/updategroup is returning both an error object and group object separated by a newline when I get an invalid_value error, which means the http response can't be parsed as json (without first parsing/splitting newlines. Is this intentional, or is there a missing return statement somewhere?

In my case, I had accidentally passed "polls_access=group_access_none" (which is the "disable" value the other features use, but polls uses "polls_access_none").

Thanks for the bug report. It was a missing return statement. It's been fixed.

Mark 


Unparseable JSON http response on updategroup invalid_value

Eric Searcy
 

/updategroup is returning both an error object and group object separated by a newline when I get an invalid_value error, which means the http response can't be parsed as json (without first parsing/splitting newlines. Is this intentional, or is there a missing return statement somewhere?

In my case, I had accidentally passed "polls_access=group_access_none" (which is the "disable" value the other features use, but polls uses "polls_access_none").

The output was:

{"object":"error","type":"invalid_value","extra":"polls_access"}\n
{"id":####,"object":"group","created":"2019-05-16T18:30:43.092324171-07:00","updated":"2019-05-16T18:30:43.092324171-07:00","title":"","name":[... and so on]}\n

(I've added the literal \n's for clarity)

Regards,

Eric


Re: API for database access

 

On Wed, May 1, 2019 at 8:59 PM Andrew Theaker <andrew@...> wrote:
Hi Mark, thanks for the quick reply. Is it the same for Events?
_._,_._,_
Right now, yes.

Thanks,
Mark 


Re: API for database access

Andrew Theaker <andrew@...>
 

Hi Mark, thanks for the quick reply. Is it the same for Events?


Re: API for database access

 

On Mon, Apr 29, 2019 at 4:32 PM Andrew Theaker <andrew@...> wrote:

The document is not really clear on access to a groups databases. We have a catalogue of all board games we own. It would be great if I could access this via API and render it in a nice view. I was thinking we could also create a database to tracking our results from events (wins/losses/attendance etc) and extract this information for compiling stats in graphs etc. Ideally I'd like to implement these things through a javascript front-end and just query the API as required.

Currently there is no API access to a group's databases. That is on the TODO list, but I don't have a timeframe for when it will happen.

Thanks,
Mark 


Re: "type" query param of /v1/getmembers non-functioning?

 

Hi Eric,

On Mon, Apr 29, 2019 at 5:38 PM Eric Searcy <eric@...> wrote:
The "type" of https://groups.io/api#get_members doesn't seem to do anything.

Thanks for the bug report. It should be fixed now.

Mark 


"type" query param of /v1/getmembers non-functioning?

Eric Searcy
 

The "type" of https://groups.io/api#get_members doesn't seem to do anything.

I was hoping to use &type=mods (and then further filter to just see
owners) but I got the entire list membership.

Then I tried type=pending and got the same thing.

Is this a bug, a doc issue, or am I doing something wrong?

-Eric


API for database access

Andrew Theaker <andrew@...>
 

Hi,

We are currently thinking about upgrading our group to premium and I'm trying to understand what benefits we could get from the API access.

The document is not really clear on access to a groups databases. We have a catalogue of all board games we own. It would be great if I could access this via API and render it in a nice view. I was thinking we could also create a database to tracking our results from events (wins/losses/attendance etc) and extract this information for compiling stats in graphs etc. Ideally I'd like to implement these things through a javascript front-end and just query the API as required.

Would these be possible with the current version of the API?


Re: Issue with /v1/updatesub

Eric Searcy
 

Thanks! (confirmed on my end, too :-) )

-Eric

On 4/25/19 9:30 AM, Mark Fletcher wrote:
Hi Eric,

It should now accept sub_id. If group_id is passed in as well, it will
be ignored.

Thanks,
Mark

On Thu, Apr 25, 2019 at 8:56 AM Eric Searcy <eric@...
<mailto:eric@...>> wrote:

Hi,

I'm calling updatesub as described in the documentation, and I'm
getting an error.

curl -v -u $GROUPIO_TOKEN: -d sub_id=##### -d sub_notify=sub_notify_none

=> {"object":"error","type":"bad_request","extra":"group_id"}

(Where ##### is the returned "id" field of the membership info
object when I ran /v1/getsub against a group_id I'm subscribed to.)

I can work around the error by adding group_id to the request. 
Subscriptions seem to be globally unique identifiers, so the way the
API documents it seems like it should work.

Two questions:

1) Can either the docs be updated, or the API be changed to match
the docs?

2) If you change the API to match the docs, can you ensure that any
passed group_id is just ignored (so it doesn't break backwards
compatibility).

Thanks!

-Eric


Re: Issue with /v1/updatesub

 

Hi Eric,

It should now accept sub_id. If group_id is passed in as well, it will be ignored.

Thanks,
Mark

On Thu, Apr 25, 2019 at 8:56 AM Eric Searcy <eric@...> wrote:

Hi,

I'm calling updatesub as described in the documentation, and I'm getting an error.

curl -v -u $GROUPIO_TOKEN: -d sub_id=##### -d sub_notify=sub_notify_none

=> {"object":"error","type":"bad_request","extra":"group_id"}

(Where ##### is the returned "id" field of the membership info object when I ran /v1/getsub against a group_id I'm subscribed to.)

I can work around the error by adding group_id to the request.  Subscriptions seem to be globally unique identifiers, so the way the API documents it seems like it should work.

Two questions:

1) Can either the docs be updated, or the API be changed to match the docs?

2) If you change the API to match the docs, can you ensure that any passed group_id is just ignored (so it doesn't break backwards compatibility).

Thanks!

-Eric


Re: Recommend cleaning up quoting of non-string values in API docs

 

On Thu, Apr 25, 2019 at 8:49 AM Eric Searcy <eric@...> wrote:
The groups.io API doesn't appear to use quotes around numbers and booleans.  At the very beginning of https://groups.io/api (under Pagination) it shows a correct response, however all subsequent sections (objects and the various calls that use them) show these numbers incorrectly quoted, not how they actually are presented by the API.

Good catch. It should be fixed now.

Thanks,
Mark 


Issue with /v1/updatesub

Eric Searcy
 

Hi,

I'm calling updatesub as described in the documentation, and I'm getting an error.

curl -v -u $GROUPIO_TOKEN: -d sub_id=##### -d sub_notify=sub_notify_none

=> {"object":"error","type":"bad_request","extra":"group_id"}

(Where ##### is the returned "id" field of the membership info object when I ran /v1/getsub against a group_id I'm subscribed to.)

I can work around the error by adding group_id to the request.  Subscriptions seem to be globally unique identifiers, so the way the API documents it seems like it should work.

Two questions:

1) Can either the docs be updated, or the API be changed to match the docs?

2) If you change the API to match the docs, can you ensure that any passed group_id is just ignored (so it doesn't break backwards compatibility).

Thanks!

-Eric


Recommend cleaning up quoting of non-string values in API docs

Eric Searcy
 

The groups.io API doesn't appear to use quotes around numbers and booleans.  At the very beginning of https://groups.io/api (under Pagination) it shows a correct response, however all subsequent sections (objects and the various calls that use them) show these numbers incorrectly quoted, not how they actually are presented by the API.

This is an important distinction for implementation in some languages (like using Go's json.Unmarshal).  Fixing will help any future people from running into extra work discovering the API doesn't match the docs.

Thanks!


Re: Impossible to download archives from cloudfoundry+cf-dev

Luis Cañas-Díaz
 

This is just a reminder.

Can u shed some light on this issue Mark? Our customers are waiting for their data :(

Thanks,
Luis.


Re: Impossible to download archives from cloudfoundry+cf-dev

Luis Cañas-Díaz
 

Hi again Mark,

does the test we included above (the one with curl) shed some light on the issue?


Re: Impossible to download archives from cloudfoundry+cf-dev

Luis Cañas-Díaz
 

Hi again Mark,
we've been doing several tests playing with the timeouts both with our tools and with standard tools such as 'curl'. None of them changed the result :(

Doing a test with curl for the group onap+onap-discuss:

curl "https://api.groups.io/v1/downloadarchives?group_id=19846" -u **** --output /tmp/xxx

we also get the error:

 

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  234M    0  234M    0     0   796k      0 --:--:--  0:05:01 --:--:--  588k
curl: (18) transfer closed with outstanding read data remaining

 


Re: Impossible to download archives from cloudfoundry+cf-dev

Luis Cañas-Díaz
 

We are having a look during today/tomorrow. Thanks for the info!


Re: Impossible to download archives from cloudfoundry+cf-dev

 

On Fri, Feb 15, 2019 at 3:51 AM Luis Cañas-Díaz <lcanas@...> wrote:

we are seeing this error with the following groups during the past week:

They are consistent and the last time I saw them was 5 minutes ago with a local test I just did with the group cloudfoundry+cf-dev

I checked one of the errors, and it was 'upstream prematurely closed connection while reading'. Can you look at increasing your network timeouts?

Thanks,
Mark