On 7/15/2022 6:18 PM, Richard Brittain (richard.britt...@dartmouth.edu)
wrote:
On 2022-07-15, 09:04, "Jeffrey E Altman" wrote:
On 7/13/2022 6:07 PM, Richard Brittain (richard.britt...@dartmouth.edu)
wrote:
> I hope that doesn't lead people to expect 'pts membership
Only that the output of system:authuser would be confusingly long, and what
would system:anyuser generate anyway ?. We also have scripts for 'show me
everyone who has access to this entity', which gets complicated with nested
groups, and I couldn't figure out what to display for 'everyone'.
On 7/13/2022 6:07 PM, Richard Brittain (richard.britt...@dartmouth.edu)
wrote:
I hope that doesn't lead people to expect 'pts membership system:authuser' to
show all users.
Richard
I'm curious. Why would it be wrong for users to expect 'pts membership
system:authuser' and 'pts membership
On 7/14/22 5:49 AM, Dirk Heinrichs wrote:
Ed Rude:
I think I prefer the new behavior you are suggesting as the default.
I'd prefer to have the current behavior as default, as to not break
current scripts. Admins can then decide to enhance their scripts as
needed instead of being forced to
Ed Rude:
> I think I prefer the new behavior you are suggesting as the default.
I'd prefer to have the current behavior as default, as to not break
current scripts. Admins can then decide to enhance their scripts as
needed instead of being forced to change them because they got broken.
Bye...
As of the writing of this reply there have been several other replies to
my original e-mail from Ed Rude, Richard Brittain, and Gary Buhrmaster.
As there is some overlap in the responses I will reply once to Dave
Botsch's but I intend to touch on the feedback from all of the above.
On
On Wed, Jul 13, 2022 at 1:49 PM Jeffrey E Altman wrote:
> The question for cell admins is whether anyone is aware of any internal
> scripts which process the output of "pts membership" which will break as
> a result of the inclusion of the implicit groups "system:anyuser" and
> "system:authuser"
Ditto - our deprovisioning scripts use pts membership output, and I expect this
is common. Filtering out system:anyuser etc. would be easy, but a flag to omit
those and revert to 'old behaviour' would be even better. I do like the
improved transparency of listing them though.
I hope that
I second the inclusion of an explicit way of requesting one behavior or the
other. As long as I have a way to explicitly specify both behaviors working
around the change in anything that wraps the pts command should be simple
enough.
I think I prefer the new behavior you are suggesting as the
I suspect our user deprovisioning scripts would break by trying to
explicitly remove users from those groups. Though would be easy enough
to fix. And I'm in favor of having this extra output.
Two questions/thoughts would be:
1) If this is a "backwards-incompatible" change (is it?) should it be
10 matches
Mail list logo
