New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cannot clone testcase #695

Closed
radiateboy opened this Issue Jan 7, 2019 · 7 comments

Comments

Projects
None yet
3 participants
@radiateboy
Copy link

radiateboy commented Jan 7, 2019

Steps to Reproduce

  1. open case
  2. click clone button
  3. filter plan , don't choose plan
    20190107181407
    20190107181429
@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 7, 2019

filter plan , don't choose plan

Well you've got to select a TestPlan in which the TestCase will be cloned. You've got an error message telling you that this field is required.

However I'm able to reproduce a problem in which when you press Filter the results are shown on a different screen.

I can reproduce on the demo website but not locally with master. I'm leaving this open for now to re-test with the new version which will be released very soon.

@asankov

This comment has been minimized.

Copy link
Member

asankov commented Jan 7, 2019

Will start to work on this once #683 is merged

@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 7, 2019

Will start to work on this once #683 is merged

Stop working on #683 for now. I was able to reproduce locally with master:

  1. Open a stand alone TestCase (e.g. not from a test plan) or edit the URL and remove the ?from_plan=xxx parameter
  2. Click CLONE
  3. Then click Filter to filter the existing test plans in which to clone the new TC

Results:
A blank page shows with a list of test plans.

Expected:
The list of filtered plans should be shown in the same page below the filtering form so that a new plan can be selected and the clone operation can proceed.

Additional info:
This is not reproducing when the ?from_plan=xx parameter is present.

@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 7, 2019

@radiateboy see the steps to reproduce above. Based on that you can workaround the problem by opening the test cases you want to clone from their test plan.

@asankov

This comment has been minimized.

Copy link
Member

asankov commented Jan 7, 2019

I am able to reproduce this both locally and on the demo.
Just an initial heads up - as far as I can see there is some kind of jQuery problem.
In testcase_actions.js we have the following code:

jQ('#id_form_search_plan').bind('submit', function(e) {
    e.stopPropagation();
    e.preventDefault();

    var url = '/plans/';
    var container = jQ('#id_plan_container');
    container.show();

    jQ.ajax({
      'url': url,
      'type': 'GET',
      'data': jQ(this).serialize(),
      'success': function (data, textStatus, jqXHR) {
        container.html(data);
      }
    });
  });

id_form_search_plan is the id of the test plan search form. When I have loaded the case with a product, everything is working fine and the following code is executed when the form is submitted. When the case is loaded separatelly however we don't get here and instead directly do a GET request and visualise the result.

For now, I have no idea why this is happening and will continue investigating

@atodorov atodorov changed the title !!!cannot clone testcase cannot clone testcase Jan 7, 2019

@atodorov

This comment has been minimized.

Copy link
Member

atodorov commented Jan 7, 2019

@asankov see what binds this to the form. Maybe in one of the cases that is simply not initialized.

@asankov

This comment has been minimized.

Copy link
Member

asankov commented Jan 8, 2019

@atodorov you were right. in the case we have are missing from_plan the jQuery binder is never called. why is that, here is my explanation:
this is the javascript we are executing when the page is loaded

$('#id_product').change(update_version_select_from_product);
if (!$('#id_version').val().length) {
    update_version_select_from_product();
}

jQ('#id_form_search_plan').bind('submit', function(e) {
  // logic we need for the form to work as expected
});

update_version_select_from_product gets the product and based on it, loads the product versions. after that it populates the select with the given versions and calls $(selector).selectpicker('refresh') However, the last line throws an error as bootstrap-select is never imported.

The valid question here is: Why does this work when we have a product? The answer is:
loading the product versions is achieved by an an asynchronous JSON-RPC call that takes time. while we wait for the call to happen we continue to run the main js file and therefore the logic we need for the form to work is executed. thus the code is executed in the following order:

$('#id_product').change(update_version_select_from_product);
if (!$('#id_version').val().length) {
    //asynchronous code
    jsonRPC('Version.filter', {product: product_id}, updateVersionSelectCallback);
}

jQ('#id_form_search_plan').bind('submit', function(e) {
  // logic we need for the form to work as expected
});

// more code

// here somewhere the asynchronous code is executed
function updateVersionSelectCallback(products) {
  // code
  $(selector).selectpicker('refresh'); // -> error. nothing more is executed
}

when product is missing however, we don't do an aynschronous call, and load empty versions. therefore the code is executed in another order:

$('#id_product').change(update_version_select_from_product);
if (!$('#id_version').val().length) {
    //synchronous code
    updateVersionSelectCallback([])
}

function updateVersionSelectCallback(products){
    //code
     $(selector).selectpicker('refresh'); // -> error. nothing more is executed
}

// none of this is executed
jQ('#id_form_search_plan').bind('submit', function(e) {
  // logic we need for the form to work as expected
});
}

This is easily fixed by importing bootstrap-select in the template. However, then arises another problem. This breaks the layout badly. It looks like this:
screenshot 2019-01-08 at 22 54 52
screenshot 2019-01-08 at 23 01 55

I suppose that bootstrap-switch and templates with Django form field, e.g. {{ search_form.version }} are not compatible and in order for this to work, we need to refactor the tempate to Patternfly where we don't use Django form fields, or remove the bootstrap-switch.

until then, the easiest and dirtiest workaround would be to place the sometimes failing code at the bottom of the js file:

jQ('#id_form_search_plan').bind('submit', function(e) {
    e.stopPropagation();
    e.preventDefault();

    var url = '/plans/';
    var container = jQ('#id_plan_container');
    container.show();

    jQ.ajax({
      'url': url,
      'type': 'GET',
      'data': jQ(this).serialize(),
      'success': function (data, textStatus, jqXHR) {
        container.html(data);
      }
    });
  });

// more code

  $('#id_product').change(update_version_select_from_product);
    if (!$('#id_version').val().length) {
        update_version_select_from_product();
    }

the boostrap-switch call would still fail, but the template will work, and we will refactor it anyway someday

asankov added a commit to asankov/Kiwi that referenced this issue Jan 10, 2019

Move failing js to bottom of the file. Fixeskiwitcms#695
A temporary workaround until this template is refactored
into Patternfly, when bootstrap-switch can be used,
and the following js code will work

asankov added a commit to asankov/Kiwi that referenced this issue Jan 10, 2019

Move failing js to bottom of the file. Fixes kiwitcms#695
A temporary workaround until this template is refactored
into Patternfly, when bootstrap-switch can be used,
and the following js code will work

asankov added a commit to asankov/Kiwi that referenced this issue Jan 11, 2019

Surround selectpicker call with try-catch. Fixes kiwitcms#695
A temporary workaround until templates/case/clone.html is refactored into Patternfly when bootstrap-select can be imported and used

@atodorov atodorov closed this in 0f4eb11 Jan 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment