In addition to LDAP groups the techcontribs tool already shows, a developer account can be a member of unix groups on wikiprod servers. Membership of those is defined in modules/admin/data/data.yaml in operations/puppet.git.
Description
Related Objects
- Duplicates Merged Here
- T403325: add "Shell groups"
Event Timeline
"Admin groups" might not be the most common name for this. I think something like POSIX groups or shell groups might be more common. Wikitech calls it "production access" or "access groups", although I don't think those are great names either.
Anyway, just be careful which name you choose!
Now deployed! Initially was going to wait for other tasks to be done but I thought I should get this out now. "Primary groups" have been renamed to just "groups". The name "primary groups" originated from wt:SRE/LDAP/Groups, and since we're including more than just that now, I've changed the groups from LDAP to be specifically named "Primary LDAP groups". I've gone with the name "production access groups" for the groups defined in Puppet, because as you point out, that's what Wikitech calls it. Changing what it's called is out of scope for the tool; I just follow what Wikitech says. Please feel free to reopen the task if there's anything that needs changing! Live examples: taavi, novemlinguae
A minor annoyance: the description for analytics-privatedata-users is extremely long. Luckily, these groups have always been alphabetically sorted, so analytics-privatedata-users will almost always show up as the first group, and thus not cause any unwanted column splitting. The other annoyance is that the descriptions in the YAML file are flow scalar strings, which means all descriptions get parsed as a single, long line (newlines are stripped). Usually you'd add a | after the key name, then an immediate line break for the multiline string.
flow: this is a multiline string in source, but will be parsed as one long string block: | This is parsed as a multiline string correctly, and a line break will appear where there are line breaks in the source.
"this is a multiline string in source, but will be parsed as one long string" "This is parsed as a multiline\nstring correctly, and a line break will appear\nwhere there are line breaks in the source."
This prevents the 1) and 2) from being expanded into an actual numbered list per Markdown parsing rules, and also leads to sentences without periods separating them. I'm not so sure if changing the format of the YAML file will break things, but this limitation will exist and make the display look bad on Tech Contribs unless we do some form of transformation that removes info (e.g. only taking the first sentence of the description).
Very nice. Two small suggestions:
- remove "primary" from primary ldap groups. Im not aware of any "secondary" ldap groups
- limit posix group descriptions to 95 characters, and chop the rest of the string after that, and add a ... . 95 chars is about the width of one line, and most other posix descriptions are one line. See this example: https://techcontribs.toolforge.org/uid/taavi
Your Toolforge tool and Cloud VPS memberships are technically LDAP groups, but they are indeed shown on a different panel. If the tradeoff of just simply calling them "LDAP groups" (which is a little bit misleading) is fine, then sure, we can drop the word.
- limit posix group descriptions to 95 characters, and chop the rest of the string after that, and add a ... . 95 chars is about the width of one line, and most other posix descriptions are one line. See this example: https://techcontribs.toolforge.org/uid/taavi
That's my initial thought, though this is very likely going to break the text. A URL will be chopped off and lead to a non-existent page, or (if we use analytics-privatedata-users as an example) it will just have completely incomplete information (e.g. This group is the main entry point to the Analytics cluster, since it gives access to the stat1...). This method would be great if there was any other user-friendly place to view these groups for a user that I can link to (similar to how Phabricator projects link to their on-Phabricator tasks), but alas I don't think such thing exists.