How do I stop group names from being editable?


(Matt Terry) #1

When we go to: admin/groups/custom/* we don’t want the group name to be editable.

I was planning to just hide the field with css but I’m struggling to find any useful css classes to target the field i want to hide.

Would also be happy to show the textfield as disabled.

We run a vanilla discourse installation and override it with a css file, we don’t have a totally custom install.


(Matt Terry) #2

I think this selector might work:

.admin-container .groups


(Mittineague) #3

This worked for me as far as targeting the input (admittedly likely more specific than it needs to be)

div.admin-container div.groups div.content-editor form div input[name="name"] { 
  background-color: #badbee;
}

BUT
It targets all custom group name inputs
changing it to display: none broke Routing

I don’t think CSS alone will be any good for what you want here and that there will either need to be changes made in Core or a custom plugin will be needed, maybe only JavaScript if lucky.

Has it been that big if a problem with Admins changing Group names? Seems to me Admins should be trusted enough to know better.


(Matt Terry) #4

I ended up using this:

.admin-container .row.groups .form-horizontal > div:first-child {
  label[for="name"],
  input[name="name"] {
    @extend %hidden;
  }
}

the @extend %hidden just sets display: none !important and visibility: hidden


(Matt Terry) #5

It’s just on my todo list, I’m not sure how much of an issue it is


(Matt Terry) #6

Oh when you create a New group there’s no difference to the css so I’m hiding the ability to set a name on a new group… ho hum


(Matt Terry) #7

Would be quite handy if the path to the current page was reflected by classes on the body tag, like:

<body class="admin groups custom undefined">

When you’re on /admin/groups/custom/undefined then you’d always be able to target things on all admin pages


(Mittineague) #8

I was thinking it would be easiest if it had the group name included in the class so each could be targeted individually, but I don’t know if this would be considered a big enough problem to get it into the Core.
Hence my previous “custom plugin or maybe only javascript” post.


(Matt Terry) #9

That’s what that undefined part in the body class is, the url path has undefined at the end when you add a new group.

I was thinking that would be a good addition for all admin url’s, possibly just all url’s site wide, then you could css target any page based on it’s path.


(Matt Terry) #10

Well we didn’t find a solution to this so it looks like we’ll just rely on the admins not to edit it.


(Mittineague) #11

Did you try a plugin to use a different group.hbs template with "#if"s in it?

You would need to change it if the DOM for it changed in Core, but I would think it would be possible, no? eg.
make it more like “automatic”

<form class="form-horizontal">

  <div>
    {{#if automatic}}
      <h3>{{name}}</h3>
    {{else}}
      <label for="name">{{i18n 'admin.groups.name'}}</label>
      {{text-field name="name" value=name placeholderKey="admin.groups.name_placeholder"}}
    {{/if}}
  </div>

(Matt Terry) #12

Thanks for that @Mittineague The only way we are currently overriding templates is in the admin customise header section of the site, then running vanilla discourse.

I’m not massively keen on overriding too many templates since we’ll have to keep them in sync with future discourse development


(Mittineague) #13

Yes, it would add maintenance overhead by requiring a diff check before every upgrade.
Might be OK for a while but it would get old fast.