It would be great if you could create admin groups which can only read things in the admin panel, or are restricted to certain panels. And also maybe restrict them to a certain category. A more extensive rights system would be nice.
The question you need to ask yourself is why you would like to impersonate a user?
list itemIs it because you want to recreate an error the user has? Just ask him if you can logon to his account and temporarily change his password to do so. You don't need any additional plugins to do this and the user knows you are accessing his account.
Do you want to read his private messages? Why would you do this? Here (in Belgium) it's illegal. For two reasons :
** it's considered as private information and thus you're not allowed to read it. It's simply illegal.
**Another reason is GDPR : you only can access user information if it's relevant to do so and only for the duration that it's relevant. No way you can justify reading his private messages.
In case of abuse or more serious illegal activity by the user, let's say he/she's trolling other members, you'll get this information from other concerned users and can act according to this information. It's your perogative as administrator to ban users based on their behaviour on your website.
And if the user really does illegal stuff like insinuating or distributing child pornography (I know heavy example), you're legally obliged to report this to the authorities. Not doing so makes you an accomplice, at least here in Belgium.
So in my book, there's no reason at all to impersonate a user. And if anybody reports abuse and provides the necessary proof, I'll act according to the forum's rules and if needed according to the Belgian law.
Not sure if that's the right category, but here goes.
I want to implement a plugin which makes it so the email addresses of registered users are stored hashed for privacy reasons.
I think I can use action:user.email.confirmed to overwrite the email with its hashed version.
I want to still support password reset and to that end I want to use the hashed provided email to get the uid of the user.
Would it be possible to add a hook for filtering the email provided to getUidByEmail here?
Additionally, in order to use the non-hashed email as the address, it would also require passing the user provided email in params here.
I am not entirely convinced about the whole overwriting story
npm deletes the old version of the module before installing the new module version. So any changes you make inside a module directory that is managed by npm will be deleted.
Ok but why not let npm do the management and add the entries in such a place that it is managed correctly?
even if that was the case, what would prevent simply reinstalling the plugins as well?
The package.json defining installed plugins would be deleted.
Ok I see your point but this is precisely the case because NodeBB insists to run in its source code directory. Indeed, NodeBB should look for package.json in the parent directory and further up the directory tree and add the plugin entries there prior to running npm install.
plugins to require('nodebb/src/...') instead of require.main.require('./src/...') which in turn would open way to proper unit testing for plugins
Unit tests shouldn't need to connect to NodeBB, as units are small pieces of code that can be isolated from the rest, including NodeBB. You can set up your unit tests however you want for your plugins.
That is true, I just mean that plugins notoriously use NodeBB internals by means of require.main.require('./src/database') etc. it would be cleaner if NodeBB actually came as a set of modules and one could simply require('nodebb-database');
As for higher level tests:
Again, NodeBB requires a connection to a database, even while testing. Your plugin test harness would still need to initialize the database as they do now.
Well ok that is true, I guess the main points are the ones before.
run multiple instances without copying the entire source code directory
That would be a nice result of rearchitecting, except then every NodeBB instance must be at the exact same version.
True but it is usually fine to just run the most recent version.
be more in line with how Node apps are installed generally
Again, I'm unaware of any node applications like NodeBB, that must connect to a database to function, that work the way you describe. Please provide an example.
I don't think that connecting to a database somehow "excuses" applications writing inside of their own source code directories. It just feels very much not right.
Among bigger applications I guess ESlint still nicely provides a binary. But it would be great if NodeBB was a pioneer and the first one to do it "right" among the Web apps :)
@julian No, no, no!! Hashtags are for IRC channels! Always have been. On the 'net, anyways.... ;-P
I have thought about the tagging thing on and off a few times over the course of using NodeBB. At first I missed the absence of tagging individual posts. Figuring that the NodeBB crew were smarter than the average bears, I figured they must have some reason or another figured for omitting such. Alas, the only thing I could figure was "tag pollution". Kind of like too many chefs spoil the broth kind of deal, too many tags, and perhaps ensuing gamification thereof by those desperate for attention/upvotes could result in them becoming essentially useless. Herding cats, entropy always increases, etc. Substitute whatever analogy floats yer' boats.
Forums excel at promoting long running, in depth conversations. Too many distractions are deriguer for the "ADD Generation". Hence, while I can see how hashtags would be an asset for something like Twitter, I wonder about posts wh/actually contain some meat, rather than just a bunch of "me too's" pointing to various other "me too's". Hmm...
So we should ask ourselves; "What purpose do tags actually serve? What itch do they scratch?". I think not many, actually, other than one: A quick substitute for lame and/or non existent search functionality. Maybe another side benefit for the lazy would be that tags are amenable to "clickery" driven UI's. This revelation then begs the question of how many new things we might invent to solve "problems" supposedly already solved by other previously invented "solutions". And maybe, just maybe, rather than proliferating yet another new thang... we should focus on improving the original thang that was supposed to solve these issues: Search that works? And what would that look like?
Hmm... just a bit of thought food here for inquiring minds.... 🤔
P.S.; Not meaning to disparage anyone's efforts here but rather stimulate further discussion.