problem with formular and value submitting...

[AndySilvia]

Hi!

I've the problem with a formular, that the value of a formular-based field doesn't come through. Here the details: Formular (for testing if printer is present) "printer_check" Content of the step-file printercheck.yml:

---

formulars:

• name: printercheck label: Check printer fields:
  • name: name type: text label: Printer Name primary: true options:
    • autofocus buttons: next_formular: text: Finish last_formular: text: Back

The corresponding job hast on step, here the coding of the task:

desc "Check printer via formular"; task "check_printerform", sub { my $fcmdb = get cmdb "printercheck"; my $printer = $fcmdb->{name}; $printer = "" unless defined $printer; if ( $printer eq "" ) { say "No Printername commited..."; exit; } my $server = connection->server; say "Checking Printer ".$printer." on Server ".$server; my @output1 = run "/usr/bin/lpstat -v ".$printer; say map { "\t$\n" } @output1; my @output2 = run "/usr/bin/lpq -P".$printer; say map { "\t$_\n" } @output2; };

When I execute the forumar and entering some value for the printer-name, there is no error, here the Log output:

[2015-06-18 16:08:39] INFO - Running task check_printer_form on server1 [2015-06-18 16:08:39] INFO - Connecting to server1:22 (root) [2015-06-18 16:08:40] INFO - Connected and authenticated to server1 [2015-06-18 16:08:40] INFO - Successfully authenticated on server1. No Printername commited... [2015-06-18 16:08:42] INFO - Exiting Rex... [2015-06-18 16:08:42] INFO - Cleaning up...

I'm sure, that this forumar was functional some time ago, as far as I can remember the only thing I changed was one update of Rex via cpanm...

An older Log output (with the same value submitted for printer-name):

[2015-05-08 12:25:33] INFO - Running task check_printer_form on server1 [2015-05-08 12:25:33] INFO - Connecting to server1:22 (root) [2015-05-08 12:25:34] INFO - Connected and authenticated to server1. [2015-05-08 12:25:34] INFO - Successfully authenticated on server1. Checking Printer stbp on Server server1 device for stbp: lpd://stbp/raw

stbp is ready
no entries

Something changed in the last release?

Thanks in advance for your help...

Bye,

AndySilvia

[AndySilvia]

One more info on this: in the access.log I could find these lines during forumlar execution:

[Thu Jun 18 16:08:34 2015] [debug] $VAR1 = { 'printercheck' => { 'name' => 'stbp' } };

So this looks rather good....

So am I doing something wrong?

Thanks & Bye,

AndySilvia

[AndySilvia]

Continued testing and added the lines say Dumper($fcmdb); say Dumper($printer); right after my $fcmdb = get cmdb "printercheck"; my $printer = $fcmdb->{name};

Log-output now looks like this:

[2015-06-19 10:04:45] INFO - Running task check_printer_form on server1 [2015-06-19 10:04:45] INFO - Connecting to server1:22 (root) [2015-06-19 10:04:45] INFO - Connected and authenticated to server1. [2015-06-19 10:04:45] INFO - Successfully authenticated on server1. $VAR1 = {};

$VAR1 = undef;

No Printername commited... [2015-06-19 10:04:48] INFO - Exiting Rex... [2015-06-19 10:04:48] INFO - Cleaning up...

...?!...

[krimdomu]

Hi, thanks for the report. I'm going to take a look at it.

[AndySilvia]

Please take a look at CLI.pm - the change "added option to overwrite cmdb path" made on 2014-09-06 (https://github.com/RexOps/Rex/commit/83b6e8b0aa258504cbc658c321b03d59dbdbd7d0) added a line:

O => { type => "string" },

This one is now missing. If I readd it as in the change, formulars are working again with submitted values...

Bye,

AndySilvia

[ferki]

Well, it was me :) I removed it because it was an undocumented CLI option, which was also not handled where all the other options were.

@krimdomu: it can be fixed by reverting RexOps/Rex@ae1597a plus adding it to the help screen at least.

@AndySilvia: sorry for the inconvenience, and thanks for the report!

[krimdomu]

@AndySilvia @ferki thanks for the investigation on this bug. This seemed to slipped through the review.

[ferki]

@AndySilvia: the fix for this is now merge into the master branch of Rex - I'm reviewing lots of different changesets currently, so I'm not sure yet if there will be a bugfixing 1.3.3, or a bigger 1.4.0 relase yet, but this should be included in the next Rex release again.

Thanks for reporting and sorry for the inconvenience.