Dear community,
I use JSM for my customer support requests, and Scroll ViewPort for the customer-facing documentation of my Confluence docs.
One issue that I am trying to tackle is as follows: when I add a KB page link (from JSM "Knowledgebase" search/suggest tool), it is included in my replies with the Jira servicedesk URL. For example :
https://maestrel.atlassian.net/servicedesk/customer/kb/view/29130753?source=issue-view
I would like to modify automatically the URL in the comment to redirect my customers to my ScrollViewport URL instead. In my example :
https://documentation.maestrel.com/hbook/plugin-installation
This will be done in 2 steps:
1. With Automation, I am trying to modify the comment so the link is modified from :
https://maestrel.atlassian.net/servicedesk/customer/kb/view/29130753?source=issue-view
To this :
https://documentation.maestrel.com/hbook/29130753
2. With ScrollViewport : I can set redirects on ScrollViewport, so once I have achieved step 1, I am good!
I have an Automation rule which is as follows :
What does not work is the "Edit comment on work item":
I know exactly what happens :
- the comment is edited at each loop, but since it edits the initial comment (and not the updated comment), it shows only the initial comment with the last edit and not the combined edits...
Here is what I have tried:
- Use a variable : I don't find a way to temporary save the comment as a variable and update the value with the updated string of the comment
- Re-fetched work item: I have tried to re-fetch the work item (hoping to have the updated comment) but this did not work either
Another issue that I am facing with the above rule is that an email is triggered (comment updated) at each loop.
Does anyone have come across this issue, and how did you tackle it?
Best regards
Céline
Hello,
I have decided to simply do a replacement of the base URL, as I can ignore the query parameter in the service desk URL.
I add the rule for anyone looking for this workaround, when using ScrollViewport.
Well done finding a workaround for your own question!
FYI -- The reason the branch did not work for this scenario is branches which could be on more-than-one-thing are executed in parallel and asynchronously, with no guarantee when the branch will complete...up until the last step of the rule.
This means repeated updates of the comment collided / walked-over each other as the branching happened. Occasionally, this can even appear as rule errors for some updates / actions.
The workarounds for this depended upon the specific rule, and often include three patterns:
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.