Alter [everyone-pattern] before saving an activity record

Nope, everything works with one trigger, and it's been working great for the past few months. It's impractical and counter-intuitive to have multiple triggers for the same event (submission of the status update form). The only issue at hand is determining the template to use for a second message to everyone.

(Part of the reason it works is because the system treats a self-update as having two actors, it's just that they both refer to the same object.)

The attached image shows what the Activity publisher template looks like. Below are the scenarios for different events that can happen and the messages that are shown to various users.

== EVENT: User A updates his status ==
User A sees: You updated your status.
Everyone else sees: User A has a new status.

== EVENT: User A writes a message on User B's profile. ==
User A sees: You wrote a message on User B's profile.
User B sees: User A wrote a message on your profile.
Everyone else sees: User A wrote a message on User B's profile.

In terms of interaction, these may seem like slightly different events, but in terms of code, they are exactly the same.

The structure described above is how everything is currently working, and also exactly how I want it to work. There are no acrobatics required to make it happen this way; the code is straightforward except when it comes to having different templates for the Public message. My question was simply if there is a way to more easily access additional information in the hooks that Activity offers, and if there is not that's okay as well since my existing code is working.

I'm aware of the language part, I have it working for every language across multiple $ops.

If I split the trigger, where does it stop? Does there have to be a different trigger for editing and deleting too? Doesn't that seem awkward?

I will think about this a little more. Thanks for your help thus far.

No, editing and deleting are separate actions! That would certainly be ridiculous to combine them. I'm saying that I may also have to split editing and deleting statuses based on whether the status in question was posted to one's own profile or to another's profile.

I completely understand the purpose of different Triggers and Actions and how they relate to Activity. My concern is unique to FBSS in that something I thought of as one action -- submitting the status form -- could involve either one or two actors. The question at stake here is simply which method will create the most intuitive UI for users.

Let me try to be a little clearer.

The part that felt unintuitive to me was that if I as a site administrator to go the Activity templates page, I think "I'm going to add a template for when a user edits a status." It doesn't immediately occur to me that there could be two different kinds of editing a status based on where the status was posted.

On the other hand, once I go to the template creation screen and it shows me a list of triggers with descriptions, the distinction may become clear. So I'm currently leaning towards your suggestion of splitting each of the three existing triggers (status submission, status editing, and status deletion). (The result will be six triggers.)

I think I should also point out that part of the reason I opened this issue is that I think the Activity 2 API is relatively clear and useful (at the very least compared to Activity 1) so I was encouraged by this fact to explore some of the flexibility it offered. FBSS has unusual circumstances that occasionally make it necessary to stretch the limits of some APIs in ways that they weren't originally envisioned to be used, and this is simply a case where I tried to find a way to make the interface as clear to site administrators as possible at the potential expense of clarity of code.

Does it not seem ridiculous to you to duplicate functionality just to demonstrate how an API can be used? I understand how it can be used, and I've used it correctly in FBSS for months. The documentation is reasonably clear, and there are already fine examples of how the API is used within the existing Activity package. It's not even Activity's API that you're talking about, it's the Actions API in core!

Also, writing *anything* for the sole purpose of demonstrating an API is in dubious territory. Attempting to duplicate the functionality of a very powerful and stable module with thousands of hours of development work, in a way that could not possibly be maintained anywhere near as well as FBSS is, is simply absurd. It's the equivalent of me building an Activity system in FBSS just to demonstrate how statuses could be displayed. If you want to build a good example of how the Activity API should be used, write a patch for FBSS, don't waste time and effort on duplicated functionality that could never approach FBSS's flexibility anyway, please!

By the way, Mr. Reynolds, you helped a bit with the original Activity 2 integration way back in early June.

I didn't mean to imply that Activity isn't well-maintained; Activity and FBSS are used together and if Activity stopped being maintained then FBSS would suffer as well. I use Activity 2 on several sites and I like it a lot. I just meant that, as part of a larger project, it's unlikely that activity_user_status would get the same kind of focus that I can give to a dedicated project like FBSS.