Badge SQL can no longer be edited by default

badge
(Tobias Eigen) #9

Suggestion: add a link to the badge admin pages to here, to explain to those who follow what happened to the badge sql options? I just spent a good hour trying to remember how to do this. :crying_cat_face:

5 Likes

(Jay Pfaffman) #10

Indeed. It would be good if some settings (or notes about them) could also be displayed on other admin pages. My latest example was spending a good while trying to figure out why the Restore buttons were all disabled on the Backup page.

Edit: Oh. Golly. And I’d forgotten that it was a SiteSetting available only through the console.

0 Likes

(Jeff Atwood) #11

Hmm, no, I see it in site settings just fine on my DO droplet. “allow restore”.

0 Likes

(Sam Saffron) #12

Enable badge sql is a hidden site setting, only available via console

5 Likes

(Jay Pfaffman) #13

Antecedents.

Yes, the badge setting is hidden, so it’s really hard for someone to tell why they can’t make new badges.

Yes, “allow restore” is in site settings, but it took me a while looking at the backups page to figure out that I had to go to site settings to enable a restore (especially since it seems that on a Dev box you can restore regardless of the site setting.

3 Likes

(Christoph) #14

I agree. I don’t even want to start estimating, how many hours of wondering this has cost me. Could this be made more (admin-)user friendly? In my case, the confusion started when I was able to easily create new badges even though (as I can see now) the only way to actually use them is by manually granting them to individual users. In other words, the problem is that being able to generate new badges misleads the user to believe that these can be used just like any other badge So when I saw the option “Allow bdage to be used as a title” and thought, great, so I can create badges that people can use as titles (I know, for discourse veterans, this sounds stupid, but bear with me).

Long story short: I would suggest

  1. to add some help text in the “create new badge” dialogue informing the user that “unless badge SQL is enabled, the newly created badge can only be granted manually to individual users. Badge SQL can only be enabled via the command line.”
  2. to add a small help text under “Allow bdage to be used as a title” stating “Note that a user need to be granted the badge before they can select it”
4 Likes

How are user titles generated?
(Tobias Eigen) #15

A simpler suggestion methinks would be to just add a bullet about badge sql towards the bottom of the install instructions:

0 Likes

(Christoph) #16

That’s assuming that the person installing discourse is the same as the one getting confused about badges. To say the least, that’s not the case for all hosted discourse clients.

2 Likes

(Tobias Eigen) #17

Sure - that’s a good point. I had the same experience last summer and it was super frustrating. This issue was a big one back then because it affects people who already had discourse set up and upgraded at some point and the functionality changed/seemed to go away on us.

But the fix hasn’t happened yet and bikeshedding and all that. I honestly prefer to see discourse developers improving the frontend and like the approach they follow to try to keep the admin settings as simple as possible. Every change and every new text requires localization.

Badge sql queries are an advanced feature and should be implemented with care, which is presumably the reason why it has been hidden in the first place. I think the site admin should know about them.

If some commonly used queries could be exposed in a safe way via the admin UI, I’d totally welcome that. Perhaps this is already on the roadmap:

0 Likes

(Christoph) #18

That is indeed an important point that I had not thought of. And I see that it’s always a matter of prioritizing. Nonetheless, I feel it is my duty to report (admin-)user experiences that these folks will never have, given their familiarity with discourse. In the end, it is up to them to figure out what is feasible.

1 Like

(Steve Pavlina) #19

I agree that it would be nice to be able to add custom badges without having to use SQL. I just started configuring Discourse a few days ago and got to the badges section today. When I tried to create a new badge, it looked like something was missing – i.e. where am I supposed to set up the rules/triggers for each new badge? I had to search to find this thread about it. At least offer a few options like inputting triggering thresholds for posts, likes given, likes received, etc.

It would also be nice to edit the text for the default badges. I’d rather not provide a Lounge category for the Level 3 members (since I don’t think we’ll have many with a private forum), so I’d like to remove that from the description. I want to bring the text into alignment with the customizations that are permitted.

1 Like

(Harold Martin) #20

Can customers who have “fully hosted Discourse instances” get this configuration changed as well?

0 Likes

(Joshua Rosenfeld) #21

Yes, send an email to team@discourse.org with the request, they’ll take care of you.

7 Likes

(Dylan Hunt) #22

is this an old guide?

0 Likes

(Rafael dos Santos Silva) #23

It’s SiteSetting and not SiteSettings.

9 Likes

#24

I executed ./launcher enter app and then rails c, but it doesn’t seem to start right.

After starting, it doesn’t print out anything and it doesn’t react either. Any idea?

root@scw-1a7c81-app:/var/www/discourse# rails c
^Cbundler: failed to load command: pry (/var/www/discourse/vendor/bundle/ruby/2.4.0/bin/pry)
Interrupt: 
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/core_ext/class/subclasses.rb:8:in `<class:Class>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/core_ext/class/subclasses.rb:4:in `<top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/core_ext/class.rb:3:in `require'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/core_ext/class.rb:3:in `<top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionmailer-4.2.8/lib/action_mailer.rb:29:in `require'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionmailer-4.2.8/lib/action_mailer.rb:29:in `<top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionmailer-4.2.8/lib/action_mailer/railtie.rb:2:in `require'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionmailer-4.2.8/lib/action_mailer/railtie.rb:2:in `<top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/all.rb:13:in `require'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/all.rb:13:in `block in <top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/all.rb:11:in `each'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/all.rb:11:in `<top (required)>'
  /var/www/discourse/config/application.rb:2:in `require'
  /var/www/discourse/config/application.rb:2:in `<top (required)>'
  /var/www/discourse/config/environment.rb:2:in `require'
  /var/www/discourse/config/environment.rb:2:in `<top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/pry_class.rb:91:in `require'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/pry_class.rb:91:in `block in load_requires'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/pry_class.rb:90:in `each'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/pry_class.rb:90:in `load_requires'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/pry_class.rb:128:in `initial_session_setup'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/cli.rb:206:in `block in <top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/cli.rb:83:in `block in parse_options'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/cli.rb:83:in `each'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/lib/pry/cli.rb:83:in `parse_options'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pry-0.10.4/bin/pry:16:in `<top (required)>'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/bin/pry:22:in `load'
  /var/www/discourse/vendor/bundle/ruby/2.4.0/bin/pry:22:in `<top (required)>'
0 Likes

(Jay Pfaffman) #25

That seems strange. Is your site up?

0 Likes

#26

Yes it is, installed discourse today on a fresh vps after not having used it for quite some time :slight_smile:

0 Likes

(Jay Pfaffman) #27

Perhaps try rebuilding? I thought it might be something with Ruby 2.4, but I just did a clean install and rails c comes up just fine.

You followed the INSTALL-cloud instructions and Docker, right?

1 Like

#28

ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]

Rails 4.2.8

Discourse v1.9.0.beta1 +79 installed yesterday using the guide and Docker.

0 Likes