Can a repeating group contain custom set and data type?

Questions
1

Most of the content will be created by an internal team through the option set. Some of the content will be created by third parties. Due to security concerns, can I use both the content in a repeating group but the content coming from third-party comes from the data set. Is this feasible? Thanks

2

Yes, you can merge different lists with the “merged with” operator while they have the same content type.

1 Like
3

As Efe says you’d use :merged with. If you’re displaying a list of names in a list you can do something like this. “BusinessEntityType” is the data type and “_BusinessEntityType” is the option set.

optionsetmergewithdataset

1 Like
4

@narayan

A repeating group can only have a single content-type, so the answer to your question is no, you can’t use an option set AND a datatype directly as the content for a RG.

If you need to do something like that then one solution is to create a new datatype that can link to either the option set or the original datatype, and set that new datatype as the content type of the RG. Then use conditionals on the elements within the RG to display the correct data, either from the original datatype or from the option set.

Alternatively, as suggested above, you can set the content type of the RG to text and then set the datasource to text fields within both the datatype type and the option set using the ‘merged with’ operator. Obviously that will limit what you can display in the RG and/or make it more complicated to sort and search within it, and to run workflows on the cell’s data (you’ll need to use searches to match the current cell’s text to items in the database).

Out of interests, what are the security concerns you’re having, and why specifically are you choosing to use an option set for this, rather than simply using a datatype for all the content?

2 Likes
5

Thanks Efe

6

Thanks Gazinhio

7

Hi Adam,

I would be building holidays for different destinations which would be 500- 1,000 in number. largely created by an internal team. I understand using option sets, retrieval in much quicker than searching the data set.

However, I also understand that all info stored in option sets is public, hence I would not want to expose any details of a 3rd party ( supplier) - is this understanding correct?

Hence, though the data / content is standard and similar, I wanted to maintain it in this manner.

Thanks,

Narayan

8

I agree with Adam that the answer I gave is fairly simplistic and only works if displaying a raw list of names etc. If you need to manipulate them after the fact, you probably need to do things a bit differently.

If I were you I would save yourself a lot of bother and just store it all in the dataset. I can’t see any performance benefit from storing most values in an option set as you’re having to query the database anyway using :merged with. If you’re having to go to the database anyway, the amount of data returned isn’t the issue, it’s the amount of data you’re displaying in terms of the number of elements it has to put on the page, which either way will be the same I suspect. I surmise the processing of doing the :merged with will more than wipe out any benefit of using option sets. As for security, privacy rules are the way to go to secure your data and you can only set those on data types.

I would keep it simple, if it’s a list that’s in anyway customisable use a data type otherwise use an option set. It will save you a lot of time and effort I suspect.

2 Likes
9

Thanks again! I think that’s the best way forward.

1 Like