While using less in the custom CSS, is it possible to gain access to the colors used in the theme/skin (specifically the skin).

I'm trying to plop in a background image floating underneath the content but allowing users to change skins causes problems because the main content area is transparent. So either I can set it to something light, which messes up dark skins, or set it to something dark, which messes up light skins.

Ideally, I'd like to transplant the body background color to the #content div without modifying the theme or skins.

Thoughts?

Ok. I think I know what's going on.

We're using a plugin called support forum that looks like it hasn't been updated in quite a while. My guess is that it keeps a hard reference to the tid, even if it's moved to another category.

It's only 168 lines of source, but I don't know Node.js or NodeBB architecture enough to make heads or tails of it. Maybe I should put a bounty on it? Not sure how well those kinds of offers are received, though.

Thank you, @baris

GitHub issue: https://github.com/julianlam/nodebb-plugin-support-forum/issues/7

ELadner created this issue in julianlam/nodebb-plugin-support-forum

closed Moving topic to another category has side-effects. #7

I've read all the docs and searched the forums several times over, but it's still not clear to me if you can upgrade across branches in one step.

For example, if I'm on 1.10.2, can I upgrade directly to 1.12.2?

In the past, I've always applied each interim release to get from point a to point b (i.e. in this case 1.10.2 -> 1.11.0 -> 1.11.1 -> 1.12.0 -> 1.12.1 -> 1.12.2).

If it's generally agreed that doing it one fell swoop is "no problem" (TM), it would save me some typing and time.

While using less in the custom CSS, is it possible to gain access to the colors used in the theme/skin (specifically the skin).

I'm trying to plop in a background image floating underneath the content but allowing users to change skins causes problems because the main content area is transparent. So either I can set it to something light, which messes up dark skins, or set it to something dark, which messes up light skins.

Ideally, I'd like to transplant the body background color to the #content div without modifying the theme or skins.

Thoughts?

In a fit of desperation, I ran the nodebb upgrade again and it finished with no errors. Should I be worried? (yes, I made a backup so I have a safety net if necessary).

Encountered this error during upgrade (1.9.x -> 1.10.0).

Forums are down, so I don't have access to the admin console. Looks like it's permissions based. Is it safe to delete the offending duplicate (and my command line mongodb kung fu is weak so assistiance would be grealy appreciated).

Updating NodeBB...

1. Updating package.json file with defaults...  OK

2. Bringing base dependencies up to date...  started
npm WARN discord.js@11.2.1 requires a peer of bufferutil@^3.0.2 but none was installed.
npm WARN discord.js@11.2.1 requires a peer of erlpack@hammerandchisel/erlpack but none was installed.
npm WARN discord.js@11.2.1 requires a peer of node-opus@^0.2.6 but none was installed.
npm WARN discord.js@11.2.1 requires a peer of opusscript@^0.0.3 but none was installed.
npm WARN discord.js@11.2.1 requires a peer of sodium@^2.0.1 but none was installed.
npm WARN discord.js@11.2.1 requires a peer of libsodium-wrappers@^0.5.4 but none was installed.
npm WARN discord.js@11.2.1 requires a peer of uws@^0.14.5 but none was installed.

3. Checking installed plugins for updates...  OK
4. Updating NodeBB data store schema...
Parsing upgrade scripts... 
OK | 4 script(s) found, 53 skipped
  → [2017/6/22] Hash all IP addresses stored in Recent IPs zset... OK
  → [2018/5/28] Give global search privileges... OK
  → [2018/6/7] Give post history viewing privilege to registered-users on all categories... OK
  → [2018/6/8] Give deleted post viewing privilege to moderators on all categories...
2018-11-09T16:07:00.294Z [31427] - error: [groups.join] Could not create new hidden group MongoError: E11000 duplicate key error collection: nodebb.objects index: _key_1_value_-1 dup key: { : "group:cid:166:privileges:posts:view_deleted", : null }
    at Function.MongoError.create (/opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:45:10)
    at toError (/opt/nodebb/node_modules/mongodb/lib/utils.js:149:22)
    at /opt/nodebb/node_modules/mongodb/lib/collection.js:1029:39
    at /opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)
