Adalennis opened a new issue, #9199:
URL: https://github.com/apache/hop/issues/9199
### Apache Hop version?
SNAPSHOT-20261021
### Java version?
Java 21
### Operating system
macOS
### What happened?
Found while documenting the result of these actions (#8970, PR #9197). Each
point was tested with hop-run and re-checked on today's main.
**1. Send SNMP trap: Target type "User (SNMP V3)" is lost when the workflow
is loaded**
The dialog calls `setTargettype(wTargetType.getText())`, which turns the
description into the code, and the workflow is saved with
`<targettype>user</targettype>`. When the workflow is loaded, the metadata
serializer calls the same setter with the code:
public void setTargettype(String targettypein) {
this.targettype = getTargetTypeCode(targettypein); //
ActionSNMPTrap.java line 243
and getTargetTypeCode() only recognizes the description
(`tt.equals(targetTypeDesc[1])`, line 147), so "user" becomes "community". A
workflow run from its file (hop-run, or after reopening it in Hop GUI) always
sends an SNMP V1 trap with the community string; User, Passphrase and Engine ID
are never used. A test UDP listener received the same V1 packet ("public") for
target type community and user. This dates from the XML cleanup in afdd386d28
(#1992).
Expected: the setter (or the serializer) accepts the code, so a saved User
target stays SNMP V3.
**2. Delete execution information: success and failure hops are never
followed**
ActionDeleteExecutionInfo doesn't override isEvaluation(), so it inherits
`false` from ActionBase (line 464). Workflow.isHopFollowed() (line 1128) only
follows a non-unconditional hop when `actionMeta.isEvaluation()` is true. With
"Delete all executions in this location" on a File location holding 2 runs:
TESTED - Deleted 2 execution(s) from location 'files'.
Finished action [TESTED] (result=[true])
Workflow execution finished
and the action behind the success hop doesn't run. The same happens with a
failure hop when the action is false. Only an unconditional hop works (the
result and Lines deleted are passed on correctly).
Expected: override isEvaluation() to return true, as was done for another
action in #3741 / PR #3741, so the success and failure hops work.
**3. Set password encoder: an Encoder plugin ID that doesn't exist gives
true**
With Encoder plugin ID `Nope`:
General - ERROR: Unable to find two-way password encoder plugin with ID
'Nope'
TESTED - Two-way password encoder initialized with plugin ID 'Nope'
(process-global)
and the action is true with 0 errors. Encr.init() (lines 80-84) only logs
the missing plugin and falls back to HopTwoWayPasswordEncoder, so the workflow
goes on with the Hop encoder, while HOP_PASSWORD_ENCODER_PLUGIN is set to
`Nope`. A typo in the ID (for example `AES 2`) silently disables AES.
Expected: the action fails when the plugin ID is unknown (Encr.init could
throw, or the action could check the plugin registry first).
The current behaviour of the three actions is documented on their pages (PR
#9197), so the docs need an update when they are fixed.
### Issue Priority
Priority: 3
### Issue Component
Component: Hop Gui
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]