Which operator should I use to return certain records based on logged in status?

@sonalk Just to let you know, 'in' operator doesn't work at all. If you take a look at the use-case keenly, the column in the report looks as follows:


Example 1: Let's assume that a column by name 'Users' contains following values for 4 rows in a report:
Users
-------
user1
user1;user2
user3;user2;user1;user4
user5;user1

I don't think applying the 'in' operator will result you in the desired content. Because here each value in the column is in-turn a list of values in concatenated format, that is, 2nd row is a string combining two values, 3rd row is a string combining five values and so on.

For instance, let's say, for a filter, we have used the 'in' operator and fed the value as 'user1'. Then we get only one row, that is the first row from the above mentioned example. The remaining rows will be skipped because, second, third and fourth rows which should be present in the result has concatenated values by joining with other set of users.

Take a look here, this is how the filter will be applied, and you can understand that the filter won't work at all:
(user1) in (user1)
(user1) in (user1;user2)
(user1) in (user3;user2;user1;user4)
(user1) in (user5;user1) (We need to make a note here that user5;user1 is a string, and trying to filter the user1 in it fails and this row won't be returned. And this is also a reason, why a user has desired for contains())

As specified by you, the 'in' operator does good, only when the column holds a single value against each row in the report. Have a look at the example as follows:

Example 2:
Users
-------
user1
user1
user5
user4

So simply speaking, the 'in' operator does good when filtering the list(as specified in Example 2), but that's not the case when the each row in-turn holds a list in a concatenated format(As mentioned in Example 1).

Even the solution suggested by me is quiet simple just because of the requirement that the filter should be based on loggedInUser. Else accomplishing the use-case when the user value is dynamic makes the solution highly complex.

@sonalk Just to let you know, 'in' operator doesn't work at all. If you take a look at the use-case keenly, the column in the report looks as follows:


Example 1: Let's assume that a column by name 'Users' contains following values for 4 rows in a report:
Users
-------
user1
user1;user2
user3;user2;user1;user4
user5;user1

I don't think applying the 'in' operator will result you in the desired content. Because here each value in the column is in-turn a list of values in concatenated format, that is, 2nd row is a string combining two values, 3rd row is a string combining five values and so on.

For instance, let's say, for a filter, we have used the 'in' operator and fed the value as 'user1'. Then we get only one row, that is the first row from the above mentioned example. The remaining rows will be skipped because, second, third and fourth rows which should be present in the result has concatenated values by joining with other set of users.

Take a look here, this is how the filter will be applied, and you can understand that the filter won't work at all:
(user1) in (user1)
(user1) in (user1;user2)
(user1) in (user3;user2;user1;user4)
(user1) in (user5;user1) (We need to make a note here that user5;user1 is a string, and trying to filter the user1 in it fails and this row won't be returned. And this is also a reason, why a user has desired for contains())

As specified by you, the 'in' operator does good, only when the column holds a single value against each row in the report. Have a look at the example as follows:

Example 2:
Users
-------
user1
user1
user5
user4

So simply speaking, the 'in' operator does good when filtering the list(as specified in Example 2), but that's not the case when the each row in-turn holds a list in a concatenated format(As mentioned in Example 1).

Even the solution suggested by me is quiet simple just because of the requirement that the filter should be based on loggedInUser. Else accomplishing the use-case when the user value is dynamic makes the solution highly complex.