Project

General

Profile

Actions
Copy link

Bug #15640

closed

Built in File Content technique does not warn about using cfengine variable syntax in file content

Added by Janos Mattyasovszky about 5 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
Nicolas CHARLES
Category:
Techniques
Target version:
5.0.19
Pull Request:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Getting started - demo | first install | Technique editor and level 1 Techniques
Effort required:
Priority:
59
Name check:
To do
Fix check:
To do
Regression:

Description

When using $(text) or ${text} as in the File content part of technique "File content version 8.0", there is no warning about escaping or not using them, otherwise you might hit issue #15167.

Please consider adding an appropriate warning label to each of the affected input fields if this is still applicable.

Suggesting it as Major because it will break the technique with no visible error and no real input that it does not work other than it does not work, and adding a visual information should be quite trivial...

Related issues 1 (0 open — 1 closed)

Related to Rudder - Bug #15167: Invalid detection of empty strings for edition in TechniquesReleasedAlexis MoussetActions
Actions
Copy link
 #1

Updated by Janos Mattyasovszky about 5 years ago

  • Related to Bug #15167: Invalid detection of empty strings for edition in Techniques added
Actions
Copy link
 #2

Updated by François ARMAND about 5 years ago

  • Target version set to 5.0.14
Actions
Copy link
 #3

Updated by Vincent MEMBRÉ about 5 years ago

  • Target version changed from 5.0.14 to 5.0.15
Actions
Copy link
 #4

Updated by François ARMAND about 5 years ago

  • Assignee set to Nicolas CHARLES
  • Priority changed from 70 to 69

Adding in the field documentation the warning is easy, and we should defenitly do that. Having a real-time warning based on the input text is not possible right now (we don't know on rudder what are the defined variables on nodes). We could rule out some inputs, thought (like "no . in the variable name").

So for now, step 1: add warning in field documentation.

Actions
Copy link
 #5

Updated by Vincent MEMBRÉ almost 5 years ago

  • Target version changed from 5.0.15 to 5.0.16
  • Priority changed from 69 to 67
Actions
Copy link
 #6

Updated by Alexis Mousset almost 5 years ago

  • Target version changed from 5.0.16 to 5.0.17
  • Priority changed from 67 to 65
Actions
Copy link
 #7

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.17 to 5.0.18
  • Priority changed from 65 to 63
Actions
Copy link
 #8

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.18 to 5.0.19
  • Priority changed from 63 to 59
Actions
Copy link
 #9

Updated by Nicolas CHARLES over 4 years ago

  • Status changed from New to In progress
Actions
Copy link
 #10

Updated by Nicolas CHARLES over 4 years ago

Only does Line replacement regular expressions fail in my test

Actions
Copy link
 #11

Updated by Nicolas CHARLES over 4 years ago

  • Status changed from In progress to Rejected

Tested on 5.0.17: agent can insert any variable ${} , delete using ${}, replace using ${} without any escaping

I'm rejecting it, feel free to reopen it if you have a use case where it fails

Actions
Copy link

Also available in: Atom PDF