@Russ Whitehead - should the check be changed from it's current :

to:

?

Thanks, @Russ Whitehead, but I believe I understood. Given its narrow scope and essentially consistent-enough-to-be-hard-coded approach, there is no need to have a managed file scope in LDAP for each of them.

My point is once this is hard-coded so that hpccinternal::mydogspot is handled in code, then only user mydogspot will have access. For day-to-day, no problem.

For exceptions, though, would we not need a new permission that allows assigned users/groups access to these scopes for special purposes, such as clean-up? Orphaned files have existed for various reasons (failed WUs that did not clean-up), people leave, etc.  That's all.  @Fernando Uceta, know what I mean?

@Tony Kirk Perhaps the Jira description was unclear. What I have done is removed the creation of all HpccInternal scopes, and no longer check them via LDAP.  Instead, it is hard coded to make sure the username matches the name of the internal scope (ie  user tkirk, scope hpccinternal::tkirk is granted, user wwhitehead scope hpccinternal::tkirk is denied),
Once all environments are up to date with this feature (Fix Version: 9.0.36 9.2.14 ) then you can delete all of the thousands of LDAP HpccInternal scopes.
Note that @Fernando Uceta and other admins greatly disliked the old way, since they had to scroll through thousands of them in ECLWatch

I suppose we could grant HPCC Admin's access, but I will defer that question to @Jacob Cobbett-Smith 

@Russ Whitehead, the point is it can currently be manipulated as can any managed file scope, if necessary, such as to allow someone to delete an hpccinternal::<user_name> file created by someone who no longer has access.