change api to QraphQl
A few (5) bundled requestions...
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:
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).
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).
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.
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)