Forced matrix

Hey, I'm not done yet!

Sorry if I was a little long but I will post patches here so my new module works. I'm starting now. I should have something within a few days.

Thank you for keeping this active!
Alexis

Hi bojanz,

Existing module

Okay, I'm trying to figure out how to program my system and I have a few questions about the existing module:

1) What happens if I delete a user?

At this point it looks like you do nothing at all. This means you will continue to generate commissions to that user, although it works because you never access the "users" table in that code, I would think that could look suspicious to an admin to have to pay someone he previously deleted...

This is not a trivial delete since all the affiliates below that user should probably get that user affiliate as their previous level affiliate. Hmmm... Let's give an example: User A is the affiliate of user B; and User B is the affiliate of user C. At this time, A receives commissions on sales to B and C. User B receives commissions on user C. The administrator decides to delete B. I think A should continue to receive commissions on C as if C was in his direct downline. At this point, you do not modify the uc_affiliate2_users table at all.

I know you also have "product affiliates". So I'm not too sure how much work is involved right at this point...

2) uc_order_comment_save() with wrong user?

It looks like you are adding a comment to an order with the current user (global $user; although in one case $user is not even defined.)

That probably needs to be fixed using either the order user or the affiliate (I think the latter is what was meant to be, but I may be wrong.)

3) Cumulative commissions

From what I understand, the commissions are added to each user's account by the uc_affiliate2_apply_commission() function. This happens each time there is an update on the order. I did not test yet, but my orders go from Payment Received to Completed and in both cases I tell you to add the commissions. It looks like it could very well be added twice in that case... At least, I did not see anything that would prevent that from happening.

I think that a simple solution to that problem would be to do a SELECT with the affiliate ID and order ID. If we find an entry, skip the save altogether, it was already processed.

Forced Matrix module

Otherwise, from what I can see so far, and I may have missed something, but anyway... all I would need is receive some sort of an event when the uc_affiliate2_apply_commission() function is entered. I need the Order and the Affiliate identifier. With those two parameters, from what I can tell at this point, I can force the matrix as required by my needs.

Just right now, I'm not too sure what would be best, a ca_pull_trigger() call should work since we can modify the parameters in the callback. My idea is pretty simple. The Forced Matrix module will manage its own tree and thus be capable of knowing where a new customer is to be added. If the call is not about a new customer, leave everything in place (i.e. case when the Admin edits the order.)

If the Forced Matrix module kicks in and determines that the current user is "complete," then make changes to the tables and return with a new Affiliate identifier. The order will not be modified (unless we have to change the product affiliates too, but I'm not too sure how that works right now... I may have to forfeit that feature to start with.)

More soon.
Thank you.
Alexis Wilke

Doud,

Using different roles, you will be able to allow one (free) or the other (forced) on the same website.

So, you could have two roles such as: "Affiliates" and "Forced matrix". And make people part of one or the other (the Forced matrix would have priority if you are part of both, so any product that allow for a downline would use the forced matrix.)

What is your take about Deleted users? At this point, my idea is to handle the tree as a very simple tree. Say you have users A, B, C, and D. A found B, and B found C and D. B leaves, A inherits C and D. But at that point A may have reached his limit (i.e. we can replace B with C, but D is "too much".) In that case I place D as if it were a new affiliate of A, using the same rules as you would otherwise use for new affiliates.

Would that sound like what you'd do? I guess C could be places under A as a new affiliate too and end up in place of B automatically.

Bojanz,

Yes. And I was thinking that the conditional actions could make use of additional conditions such as a minimum amount spent, the type of product, whether the product as the Recurring feature attached, etc.

Thank you.
Alexis

@Doud,

Okay, I have a starting point here:

UC Matrix

I does not do anything yet, but it has all the settings and the trigger/capture support that is necessary to transform the tree appropriately.

In regard to having it in a separate module, it probably isn't a bad idea, although new versions of the uc_affiliate2 module may break the uc_matrix module... We'll see how that works. Another way would have been for me to take the existing uc_affiliate2 as it was and not depend on this module. Just rename it uc_matrix and make that work instead.

Anyway... duplicate effort is an annoyance too. 8-)

As mentioned in an earlier post, we'll need some extra trigger. Cool thing since you could add all sorts of reasons why the trigger should not be taken in account (i.e. user not in right group, order amount too small or too large, etc.)

Bojanz,

Let me know if you see any problem with that patch. I may need to have the returned value tested to bypass the default behavior. I hope not, we'll see.

Thank you.
Alexis Wilke

Bojanz,

As I'm trying to figure out how to count things, I noticed what feels like a bug. I have to test to make sure though... 8-)

It looks like in two cases the linking between affiliate and user does not occur.

The following graph is a somewhat simplified graph showing what happens in the affiliate module. The two red lines should be followed but they are not at this point. (see attached.)

Thank you.
Alexis

bojanz,

There is only one case when you link aid and uid together. That's on a user registration (when user_save() is called and the user did not exist before.) And that happens either when you purchase something or actually register. But really only if you did not have an account on the affiliate enabled website.

Maybe if you had case 'update' as well... and add the link between aid/uid if it does not exist yet?

/**
 * Implementation of hook_user()
 */
function uc_affiliate2_user($op, &$edit, &$account, $category = NULL) {
  global $user;
  switch ($op) {
    case 'insert':
      // update user count for affiliate and associate user with affiliate
      $aff = $_SESSION['affiliate'];
      if ($aff) {
        db_query('INSERT INTO {uc_affiliate2_users} (aid, uid) VALUES (%d, %d)', $aff, $account->uid);

        $message = t('User !name referred by user id !affiliate', array('!name' => theme('username', $account),
                                                                        '!affiliate' => theme('placeholder', $aff)
                                                                        )
                     );

        watchdog('user', $message);
      }
      break;

A case that does not work going something like this:

1. User A comes to my website
2. User A becomes affiliate
3. User A put a link on his website

4. User B comes to my website
5. User B creates an account
6. User B leaves... (B is not an affiliate nor did he click any link to become one.)

7. User B finds User A website and clicks on his affiliate link
8. B is still logged on my website
9. B is never linked to A
10. B purchase something, A receives nothing

Now some people may consider that since B found the website before clicking on A's link that we owe nothing to A...

I did not have much time to look in UC Matrix lately... But the only thing left, really, is counting the number of paying children. (well... we'd have to make the Delete work properly too! Especially if a child is not considered a child anymore once he/she stops paying a recurring fee! One thing at a time, though.)

Thank you.
Alexis

bojanz,

The two "broken" cases may not be considered broken to some people since the user would have come to your website before clicking an affiliate link. However, in this case, it is not even a question of whether you have parent/child. In my example B is not an affiliate and he purchases something after he clicked on the link offered by A. A could complain that he should be assigned the commission. That would fail in all cases, with a parent/child or just a random customer.

Thank you.
Alexis

if B followed A's link, A should get a commission regardless of what B did earlier.

Try the steps in #15 and see the A does not receive the commission.

Thank you.
Alexis