Project

General

Profile

Actions

Bug #18420

closed

saving imported techniques with unknown GM fails with no error prompt

Added by Gaëtan POBLON about 4 years ago. Updated almost 4 years ago.

Status:
Released
Priority:
3
Category:
Web - Technique editor
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
To do
Fix check:
Checked
Regression:

Description

Trying with a 6.2 centos8 build (updated from 6.1), importing a json technique works but the save button does not save the technique plus no error is prompted to the user

Reproduce:

- export a technique,
- change it' name/bundle name,
- change a gneeric method name so that it's a name that doesn't exist
- import.

We need to be MUCH more resilient to such error.


Files

clipboard-202011201908-dvpkk.png (252 KB) clipboard-202011201908-dvpkk.png François ARMAND, 2020-11-20 19:08
Actions #1

Updated by Gaëtan POBLON about 4 years ago

it appears the technique was legitimately erroing wince the name of a generic method was different. No error was prompted though.

Actions #2

Updated by Gaëtan POBLON about 4 years ago

looks like it creates another issue:
Even in case of errors the Technique Editor seems to occasionally create a technique_name folder that only contains the technique.cf file (and rudder report), making impossible to save a technique with thie same name afterwards. And because it has no .json, it doesnt appear in the techniques list

Actions #3

Updated by Vincent MEMBRÉ about 4 years ago

  • Target version changed from 6.2.0~beta1 to 6.2.0~rc1
Actions #4

Updated by François ARMAND about 4 years ago

  • Priority changed from N/A to 1 (highest)
Actions #5

Updated by François ARMAND about 4 years ago

  • Status changed from New to In progress
  • Assignee changed from Raphael GAUTHIER to François ARMAND
Actions #6

Updated by François ARMAND about 4 years ago

Doing import of a bad gm, I have hundreds of errors like:

Actions #7

Updated by François ARMAND about 4 years ago

  • Priority changed from 1 (highest) to 3
Actions #8

Updated by François ARMAND about 4 years ago

The use case is not that standard, I won't mark it as blocking for 6.2 - especially if the problem is oldert than that and should be correted in 6.1

Actions #9

Updated by François ARMAND about 4 years ago

  • Assignee deleted (François ARMAND)
Actions #10

Updated by François ARMAND about 4 years ago

  • Status changed from In progress to New
Actions #11

Updated by Elaad FURREEDAN about 4 years ago

  • Status changed from New to In progress
  • Assignee set to Elaad FURREEDAN
Actions #12

Updated by Vincent MEMBRÉ about 4 years ago

  • Target version changed from 6.2.0~rc1 to 6.2.0
Actions #13

Updated by Elaad FURREEDAN about 4 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Elaad FURREEDAN to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder/pull/3431
Actions #14

Updated by Vincent MEMBRÉ about 4 years ago

  • Target version changed from 6.2.0 to 6.2.1
Actions #15

Updated by Anonymous almost 4 years ago

  • Status changed from Pending technical review to Pending release
Actions #16

Updated by François ARMAND almost 4 years ago

  • Fix check changed from To do to Checked
Actions #17

Updated by Vincent MEMBRÉ almost 4 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 6.2.1 which was released today.

Actions

Also available in: Atom PDF