I have only one relationship type 'Friend' and Request expires in: is set to '1' days
http://www.example.com/admin/user/relationships/1/edit

I sent a request and 26 hours later the request has still not expired.
I have flushed cache, ran cron and ran updates.

This feature use to work in 6.x-1.0-rc2. Has there been a change that stopped 'expiring of the request' from working?

Comments

alex.k’s picture

I can't recall any changes to the expiration code. Since 26 hours is pretty close to 24, can you wait a bit more and make sure it really doesn't get cancelled? If you can try another increment e.g. 3 days that would be helpful as well. Thanks.

rburgundy’s picture

Hello alex.k,

Thanks for your response. After 35 hours the request was not cancelled. I have manually cancelled and resent the request for testing to see if the request gets cancelled in the next 24~30+ hours.

This feature is crucial for the website I am trying to make (for the request to expire after a day..but doesnt have to be exactly 24 hours. 25, 26, 27 hours is all good) and will do any testing required to get this to work.

Kindest Regards

rburgundy’s picture

I have a question for testing purposes (to have the expiration occur earlier and provide quicker feedback)
Will '0.5' work in the setting for expire in half a day? and smaller decimal number for expire in 1 hour?
Thanks

rburgundy’s picture

sorry nevermind #3, decimal numbers seems to not work in the Expire in: input box.

Th expiring of the request did not work again on 2nd testing =(
I see the unix timestamp in myphpadmin in user_relationships 'created_at' and 'updated_at' and the current time has passed the time in these values. I have flushed cache, ran cron and ran updates again without any luck.

Can this be looked into when you have time?
Thank you very much!

robby.smith’s picture

subscribing

rburgundy’s picture

Hello alex.k,

I've been testing on 10 different clean drupal installs with user relationship rc3 as the only contrib module and expire in: 1 day (tested), 2 day (tested), 3 day (waiting for expire time)

What I noticed so far:
The expiring of the request works ONCE but then never again on the same site for ALL installs. This seems to be the case on the first test site I was using. I first thought it may be due to a module clash, but I confirmed it was not with the results of ALL the clean installs I tested with the past several days.

On two of the drupal installs:
I changed the unix timestamp of the Request via phpmyadmin (with expire in 1 day setting the timestamp to 2 days back / with expire in 3 days setting the timestamp to 4 days back) Same as in the other tests (where I just waited for the expire time to come), the request expired the first time, but all requests afterwards that I tried to expire by changing the timestamp did NOT expire.

I hope this information helps you in getting to the root of this problem.
I would really appreciate your help with this issue!

Please let me know if I can provide anymore information that will help.

rburgundy’s picture

Did a little more investigating..

Result: Only the FIRST request sent on the site expires. Request from 2nd~ never expire.

Steps to replicate:
1) Install Drupal 6.15 with User Relationships rc3 and setup permissions
2) Create two new users (user1, user2)
3) Send request to user1
4) Send request to user2 [now the pending page shows user1 and user2 shown)
5) Change created_at and updated_at timestamp in user_relationships table via phpmyadmin
6) Run Cron
7) Only user2 is shown on the pending page [request to user1 expired successfully, user2 never expired]

I hope this is a minor bug that can be fixed easily =)
Please let me know if any further details are necessary.

I look forward to your reply.

Bilmar’s picture

subscribing - I'm also experiencing problems with requests not expiring.
(I'm coming from http://drupal.org/node/468764)
Thanks very much in advance

Bilmar’s picture

I tried to change the following code in user_relationships_api.module ...

  // only expire relationships once a day
  $last_cron = variable_get('user_relationships_last_expire', 0);
  if ($now < $last_cron + 86400) {
    return FALSE;
  }

To the below code (taking out the "+ 86400") to try to have the expiring of request happen whenever cron is run for testing purposes with changing the timestamp with phpmyadmin.

  // only expire relationships once a day
  $last_cron = variable_get('user_relationships_last_expire', 0);
  if ($now < $last_cron) {
    return FALSE;
  }

This made no difference and I still cannot get requests to expire. Also I did many tests by just waiting several days to pass. Maybe this is a bug allowing only request id rid=1 to expire as I am seeing that above 1 not expiring? All my tests have been on a vanilla install of Drupal 6.15 with User Relationships rc3.

@alex.k - could you please look into this issue when you have the chance? Your help would be very much appreciated.
Very awesome module!

YK85’s picture

subscribing

rburgundy’s picture

I am a web designer and don't know programming, but thought from comment #9 that if rid 1 is the only one ever being expired, the problem may be in the code to delete the expired rid? Can anyone tell if there is something wrong with this code in user_relationships_api.module?

$expired_requests = array();
  while ($request = db_fetch_object($result)) {
    $expired_requests[$request->rid] = $request;
  }

  if ($expired_requests) {
    db_query('DELETE FROM {user_relationships} WHERE rid IN ('. db_placeholders($expired_requests) .')', $expired_requests);
    _user_relationships_invoke('delete', $expired_requests);
  }

Many thanks!

alex.k’s picture

Assigned: Unassigned » alex.k

Committed a possible fix, http://drupal.org/cvs?commit=318556, please update and try it out.

Bilmar’s picture

Status: Active » Fixed

hello Alex,

I manually patched the module with the changes you committed just now and confirmed that it works!
Thank you very much for looking into this issue.

rburgundy’s picture

I have confirmed that all requires are expiring as well.
Many thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.