最近の検索


最近の検索はありません

But in FIND() function when using non-zero start index



投稿日時:2021年9月24日

I think I have found a bug in FIND() when creating a standard calculated attribute in Explore.

Scenario:
I have two tickets where one has a tag "cat_laptop" and the other has a tag "cat_software_ms-office_2019". These tags are used to categorize tickets.
I now want to create a report that shows all primary categories (the text after the first _ and before the second _)

Troubleshooting code

I create a new standard calculated attribute with this code:

IF
STARTSWITH([sakstagger], "cat_")
THEN
[Sakstagger]+" "+
FIND([Sakstagger],"_",4)
+" "+FIND([Sakstagger],"_",FIND([Sakstagger],"_",4)+1)
+" "+FIND([Sakstagger],"_",FIND([Sakstagger],"_",FIND([Sakstagger],"_",4)+1)+1)
ENDIF

Expected result:

cat_laptop -1 -1 -1
cat_software_office_2019 12 19 -1

Actual result:

cat_laptop 3 3 3
cat_software_office_2019 12 19 19

 

To me it appears that the FIND() function is missing the check that if the returned value is equal to or lower than the start index then it should return -1. In stead it returns the latest instance of the character and ignores the start index.

 

Possible workaround

I guess I could make a check myself, but that would defeat the entire purpose of the start index.

 

(Also I hope this is the right place to file bug reports. I couldn't find a better category.)


0

3

3件のコメント

Also, I would like to create some variables to use in stead of nesting the find statements like this.

0


… and it should be "Bug in" not "But in" o.0

0


… and now it appears to be fixed.

0


サインインしてコメントを残してください。

お探しのものが見つかりませんか?

新規投稿