Service Discourse

License

No license.

Description of the service

Forum/mailing list service.

How to access it

• https://talk.openmrs.org

To perform several of the operations on Talk listed below (upgrade Talk, access sidekiq, edit badges), you must be an admin on Talk.

How to restart it

$ sudo -i
# cd /opt/discourse/
# ./launcher restart web

How to upgrade it

Upgrade the actual software here reasonably often (about weekly): https://talk.openmrs.org/admin/upgrade

At least 3-4 times per year, we should update the and web and data containers from the command line to keep from falling behind in the data layer (database and backend libraries and backend security updates). While rebuilding from the command line, the web application will be unavailable, so plan for 10-20 minutes of downtime when upgrading this way:

$ ssh talk.openmrs.org
$ sudo -i
# cd /opt/discourse/
# ./launcher stop web && ./launcher rebuild data && ./launcher rebuild web && ./launcher cleanup

Occasionally, changes in Discourse will not be upgradeable from the web UI either because the upgrade fails or you see a message like this:

You are running an old version of the Discourse image.
Upgrades via the web UI are disabled until you run the latest image.

When this happens, Discourse must be upgraded from the command line. If you want to have less downtime, you can defer rebuilding the data container (but if you are upgrading from the command line and going to have some downtime, it's probably worth rebuilding both web and data containers as mentioned above instead of using this shortcut):

$ ssh talk.openmrs.org
$ sudo -i
# cd /opt/discourse/
# ./launcher rebuild web

Troubleshooting

Emails are not being sent

If https://talk.openmrs.org/admin/email/sent doesn't show any email sent, send a test email from https://talk.openmrs.org/admin/email. If that doesn't work, it's probably a problem with the SMTP server or configuration.

If the test email arrives, it might be sidekiq paused. https://talk.openmrs.org/sidekiq/scheduler will have a huge warning letting you know that sidekiq is paused.

Following https://meta.discourse.org/t/sidekiq-stopped-working/26479, do:

$ ssh talk.openmrs.org
$ sudo /opt/discourse/launcher enter web
# rails c
==> Sidekiq.paused? 
(it should return true)
==> Sidekiq.unpause!
(it should return true)
==> Sidekiq.paused? 
(it should return false)
==> quit
exit

https://talk.openmrs.org/admin/email/sent should now have a lot of recent activity.

If that doesn't work, you can try rebuilding the app:

$ ssh talk.openmrs.org
$ sudo -i
# cd /opt/discourse/
# ./launcher stop web && ./launcher rebuild data && ./launcher rebuild web && ./launcher cleanup

It will cause outages, but it usually works.

How to enable Automatic Badges

Discourse has a feature to assign badges based on a SQL query; however, this feature was hidden for security reasons as of version 1.6. To enable the SQL box on the badge admin screen, you must temporarily toggle the feature on.

WARNING: invalid or improperly written queries can have adverse effects on Discourse (that’s why the feature is hidden), so be careful using this feature.

Temporarily enabling the Badge Query (SQL) field:

$ ssh to talk.openmrs.org
$ sudo /opt/discourse/launcher enter web
# rails c
[1] pry(main)> SiteSetting.enable_badge_sql = true

(go to OpenMRS Talk admin screen for badges, select a badge or create a new one, and you will see a Badge Query (SQL) box as one of the fields)

[2] pry(main)> SiteSetting.enable_badge_sql = false
[3] pry(main)> exit
# exit

(the SQL box should be hidden again from the badge admin UI)

For example:

/dev/2 badge is automatically assigned to users in the /dev/2 group using the following query:

with higher_groups AS (
  -- users also in groups above target are excluded
  select id from groups where name in ('dev3', 'dev4', 'dev5')
)
select user_id, created_at granted_at, NULL post_id
from group_users gu1
where group_id = (
  select g.id from groups g where g.name = 'dev2'
)
and not exists (
  select id from group_users gu2
  where gu1.user_id = gu2.user_id
  and group_id in (select * from higher_groups)
)

The query needs to return user ID, date badge was assigned (the query uses group assignment date), and a post references (not used in this example, so set to null). Once the query is entered, you should see a link beneath the field to preview the results (make sure it works as expected). You should also see a “Run revocation query” checkbox once the query field is filled in; check the revocation option to automatically remove the badge from users who are not returned by the query.

Badge updates (unless specifically designed to be triggered by something else) are run daily. Administrators can see when the daily job will run and trigger it manually from: https://talk.openmrs.org/sidekiq/scheduler (the GrantBadges job).

Logs location

/data/discourse/web/log/rails