Hi, I am trying to render a dropdown from a constant of type group (List) using

@karthikeyans If I am not wrong, this is a security issue. The user with whom you are trying to test the functionality - Either make this user a part of all the groups or set the 'Type' in 'Security Settings' of Group under 'Properties' tab to Public. It might be worth giving a try as suggested.

Added to above, inspect logs at the time you experience an error. That will help you to drill down deeper into issue.

Hi Karthik,

you can also try moving the logic or retrieving the group names to some script task in process before you hit this form(run as designer), as in certain cases you might not want to give extra security to the viewers or modify the security settings of groups.

@manisht Correct me if I am wrong, my understanding the suggestion given by you holds good only when we are in the context of process and if we are out of the context of the process, let's say we are on the Record View or Report etc, I guess the only way is to open the Security to all.

*my understanding is that, the suggestion given

Hi Sikhivahans,

yes you are right this is for process context, I am wondering what can be the scenario where we need a dropdown to represent groups on a report or a dashboard. If it's not a dropdown and is required only for display we should use groupnames (Text).

In any case if it is outside the processcontext and a dropdown is required, we can configure the rules to use getgroupbyname() and pass the text array of names, it returns null where user doesn't have proper rights on groups and we can process the o/p to remove the nulls.

This way user can still see all the groups he has proper access to without ending into above mentioned exception.

Opening the group security to all users will defeat the purpose of applying the group security at the first place itself.

@manisht Fair enough re statement 'Opening the group security to all users will defeat the purpose of applying the group security at the first place itself.' That's true.

I hope you didn't get the context in which I posed the question. My question isn't exactly about the dropdown component or the values it holds, but infact it's a question about visibility of the Group objects whose security is Closed. So far I have come across many scenarios where users who are not actually the part of process also tends to see what's going on in the process. Well, I would like to present you a scenario and I would be glad to hear your thoughts - Let's say I have an application and further let's say I have some instances launched as a part of the application and let's assume that each process has its own dynamic groups which are created as part of process and populated later on and only the users present in these dynamic groups will be able to complete the tasks in the life cycle of the corresponding processes. Ideally I would like to lock down the security of the dynamic groups created per process so that they aren't visible outside of the process and also these groups aren't needed outside the process infact. So far this is good. Now let's say I do have a group called 'Super Users', a static group which sits at the top in the Application's security hierarchy, but has nothing to do in the Application except to see how things are going on in the Application. Now let's say I want to show the Tasks Report on all processes in the Application. Ideally Task Report contains Task Assignees(tp!assignees) which are nothing but the dynamic groups created in the processes as specified by me earlier. Now if a user from Super User Group tries to access the report, an error will be surfaced because the security of the dynamic groups in the process is Closed. Now could you please let me know how I can overcome this without opening the security? We couldn't simply turn down the requirement saying that users from Super User Group can't see the Task Assignees values (could be by implementing the getgroupbyname() as specified by you and thereby specifying null content) in the Task Report as they are not a part of the process because logically the Super User Group sits at the top in application's security hierarchy as specified before.