1

Best Practice for a "Read-Only" Pro User in a CI/CD Environment

Hello PA Team,

I'm looking for a best practice or architectural advice for a common CI/CD scenario that I'm struggling to implement.

I need to configure a Pro user profile for my production environment. This user should be able to:

  1. View all content (models, reports, etc.).

  2. Execute and schedule ETL processes for existing models (this is required for our CI/CD pipeline).

  3. Be blocked from making any structural changes to the models or any other content. All development must happen on a separate dev environment.

What I've Tried (and why it failed):
I tried to achieve this using Profiles. I created a "Pro Read-Only" profile and attempted to disable all editing capabilities. However, I found this was too restrictive. If I disable the rights to edit the model, the user also seems to lose the ability to execute the ETL process.

I couldn't find a granular setting to "Allow Execute but Deny Edit".

My Question:
What is the recommended, official Pyramid best practice for setting up this kind of "read-only" administrative Pro user for a production environment? Is there a built-in mechanism for this that I'm missing?

Any guidance would be greatly appreciated.

Thanks.

2 replies

null
    • Surya_Sankar
    • 2 days ago
    • Reported - view

    Hi  , have you taken a look at this pyramid link? There is more context to your scenario if you take a look at the Features section under Model. There are specific box options that can be checked off to suit your specific needs for the ETL process. I know you mentioned disabling all editing capabilities, but have you tried manually disabling only the features you don't want. For example, you could only select the "execute process" and leave other features disabled and then run apply this profile to check. I hope this helps. 
    Pro User Profile

      • TKH_TKH
      • yesterday
      • Reported - view

       

      Hi Surya,

      Thanks for the suggestion.

      Unfortunately, I have already tried this exact approach, and it doesn't work for my use case.

      The core challenge remains: I need a way to block structural edits while preserving all necessary "read" and "execute" permissions.

      Thanks again for your input.

Content aside

  • 1 Likes
  • yesterdayLast active
  • 2Replies
  • 30Views
  • 2 Following