Closed kschmiechen closed 2 months ago
In the meantime, I have implemented my hook with the following setting structure
settingId.Playground.*.draft=field1.something, field2.somethingElse
So this enhancement has low prio for me.
Hello Kevin, Could you please give an example when the functionality like this must be useful? Is there some cases when you do not know the full final setting name you need so you have to read all similar / starting from some prefix? And then? Loop through them or something?
I have a hook (I'll publish it once the interceptor manager is officially published) that synchronized work item hyperlinks in richtext and table fields to the linked work items section.
The original structure for the settings was:
settingId.projectId.workItemTypeId.statusId.fieldId.columnId.targetProjectId.targetWorkItemTypeId=linkRoleId
I wanted to get all settings (multiple, because I have cases where I need to configure more than one linking type per work item) for settingId.projectId.workItemTypeId.statusId
and then have a map with entries looking like this:
fieldId.columnId.targetProjectId.targetWorkItemTypeId=linkRoleId
So yes, I don't know the full setting name at this point because the name already contains "values".
I wanted to avoid comma-separated values to have one configuration per line.
Since the full setting name serves as a key and needs to be unique, I did the following workaround to specify multiple link relationships per work item.
I restructured the setting to a list of comma separated values looking like this
settingId.projectId.workItemTypeId.statusId=fieldId.columnId.targetProjectId.targetWorkItemTypeId.linkRoleId, fieldId.columnId.targetProjectId.targetWorkItemTypeId.linkRoleId
So it looks like this is just some kind of specific logic which is needed for some specific use case. The purpose of adding some methods to the ActionHook is the assumption that this method will be potentially useful for many hook implementations. I think for now you can just implement and use this method in your ActionHook subclass, and if in the future we see that it's needed in several different hooks then we can move it to the base class.
Description
Seems like we had a misunderstanding of the functionality of https://github.com/SchweizerischeBundesbahnen/ch.sbb.polarion.extension.interceptor-manager/blob/72bd95a7d96c6338f9c279448718d840b90bfbb9/src/main/java/ch/sbb/polarion/extension/interceptor_manager/model/ActionHook.java#L133
Currently, the method only returns the one setting matching the selectors combination and puts it in a map. Instead, I was looking for a behavior like in: https://testdrive.polarion.com/polarion/sdk/doc/javadoc/com/polarion/alm/tracker/workflow/IArguments.html#getArgumentsWithPrefix(java.lang.String)
The map contains all settings that have the prefix defined by selectorscombination and the key in the map is the setting key stripped of the prefix.
Example Settings (
settingId.projectId.typeId.statusId.fieldId=value
):For the selectorsCombination
settingId.Playground.requirement.draft
, the map contains: field1, something field2, somethingElseMotivation
--
Proposed Solution (optional)
No response