cancel
Showing results for 
Search instead for 
Did you mean: 

admin read vs. end-user permissions on systems used in VC

Former Member
0 Kudos

Hello,

after refining the groups/roles/permissions concept on our portal I found out that VC developers need end-user <b>and</b> admin read permissions on the required system objects (in order to see their aliases e.g. in 'find data' while vc modelling).

This fundamentally upsets my understanding of portal permissions! So far I thought the various admin(a.k.a. 'design-time')permissions were only needed for administering pcd objects (i.e. look at/alter object attributs) whereas end-user(a.k.a. 'run-time')permissions where only relevant for end-users who run applications in the portal.

In my case I would expect end-user permission to suffice for developing vc models. I mean as for the system objects used, a vc developer is an end-user - he doesn't administer system objects in any way.

Any ideas why this is so?

Regards,

Sebastian

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Sebastien,

If an iView is based on a system object defined in your system landscape, you must assign end user permission for the relevant user, group, or role to the system object, as well. End user permission assigned to a system permits the iView to retrieve data from the respective back-end application through the system object at runtime.

Former Member
0 Kudos

Well, thanks Tiberiu, however, this was not the point. My question was, why do I need both end-user <b>and</b> admin permissions, where end-user permissions should suffice.

I mean developing VC apps is a runtime scenario, so the need for end-user permissions for a user (in this case a VC developer) is obvious - otherwise the dropdown-box with the system aliases could not be filled for that particular user. But why the necessity of additional admin permissions on the system objects?

Regards,

Sebastian