Previous URL as GET parameter wrongfully encoded

Hi,

I'm a bit new to Drupal (and Open Atrium of course) and working on a complex project that I didn't design myself (just maintaining it), so I may have trouble explaining the problem, bear with me !

I don't know if the source of the bug I encountered is Open Atrium itself or if it's because I have other modules built on top of it.

Anyway, when I go to an oa_space with a user that can administer that oa_space, I have a "Member administration" menu. I can filter members, or browse through pages of members. Whenever I do, this adds GET parameters to my URL.
Example : /group/node/7/admin/people?state=1&uid=&page=1

Then, when I click on the "edit" link to edit a membership, I get to a new page, with a new URL.
Example : /group/node/7/admin/people/edit-membership/92
And this URL has a new GET parameter wich (should) stores my previous URL like this :
Example : ?destination=group/node/7/admin/people%3Fstate%3D1%26uid%3D%26page%3D1

In this GET parameter, the special characters "?", "=" and "&" of the previous URL are encoded respectively as "%3F", "%3D" and "%26". But actually, the GET parameter I was getting (before patching) was :
Example : ?destination=group/node/7/admin/people%3Fstate%3D176uid%3D76page%3D1

I went into the code and found out that something wrong happened in the file
/openatrium/modules/contrib/views/handler/views_handler_field.inc

//Line ~1340
//This first command creates the GET parameters, rightfully encoding the previous URL
$options['query'] = drupal_http_build_query($alter['query']);
//This second command converts aliasses such as %1 or !1 into the arg(1) of my URL (i.e. "node" in my example) or %2 and !2 into the arg(2) of my URL (i.e. "7" in my example)
$options['query'] = strtr($options['query'], $tokens);

Result : the first command encodes & into %26 and the second %26 into 76 wich kinda prevents the application from behaving right : redirecting me to my previous URL after editing the membership (with all GET parameters re-created).

The patch I came up with, wich seemed to me, at the time, like the best solution, was to modify the function get_render_tokens (still in views_handler_field.inc around line 1390).

function get_render_tokens($item) {
    $tokens = array();
    if (!empty($this->view->build_info['substitutions'])) {
      $tokens = $this->view->build_info['substitutions'];
    }
    $count = 0;
    /*PATCH START. 
      * This allows for GET parameters containing encoded URL to keep their special characters (? & =) well encoded
      */
    $tokens['%3D'] = '%3D';
    $tokens['%3F'] = '%3F';
    $tokens['%26'] = '%26';
    // PATCH END
    [...]

Of course, since the GET parameter was messed up, when being redirected to the meber administration, I was getting only one get parameter wich translated to : $_GET['state'] = "176uid=76page=1" wich was causing an "illegal choice has been detected" error since state was, obviously, not supposed to get this value.

I don't know if this is a known issue or if there are other patches for this out there (I had no luck searching for this issue since I kinda didn't know what I should search for ! )
Anyway, this patch works and I can't picture cases (or only very twisted ones) in wich it could do harm to an application although I'm pretty sure there should be better solutions to this issue.

Regards.