Project

General

Profile

Actions
Copy link

Bug #8687

closed

Inconsistent directive API parameters at creation

Bug #8687: Inconsistent directive API parameters at creation

Added by Alexis Mousset about 10 years ago. Updated almost 10 years ago.

Status:
Released
Priority:
N/A
Assignee:
François ARMAND
Category:
API
Target version:
2.11.23
Pull Request:
https://github.com/Normation/rudder/p...
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

In the directive API:

  • the priority attribute in exported, can be modified, but cannot be provided at creation
  • the isSystem attribute in exported, can be modified, but cannot be provided at creation
  • The isEnabled attribute is called enabled at creation

Subtasks 4 (0 open — 4 closed)

Bug #8715: Migrate 'api_compatibility_mode' so it's enable on migrationReleasedAlexis MoussetActions
Bug #8716: Remove 'isxxx' and add priority in Directive from api docReleasedFrançois ARMANDActions
Bug #8768: Style of title Api backward compatibility in Settings is invalidReleasedVincent MEMBRÉActions
Bug #8780: Test broken since we added a new entry in bootstrap.ldif ...ReleasedBenoît PECCATTEActions

Updated by Alexis Mousset about 10 years ago Actions
Copy link
 #1

  • Subject changed from Inconsistent API parameters to Inconsistent directive API parameters at creation

Updated by François ARMAND almost 10 years ago Actions
Copy link
 #2

We need to ensure that POST (GET url_api) works.
For that case, we need to:

- just add the missing priority parameter,
- remove from documentation the "isXXX" to only keep "XXX" variant,
- keep aliases in code to node break existing script, marking "isXXX" variant deprecated,
- remove in next major API the old "isXXX" values.

Updated by Vincent MEMBRÉ almost 10 years ago Actions
Copy link
 #3

Priority works, it just not documented.

We do not accept "isXXX" as parameter, but always "XXX". But we always answer "isXXX"

Updated by Vincent MEMBRÉ almost 10 years ago Actions
Copy link
 #4

I don't think "system" should be set/modified

Updated by Vincent MEMBRÉ almost 10 years ago Actions
Copy link
 #5

  • Assignee set to Vincent MEMBRÉ
  • Target version set to 2.11.23

We will:

  • Document priority in directive creation (another issue)
  • Always send 'xxx' instead of 'isxxx"
  • Define a new property 'api compatibility' that is 'disabled' on new install, 'enabled' on migration which allows:
    • If "enabled", api will also send "isxxx" in response, which will allow compatibility with old script treating the "isxxx -> xxx" case
  • Deprecate all current API in master, so we can create a new one only snedinf 'xxx'
  • Remove all deprecated API and the property in master+1

Updated by Vincent MEMBRÉ almost 10 years ago Actions
Copy link
 #6

  • Status changed from New to In progress

Updated by Vincent MEMBRÉ almost 10 years ago Actions
Copy link
 #7

  • Status changed from In progress to Pending technical review
  • Assignee changed from Vincent MEMBRÉ to François ARMAND
  • Pull Request set to https://github.com/Normation/rudder/pull/1136

Updated by Benoît PECCATTE almost 10 years ago Actions
Copy link
 #8

If you do not accept system, you break the "export then import" workflow, which is the first use of this kind of API.

I suggest that you accept the "system" attribute and return an error if it is true.

Updated by Vincent MEMBRÉ almost 10 years ago Actions
Copy link
 #9

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100

Updated by Alexis Mousset almost 10 years ago Actions
Copy link
 #10

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 2.11.23, 3.1.12 and 3.2.5 which were released today.

Actions
Copy link

Also available in: PDF Atom