Bug #6203
closedIf I create a rule, the Rules table is not correctly refreshed, and I get a neverending "loading"
Added by Nicolas CHARLES almost 10 years ago. Updated over 9 years ago.
Description
See screenshot
Step to reproduce:
Create a rule in the rule page.
Reloading the grid solves the issue
Files
Updated by François ARMAND almost 10 years ago
I can't reproduce this one nor #6198.
So either were corrected at some point by something else (but nothing obvious for that), or they depends on something else. They both seem linked to ajax timeout, so I suspect something like an error in the JS returned interpreted differently by browser, or something like network condition...
Nico, do you still get them ?
(see also #6198)
Updated by François ARMAND almost 10 years ago
So more information: it seems to happen with firefox 31, but not firefox 35.
Updated by François ARMAND almost 10 years ago
I can't reproduce it either with firefox 31.4esr.
Nico, could you check it's still here ?
Updated by François ARMAND almost 10 years ago
- Status changed from New to Discussion
- Assignee changed from François ARMAND to Nicolas CHARLES
Updated by François ARMAND almost 10 years ago
OK, I reproduced it one time.
The problem seems to be that for some reason, the POST:
ruleCompliances = {};
recentChanges = {};
recentGraphs = {};
refreshTable("grid_rules_grid_zone", [{"name": "Global configuration for all nodes", "id": "32377fd7-02fd-43d0-aab7-28460a91347b", "description": "", "applying": false, "category": "", "status": "In application", "trClass": "tooltipabletr ", "checkboxCallback": function(checked) {liftAjax.lift_ajaxHandler('F59769931248DXIP5V=' + encodeURIComponent(checked), null, null, null);}}, {"name": "Test new rule", "id": "2f706b87-4334-45ba-8f59-72675139b2f9", "description": "", "applying": false, "category": "", "status": "In application", "trClass": "tooltipabletr ", "checkboxCallback": function(checked) {liftAjax.lift_ajaxHandler('F59769931249UNCJY5=' + encodeURIComponent(checked), null, null, null);}}, {"name": "test reporting cass\u00e9", "id": "2fcbbe40-725c-4676-9432-aeac358f4a5f", "description": "", "applying": false, "category": "", "status": "In application", "trClass": "tooltipabletr ", "checkboxCallback": function(checked) {liftAjax.lift_ajaxHandler('F59769931250KDS5XN=' + encodeURIComponent(checked), null, null, null);}}]
);
liftAjax.lift_ajaxHandler("F59769931251MVSSN3=true", null, null, null);
liftAjax.lift_ajaxHandler("F59769931252N1G5GL=true", null, null, null);
Is fired two-time, and the second time, the last liftAjax.lift_ajaxHandler leads to the "server can not be contacted at this time".
So, there is two problems:
- why the post is fired two times ? At least, it's wasting resources, at worst it's the door to double-actions
- why firing that handler leads to an error ?
For the last question, it seems that the problem is that the result of the callback ask for refreshing the rule grid, but that there is no more rule grid at that point (since it's deleted).
var ruleTable = $('#'+"grid_rules_grid_zone").dataTable();
var currentPageRow = ruleTable._('tr', {"page":"current"});
var currentPageIds = $.map( currentPageRow , function(val) { return val.id});
computeChangeGraph({"x": [], "y": []},"32377fd7-02fd-43d0-aab7-28460a91347b",currentPageIds);
computeChangeGraph({"x": [], "y": []},"2f706b87-4334-45ba-8f59-72675139b2f9",currentPageIds);
computeChangeGraph({"x": [], "y": []},"2fcbbe40-725c-4676-9432-aeac358f4a5f",currentPageIds);
Updated by François ARMAND almost 10 years ago
The two last comments were for #6198.
For this one, it seems that sometimes, we don't send back all the compliance.
For example, I have two rules, and the refresh returns only one compliance:
Post 1: return of the refresh:
ruleCompliances = {};
recentChanges = {};
recentGraphs = {};
refreshTable("grid_rules_grid_zone", [{"name": "Global configuration for all nodes", "id": "32377fd7-02fd-43d0-aab7-28460a91347b", "description": "", "applying": false, "category": "", "status": "In application", "trClass": "tooltipabletr ", "callback": function(action) {liftAjax.lift_ajaxHandler('F1296830236323D5RZM0=' + encodeURIComponent(action), null, null, null);}}, {"name": "Nodes only", "id": "ff31e98b-7325-4926-a8d8-fe551d2c3be1", "description": "", "applying": false, "category": "", "status": "In application", "trClass": "tooltipabletr ", "callback": function(action) {liftAjax.lift_ajaxHandler('F1296830236324L00WGP=' + encodeURIComponent(action), null, null, null);}}, {"name": "Root only", "id": "a3a796b9-8499-4e0b-86c5-975fc5a13505", "description": "", "applying": false, "category": "", "status": "Not applied", "trClass": "tooltipabletr disabledRule ", "reasons": "Rule disabled, No policy defined", "callback": function(action) {liftAjax.lift_ajaxHandler('F1296830236325AFKG4A=' + encodeURIComponent(action), null, null, null);}}, {"name": "A new rule!", "id": "2278f76f-28d3-4326-8199-99561dd8c785", "description": "", "applying": false, "category": "", "status": "Not applied", "trClass": "tooltipabletr disabledRule ", "reasons": "Rule disabled, No policy defined, Empty groups", "callback": function(action) {liftAjax.lift_ajaxHandler('F1296830236326GIEXRV=' + encodeURIComponent(action), null, null, null);}}, {"name": "Test new rule", "id": "f300ef37-55a8-4e7f-947c-bc192599bd6d", "description": "", "applying": false, "category": "", "status": "Not applied", "trClass": "tooltipabletr disabledRule ", "reasons": "Rule disabled, No policy defined, Empty groups", "callback": function(action) {liftAjax.lift_ajaxHandler('F1296830236327IBRLLF=' + encodeURIComponent(action), null, null, null);}}]
);
liftAjax.lift_ajaxHandler("F1296830236328AUEL1W=true", null, null, null);
liftAjax.lift_ajaxHandler("F1296830236329OJ0LRE=true", null, null, null);
Post 2 (first ajax handler ?): build compliance bar: only one !!
$("#compliance-bar-32377fd7-02fd-43d0-aab7-28460a91347b").html(buildComplianceBar([0.0, 50.0, 0.0, 0.0, 0.0, 50.0, 0.0, 0.0]));
ruleCompliances['32377fd7-02fd-43d0-aab7-28460a91347b'] = [0.0, 50.0, 0.0, 0.0, 0.0, 50.0, 0.0, 0.0];
Post three: build change graphs:
var ruleTable = $('#'+"grid_rules_grid_zone").dataTable();
var currentPageRow = ruleTable._('tr', {"page":"current"});
var currentPageIds = $.map( currentPageRow , function(val) { return val.id});
computeChangeGraph({"x": [], "y": []},"2278f76f-28d3-4326-8199-99561dd8c785",currentPageIds);
computeChangeGraph({"x": [], "y": []},"a3a796b9-8499-4e0b-86c5-975fc5a13505",currentPageIds);
computeChangeGraph({"x": [], "y": []},"ff31e98b-7325-4926-a8d8-fe551d2c3be1",currentPageIds);
computeChangeGraph({"x": [], "y": []},"f300ef37-55a8-4e7f-947c-bc192599bd6d",currentPageIds);
computeChangeGraph({"x": [], "y": []},"32377fd7-02fd-43d0-aab7-28460a91347b",currentPageIds) ;
So, why only one ?
Updated by François ARMAND almost 10 years ago
- Subject changed from If I create a rule, the Rules table is not correctly refreshed, and I get a neverendinf "loading" to If I create a rule, the Rules table is not correctly refreshed, and I get a neverending "loading"
- Status changed from Discussion to In progress
- Assignee changed from Nicolas CHARLES to François ARMAND
Updated by François ARMAND almost 10 years ago
- Status changed from In progress to Discussion
- Assignee changed from François ARMAND to Nicolas CHARLES
So, the explanation is that we actually don't have any data for the corresponding rule.
Doing the scenario in slow motion:
- we are saving the rule so that it passes from a "not activate" status from an "in application" one - say we add a target to the rule
- a promise generation is started
- the page is reloaded
- rule compliance are displayed - the promises are still reloading.
So, for the new rule, it's likelly that we DON'T HAVE YET expected reports for it. So no expected reports means the little wheel is not replaced by a bar.
If it was only that, we could say that the little wheel meaning is OK - we actually are waiting for things. But in the common shared brain, it means "the browser is waiting for data" - not what we want our user to think.
Moreover, there is an other (border-edge) case to take care of:
Say we have a rule R1, applying to group G one directive whose Technique T is unique.
Say we have an other rule R2 that is also applying to group G a directive from the same Technique T, but with a higher priority.
Then for R1, there is NO expected reports at all. Because they are all overriden, and see #5329 for what was done.
So for them, the weel is not an option.
I propose the simple text "no data available" for that.
Updated by François ARMAND almost 10 years ago
- Status changed from Discussion to Pending technical review
- Assignee changed from Nicolas CHARLES to Vincent MEMBRÉ
- Pull Request set to https://github.com/Normation/rudder/pull/818
PR is here: https://github.com/Normation/rudder/pull/818
Updated by François ARMAND almost 10 years ago
- Status changed from Pending technical review to Pending release
- % Done changed from 0 to 100
Applied in changeset 54a09b8d7d9afc35c8cde494a01f18efb9356a79.
Updated by Vincent MEMBRÉ almost 10 years ago
Applied in changeset 6a9563704df0b0e5f8684e07addf710190ab6296.
Updated by Vincent MEMBRÉ over 9 years ago
- Status changed from Pending release to Released
This bug has been fixed in Rudder 3.0.0, which was released on 2015/02/16
- Announcement 3.0
- Changelog 3.0
- Download information: https://www.rudder-project.org/site/get-rudder/downloads/