UPDATE function not updating groups

Matt Smith:

Did you find an answer to this problem? I seem to be having a similar issue.

There are some limitations to adding to groups: "Only available when called using an administrator account. Cannot be used for pre-defined groups (those with IDs less than 1000). Cannot be used for administrator security groups." Do these explain what you're seeing?

Matthew Andrade:

I'm having the same problem and Jeff no I don't get what your saying sorry.

I am trying to use the CREATE method to add people to groups and not getting it to work that way. It works adding them to the interest group.

The first of those limitations is most likely to be your problem: " Only available when called using an administrator account." It means that users cannot add themselves to any group they want to; only an administrator can add a user to a group. Generally, this means that it can only be done from what we call a "server-side" API call, one that comes from a 3rd party's server (rather than directly from the user's browser) and which requires special administrative user's log-in credentials. But it is possible to be called from the client side (browser) if it is being used by a logged-in Convio administrator; this is an unlikely scenario but possible if you were building a custom form for your Convio admin's.

We realize that in realistic use cases you are hard-coding group IDs in the form and not really giving the user an opportunity to choose to join a group that they shouldn't be in (or letting them choose from an appropriate list), but if the API allows it then there is the potential for abuse. An unscrupulous and technical person could use this, simply iterating through group ID numbers, to add themself to as many groups as possible and then perhaps receive benefits or communications they are not entitle to. So we decided it prudent to guard against this possibility.

Matthew Andrade:

Jeff,

Quick question. I understand now why we cannot allow the form to update or add emails to a group, but why then if we hard code an interest id number into the form that interst group gets filled with new contacts. If that is the case then we can just continue updating the interests group then run a query to populate a specified group.

Does that make any sense???? or am i a little confused here.

Thanks!

There isn't necessarily a problem with users being added to groups via APIs generally, but the problem I described earlier is with the potential for users to arbitrarily choose which groups to be put into. Regarding interest opt-in and opt-out groups, which are by definition a collection of users who specified a certain interest, it is perfectly appropriate for users to self-select their membership. Another example of this can be found in donations, wherein donation forms can have groups associated and anyone who donates with that form is added to a group; if a user donates using a form that uses the donations API then they are added to that group automatically. In these cases, the groups into which the users can get added via the APIs is very limited and controlled.

So I don't think you're confused -- it sounds like you found a good solution to being able to group the contacts who use your API-powered form.

Robert Zakon:

I'm encountering a similar (same?) issue...

I'm using the server API to update a (non-admin) constituent's record to add_group_ids > 1000. I get back an XML message that "user updated", however in checking C360, the constituent is not in the group. In case it matters, this is a new group with no other constituents as of yet.

Any ideas?

Disregard last post; issue resolved.