Forum OpenACS Development: group adding toggeling code

I have (in three different applications) the need for executing code once a member is added to a group. The way to do this consistently for me is to add a callback to group::add_member as this is the procedure which is called from the various places in openacs.

This does not find the approval of some OCT members, at least not without discussion, so here it is:

I want a callback added to group::add_member to be able to execute code when a user is added to a group, regardless if this is done by using community join in .LRN, adding to a group in acs-admin interface, doing it upon signup.

The callback needs to have person_id, group_id as parameters (at least in my szenarios), though I could imagine that having the member_state to see if the person was maybe added as an admin could be useful as well.

As callbacks so far are not on the to TIP list, I think adding it does not require a TIP, but lets have a discussion.

Aha, wait.

I was not awake.

I see that you want to always run this custom code. That does seem to be what a callback was designed for.

One thing you might have to do is go through and see what places members are added that don't use group::add_member and figure out if they can be changed.Otherwise your callback will not be consistent if another method is used to add a member.

I think passing member_state to the callback makes sense.

Malte ...

"As callbacks so far are not on the to TIP list, I think adding it does not require a TIP"

Your attitude towards TIPs seems to be a very narrow, legal-minded one. "If it's not explicitly there, I don't need to TIP".

You need to think about WHY we TIP. We TIP to make sure that important issues are discussed openly by the leadership team, that changes are reported to people via the TIP forum, etc.

TIPs are an important COMMUNICATION TOOL. I wish you'd quit trying to find reasons NOT to TIP by trying to read that process in a most narrow-minded way possible.

We should probably rewrite the TIP process to make the addition of callbacks to core a mandatory TIP item, but, really, a callback DOES change core behavior. C'mon. Be reasonable.

If there's any doubt about whether or not something should be TIP'd - TIP!!!!

One first thing I'd probably suggest if you were to TIP is that we think about making this consistent for all datatypes dealing with parties.

In other words do it for relsegs, not just groups. We have one for new users, right? Let's be systematic and figure out where to add them and let's name them systematically, too.

Tom:

Our callback mechanism works well. Doing it in Tcl means we often can write db-independent code, while db triggers of course must be replicated in oracle and PG. We won't be adopting your query rewriter in ACS core AFAIK.

Apparently we have a fundamentally different approach to callbacks. My goal is to keep the callback as narrowly applicable as needed, not to invite side effects by applications that might be unforeseeable.

But taking your suggestion, you would like to have callback in relation_add with object_id_one, object_id_two, rel_type and member_state.