[OPENAM-12092] Prettyprint for Amster should be a switch Created: 15/Nov/17  Updated: 25/Apr/18  Resolved: 26/Mar/18

Status: Resolved
Project: OpenAM
Component/s: Amster
Affects Version/s: 14.5.0
Fix Version/s: 6.0.0

Type: Bug Priority: Major
Reporter: Philip Anderson Assignee: Sean ONeill [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: AME, Must-Fix, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Target Version/s:
Needs backport:
Needs QA verification:
Functional tests:
Are the reproduction steps defined?:
Yes and I used the same an in the description


Bug description

OPENAM-10641 introduced pretty print for amster output, We should add a switch so that pretty print is optional

PrettyPrint being used as default  had the unfortunate side-affect of breaking the steps we publish for how to update property values (see https://backstage.forgerock.com/knowledge/kb/article/a73487721

Previously customers would:

  1. Do a read
  2. copy the output and change the property value needed
  3. remove the _rev and _id
  4. do an update using that amended output as the body
Expected behaviour

Step 4 passes and the property is updated

Current behaviour

The update step fails because of the line endings introduced by prettyprint. 

Work around

Remove the line breaks for example, using sed or an online tool  (this has been added to the KB)

It would be great if we could provide better instructions than "use sed" perhaps there is a way to override the DefaultPrettyPrinter used by CrestCommandSupport.groovy? 



Comment by Sean ONeill [X] (Inactive) [ 20/Mar/18 ]

I think this might be a candidate for must fix as it effects the Amster config story. It was previously not pretty print but that was changed to default to pretty print, breaking some config diffs. It would be good to have the option.

Comment by Andrew Vinall [ 23/Mar/18 ]

Bug Triage: Enable a switch for upgrades not to be prettyprint and for fresh installs to be prettyprint

Generated at Sat Oct 24 00:35:56 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.