Error occurred
Error occurred during upgrade: MongoError: E11000 duplicate key error collection: nodebb.objects index: _key_1_value_-1 dup key: { : "group:cid:166:privileges:posts:view_deleted", : null }
    at Function.MongoError.create (/opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:45:10)
    at toError (/opt/nodebb/node_modules/mongodb/lib/utils.js:149:22)
    at /opt/nodebb/node_modules/mongodb/lib/collection.js:1029:39
    at /opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

/opt/nodebb/node_modules/mongodb/lib/utils.js:132
      throw err;
      ^
MongoError: E11000 duplicate key error collection: nodebb.objects index: _key_1_value_-1 dup key: { : "group:cid:166:privileges:posts:view_deleted", : null }
    at Function.MongoError.create (/opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:45:10)
    at toError (/opt/nodebb/node_modules/mongodb/lib/utils.js:149:22)
    at /opt/nodebb/node_modules/mongodb/lib/collection.js:1029:39
    at /opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

Thank you, @baris

GitHub issue: https://github.com/julianlam/nodebb-plugin-support-forum/issues/7

ELadner created this issue in julianlam/nodebb-plugin-support-forum

closed Moving topic to another category has side-effects. #7

Ok. I think I know what's going on.

We're using a plugin called support forum that looks like it hasn't been updated in quite a while. My guess is that it keeps a hard reference to the tid, even if it's moved to another category.

It's only 168 lines of source, but I don't know Node.js or NodeBB architecture enough to make heads or tails of it. Maybe I should put a bounty on it? Not sure how well those kinds of offers are received, though.

@baris said in Moving topic from one Category to another:

db.objects.find({_key: "cid:<cat_A_id>:tids", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:posts", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:votes", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:lastposttime", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:recent_tids", value: "<moved_topic_id>"});

Very odd, and matches some very odd stuff I've seen on other things.

Replacing with the appropriate topic and category ID's doesn't return any values.

MongoDB shell version: 3.2.16
connecting to: nodebb
> db.objects.find({_key: "cid:35:tids", value: "39220"});
> db.objects.find({_key: "cid:35:tids:posts", value: "39220"});
> db.objects.find({_key: "cid:35:tids:votes", value: "39220"});
> db.objects.find({_key: "cid:35:tids:lastposttime", value: "39220"});
> db.objects.find({_key: "cid:35:tids:recent_tids", value: "39220"});
>

Just so I know it's working, here's the category it was moved to:

> db.objects.find({_key: "cid:54:tids", value: "39220"});
{ "_id" : ObjectId("5a610c4e1a911d0fab1a28aa"), "_key" : "cid:54:tids", "value" : "39220", "score" : 1516309669264 }

Me, as an admin, if I go look at the CatA category, it looks completely blank (all posts moved to private CatB). If I create a regular authenticated user and look at CatA, it's completely blank.

However, the creator of the moved_topic can still see a ghost of the topic in CatA.

Is there some per-user server-side caching going on? I can't see a way this could be client side, especially since there have been multiple reports of seeing the snippet of the most recent post change (right side of the topic in the list when it shows the most recent user to post and the first 100 chars or so of the post itself).

yes. My mongo is a little noobish, but I have command line access.

NodeBB 1.7.0

CatA settings: nothing special. registered users can find cat, access cat, access topic, create topic

CatB settings: also nothing special. privileges are assignd to only one group (full privs across the board for that group)

Long story, but here goes.

1. Two categories: one open to registered users (CatA), one restricted to a group (CatB).

2. Occasionally, moderators will move a topic from the open group to the closed group (CatA -> CatB) to discuss it in more detail in a closed session.

3. The original topic shouldn't be visible in CatA anymore (and to most people, it is not) but the original poster of the topic can still see it on the list. He can't click on it (permission denied in the other forum) but can still see the first line or two of the last post in the preview on the right.

I doubt this is a setup issue. Is this some kind of dangling reference bug?