This is a simple first pass at adding tracking metadata for file uploads.

Bitbucket

I have a LONG way to go here, but I thought I'd share a couple of things.

A little bit of Lavender and Vanilla in a blender plus feature requirements from in house.

Short version. The front page has a collapsable nested view of the Categories with the assumption that the top parent categories have no topics.

Posts have a severe abuse of the groups behaviour to implement forum titles and badges. Badges are displayed by placing a png file with the same name as the Font Awesome icon assigned to the group in the public/images folder ( ie fa-apple.png. ) If the file is not present the normal Font Awesome icon is not displayed - it doesn't mix and match yet.

Once I get a handle on plugins I'll probably move the badge code into a plugin. I also intend to push gravatars out into a plugin, add a custom SSO module, and add font-custom.

The I get to the prettification.

Oh. A link would be good.

https://github.com/dbolackmwm/nodebb-theme-titancity

The thing I retain most about middle school shop class was "Sure. you can stir paint with a screwdriver, but there's a better tool for the job."

@countach said in Clarity on NodeBB:

I can answer a bit.

• Is the integration of nodeBB with my own database client (say mongo) supported?

Nodebb supports redis, mongo, and a redis/mongo hybrid config.

• Is the API "build once, deploy to multiple platforms" or does an instance for each device need to be built? (web/mobile)

If I understand you correctly, there isn't really a concept of web vs mobile so long as the theme is sensibly bult.

• Does a gamification plugin/feature exist?

Try this thread?

https://community.nodebb.org/topic/6589/gamification/2

This should also work for a general Openstack deployment, but I lack a testing ground.

Simply fill in the provided fields and you're good to go. Otherwise works like the Imgur plugin. Naturally, this requires markdown.

Probably could stand to have a filetype limiter field or the like.

github

@Giggiux I expect to get the pruning in later.

I'm working on some stuff that isn't probably gonna get shared and it depends on this kind of stuff existing so I figured I'd break that out for sharing.

I'm gonna have to yoink that.

Nice work.

Honestly, this looks more like a job for rewrites.

So I picked this back up for the first time in a while and found it was horrifically not functioning, so I'm starting clean against the unstable. Should be... fun..

@baris

So I have looked at this in greater detail and here are the problems 1 I see.

1. The sortedset really only records two bits of information: the UID and the filename. If anything more is needed the filesystem will have to be queried and logic added to evaluate the file. My view is I'd rather store this in the DB and pick it up in a single query than collect the data from the filesystem on the pageload.
2. This process lacks the post validation check for uploads. This leaves debris in both the database and on the file system.
3. I didn't spot a cleanup system that might take care of this.

1 These are from the perspective of the problem I think I am trying to solve, aside from the couple I saw that are duplicates of issues I created in my own efforts.

I'm afraid you lose me at "However, for the 5$ you pay, you are getting some overpriced hipster box."

Really hard to take the remainder seriously.

@baris said in Curiousity? regarding file uploads.:

/user/<slug>/uploads

A cursory examination says no - but I need to dig a little more to be sure and then I think I need to stare at the results for a bit to see if it is better to plugin or PR for the extra bits I use that do not appear to be present here.

Also this looks like it has some of the deficiencies my initial draft had so I probably will end up doing both.

I need to churn on this for a bit.

Unfortunately, projects like NodeBB don't tend to do well with Extreme Stable spins like RHEL/CENT.

I would check and see if there is a more current node available in EPEL - Node's documentation recommends using this source: https://github.com/nodesource/distributions

I don't know if this matters for you, but the Fedora versions are usually new enough if you're in an environment where a "nonstable" spin is acceptable.

It's been a bit, but I've come back to my fileownership plugin now that the PR it was depending on has been committed.

Okay, a long time after.

This is a two step process. The first triggers off of the filter:uploadStored. This is done because part of what I want to collect and store are the mime type of the file and its size. There are also three permutations of the filename that we want to hold on to. This information is only available as part the file upload that happens when you attach the file.

The second step fires on the action:post.save - this exists for one main reason. If you delete a file from your message, nothing ( obvious anyway ) clean up after that. So this post process checks the message body at save time, compares it to the saved data from step 1 and cleans up any deleted files.

On to the curiousities. When you look at the body content on save, you''ll see

![0_1530309721623_FileNaMe.png](/assets/uploads/files/1530309721776-filename-resized.png)

The 0 is the user id #, followed by a timestamp, then the filename. The filename and extension portion match the original file as uploaded. This is followed by the relative url to the version of the image that is posted inline in the forum. Notice that the timestamps do not match and the file has been downcased.

When you click on the image when displayed, you'll load up /assets/uploads/files/1530309721776-filename.png

So why this post? Those timestamps not matching is a little irksome. Is this on purpose? If so, why, exactly?

I'm working on a plugin that programmatically adds group and/or user perms to a dynamically created category.

I mimicked the call used in the write API, but I'm not sure I'm constructing the perms correctly - and that still doesn't answer the issue of single user perms for a category.

I did a quick test to verify that nodebb setup will attempt to verify mongo access even if it has been provided - which I expected, but... and it does.

So it seems that the best practice here would be to pass the values in as part of the build with the assumption that the Redis or mongo instance already exists.

This is probably a dependency on the config file. Try building/dropping a static one in place before this step to validate.

When I have forked, in the past, I give the theme a new name and flip back and forth as needed.

I'll take a crack at it.

Where are you looking to place the tipper?