I am fairly sure this would be our no. 1 feature request as well. Group chats, without it .. it just feels like 2003 all over again.

@djcyry So we run it behind a reverse proxy too. Here's the config:

HTTP (file include)

server {
  listen 80;
  server_name www.social.example.com social.example.com;
  return 301 https://social.example.com$request_uri;
}

HTTPS (file include)

server {

    listen 443 ssl;
    server_name www.social.example.com social.example.com;

    ssl_certificate /etc/nginx/ssl/example.crt;
    ssl_certificate_key /etc/nginx/ssl/example.key;

    # SSL caching override
    ssl_session_cache shared:SSL:10m;

    # Enable long duration HSTS
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-NginX-Proxy true;
    proxy_set_header Host $http_host;

    proxy_redirect off;
    #proxy_next_upstream off;

    # Socket.IO Support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    include /var/www/social.example.com/conf/error.conf;

    location @nodebb {
        proxy_pass http://io_nodes;
    }

    location ~ ^/(images|language|sounds|templates|uploads|vendor|src\/modules|nodebb\.min\.js|stylesheet\.css|admin\.css) {
        root /srv/http/domain/example.com/social/public/;
        try_files $uri $uri/ @nodebb;
    }

    location / {

        # These need to be defined in the location block to
        # override express status message handler
        error_page 404 /404.html;
        error_page 502 /502.html;
        error_page 503 /503.html;

        proxy_intercept_errors on;

        client_max_body_size 10M;

        proxy_pass http://io_nodes;
    }

}

Also the following upstream (2 workers):

upstream io_nodes {
    server 127.0.1.4:4567;
    server 127.0.1.4:4568;
}

Finally, also a upstream loopback in /etc/hosts

127.0.1.4 nbb.node.example.com

Note that we defined both server names, www.social.example.com and social.example.com

Hi, I thought it would be a bit easier to bundle a few minor 'shortcomings' or useful additions from our perspective and future use cases. These would serve as a way to get some (community) feedback and interaction going to see if stuff is either feasible as a request or something we should pick up ourselves and if so, if there is a broader use for it (should we say, have to write a plugin for it - to get the abstractions right so others may profit from the work as well). I would really appreciate any feedback, be it that you either confirm a certain need (the so-called +1), or that something is planned (say on the roadmap), even if only that it was discussed at some point but abandoned for whatever reason (too complicated? not useful enough?). Anything like that, really, just any feedback at all is great.

I did my best searching for any earlier posts and if so, I will have checked it and either come with compelling new use-case, arguments I found weren't spoken out or something else new. If I have nothing but to support it, I might just +1 and possibly reference here.

Anyway, here goes:

1. Group settings: additional group selection for the "Allow Group Creation" setting. It's either bleeding hot or stone cold: on/off. It would seem sensible to allow further (simple) restriction based on a group? This might relate to other (in progress, planned or otherwise in the heads of) notions in the core team on 'user permissions' (as it currently really only in categories is maturely represented, it could be the idea is to take that permissions at some point and allow it to be applied to say widgets, pages and other site resources such as perhaps availability of certain settings to limited users).

2. Structure/hierarchy: allow groups to have nested groups. I'll readily admit, this might be a tough nut to crack. Or not. It would be extremely useful to our use case, and I would think others too, but I'd need to get some feedback on this. The plus side of this idea, is that it can start out really small (by simple reference and perhaps listing) but wouldn't need major expansion into other areas of logic, until required. The mere fact of organisation (with in-tact normal group logic) would be sufficient to our use case, one might assume more 'complex' rules would emerge over time (as to the inheritance of certain permissions).

3. Allow (easy) importing of users. Currently it is only possible to export users in a CSV, but not to import them. Although this may seem of some limited use, one could argue the same about exporting them. Point is, it takes some burden off the hands of non-techies who may be tasked with handling a move of a community to NodeBB who don't have the skills to import it in MongoDB or Redis. Furthermore, it already is possible to add user accounts via the admin: it is only very cumbersome to massively add users while this would very much seem like a common community (move) scenario. This is especially the case for those communities who are hierarchically organized and where profile/account presence is more eminent than user response times actually permit, were every user to move/register their account themselves.

4. A small and nice addition (easy to make/contribute) would be to have the rewards allow avatars of, well, awards - medals - ribbons - fluffy animals - whatever.

[DISCARD, FOUND] 5. friend list (people you follow)

Regards,

Rob

@Archeon just out of genuine curiosity but, how do you intend to (re)start and debug without access to the command line? Also installing it in the first place would pose a problem, tweaking and fixing packages would be although - arguably, one can do that locally as well. Somehow I get the impression you don't rely on the cli much in your desktop/laptop/development environment. Although theoretically, you'd be able to install a few things without cli and manage instances (e.g. compose.io for mongo, some redis host), the instances I had to debug/fix some plugin or other failure (since that is what Node does best, crash often and hard) far, far exceed any where I could deal with a plain NodeBB admin reload/restart (usually those are just configuration changes). I'm having a hard time imagining a pure GUI-based way, at least the foreseeable future anyway, which is not to say it is impossible

I am fairly sure this would be our no. 1 feature request as well. Group chats, without it .. it just feels like 2003 all over again.

@a_5mith Sweet, I kind of had that aching feeling, so I'll spare the extra work for now and wait for the release. I'll keep an eye out for the transfix update as well, is it supposed to collide (transifex update) with the release? I'd think the first might come a bit before the second, if only for giving translators the time to write something up before the release (unless you guys cook up the baseline translations yourself internally first). Oh well, anyway, thanks for the update !

Since there doesn't seem to be a transifex general ticket system other than ones created internally with specific translations, I decided to post here - which comes close, but might not be the most appropriate place; in which case I apologize.

Regardless, I was thinking it might be a nice time to pick up additional translations, I am doing so locally in a admin.json file of my mother language, Dutch, but I'd also need to do English. Would there be interest in making a new group/file for these translations. Is this something already taking place (I don't think so) or discussed and put on hold for whatever reason, I'd like to learn. Some other location to store the strings was decided (not their own file) or some other thing overlooking please let me know, I'd contribute the work if there is interest for it.

Cheers

Rob

@Yucayeque said:

ed or something. Any help? Thanks!

I can confirm this problem, one must delete it finally in the admin panels. Users can't delete own created groups (although there is a button) it seems to just clear, and not delete it.