Robert Angle

To play devil's advocate here: Why make them a mod if you do not trust them to not do something like this though? Especially, something small like editing a profile of another staff member on the front-end. If you can't trust them not to do this, you can't trust them not to do something on moderating a topic.

Make it a Staff policy, and then fire them if they do 😄

Make it a Staff policy, and then fire them if they do 😄

Check over their group ACP restriction if they have this 4 checked on :
 
Since they are considered as being "admins", they need the permission to edit admin accounts for the profile picture + other informations.

Could you please provide an example user who cannot and we can take a look?

That's what it seemed like.
I guess allowing members to specify future Publish Date would encourage them to post more with more freedom, like posting future news, etc. Suppose there is a new movie release on a future date, they could post a new topic with the future date inviting reviews and discussions from other members and when the date/time arrives, the topic would become visible. It would let them set up future topics and forget without having to post exactly when the topic is needed at which time they may not be available to post.
For articles, they could line up to post articles in future leisurely when they have ideas instead of being able to post only when needed and there is no way to defer its publish date. It gives them more freedom and encourages to post more. Not having access to Publish Date/Time is too restrictive as members may not be available to post when needed.
These are similar to posting blog entries in future or allowing members to comment on a topic without registering to encourage more registrations. All these would still go through usual moderations. Most members would be too happy to use the Publish Date/Time to their advantage and freedom if they are given an easy way to see/filter their scheduled content to make any edits and such.
And with config settings to control publish date, the default behavior could be retained with ability to grant access to these fields to members and other groups.
These changes would bring consistency across various modules and expected behaviors.

If you just want to award "badges" that aren't connected to secondary groups, then create a custom profile field that only Staff can edit, and set that field to display with content submissions.

Sometimes, new members mistakenly comment on an article when really their question is completely unrelated and belongs in a forum instead. I wish there was a way to move their comment to a forum. 

Not sure what you mean by "never got to Intents" was that meant to read as Invision? If it never made it's way back to your community, it could be your firewall blocked Stripe's webhook request or the webhook is invalid. The log should be in Stripe if that's the case.
Glad to hear you were able to resolve that!
Unfortunately, the only possibilities are:
The user was deleted after the email was sent. The user changed their email/display name after email was sent. A backup was restored after email was sent which the user does not exist.

the mystery has been solved... as suspected by evidence it was never there, haha. The user posted on another forum in reply to the same user. 🤪
Does not help explain the new user getting a email when the member record was not actually in the system thou.. but im going to overlook that unless I get another. 
Other than that new spin up is working well. We did have a member try to process payment 2x (stripe) for an order, Just went to spinning gif and stuck, it it did hit Stripe API log for Payment Methods but never got to Intents. Nothing in Invision. Hoping it's his connection, see when he tries later. 🤷‍♂️
thanks.. 

There is no specific database-setting for that. You can only turn commenting on or off, set group permissions who can comment and you can decide if all comments are moderated or not. There is no exception to have just guest-posts moderated for a specific database. 
For guest-specific settings, global posting settings would apply (e.g. Post before Register settings). 

Youre overthinking it there...
EVERY field in a Pages database has a "topic format" field - make use of it:

The forum copy of an article should be able to be an excerpt, truncated, with a URL to the full article, imo. 

Yeah, I think we can stick in a bug report for this. It does make a pretty big loophole for spammers and bad actors.

This is correct at the present time. If a post is already approved, and the user has the ability to edit, they would indeed be able to edit that without moderation

Disable Post Before Registering. Permit guests to reply in the forum. Make sure replies are moderated in the forum.
The guest will see:

 
When approved:

Actually it's not a pity seeing as we have that already and are making it better.

And I am looking forward to getting my hands on it 🙂

And I am looking forward to getting my hands on it 🙂

As showcased in our past blogs, Invision Community 5 introduces a brand new, modern interface which brings improvements to performance, aesthetics and mobile usability.
An optional side navigation panel, new view modes, light/dark modes, customizable header layouts, a search modal and a mobile navigation bar are some of the things we've showcased previously. Today, lets take a closer look at some other miscellaneous changes that we've been working on while developing Version 5, including some of the code reductions and performance improvements that we've been able to achieve in the process.
For those of you who are developers, we'll also give some simple explanations of how (and why) we've implemented these changes.
 
Widgets
Sidebar widgets are perfect for displaying content feeds, featured members, announcements, advertisements and more on your page. In version 4 however, the widget column would often become an empty space once the widgets had been scrolled past:
  widgets-v4.mp4  
In version 5, widgets now stick to the screen once the last widget has been reached, ensuring your readers have more convenient  access to your widgets rather than a void space:
  sticky-widgets-v5.mp4  
 
Messenger
The Messenger is a great way to reach out to members when a private chat is more appropriate than a topic. Inspired by modern email clients, the messenger in Version 5 has been revamped with a full-height, sticky inbox, a longer message snippet, mini profiles and a more polished UI - all with a 25% reduction in CSS and a 100% reduction in Javascript.
messenger-v5.mp4
 
Sticky elements
We've mentioned sticky elements a couple of times now, so lets take a look behind the scenes at how they're created, and some of the performance improvements with Version 5. Traditionally, sticky elements were created using Javascript which would calculate the position of the element on the page and adjust it's stickiness every time the page was scrolled. Scroll events can be quite taxing for browsers, and when it comes to Javascript, the less, the better (especially when aiming for great page speed scores)!
With that in mind, all sticky elements are now handled using sticky positioning via CSS, which is a native and much more performant way of controlling these elements. We've been able to replace an entire 400 line Javascript component with just 3 lines of CSS.
 
Grids and Masonry
Grids have previously been handled in a similar fashion. Javascript would scan all elements within a grid to determine how many could fit on a single line, and would then shuffle these elements into position after the page was loaded or resized. CSS has since introduced its own grid properties, which has allowed us to replace more than 350 lines of Javascript with just a few lines of CSS, resulting in more performant page rendering and nicer looking grids (especially on small-medium displays such as mobiles and tablets).
 

 
Fun fact: We first introduced a similar performance improvement to "masonry grids" in our Gallery update from January this year, by replacing more than 400 lines of Javascript with, you guessed it, just a few lines of CSS.
 

 
 
 
Click targets
We wanted to make Version 5 as simple as possible to navigate, and one way of doing that has been by implementing larger click targets. Clicking anywhere inside an entry in a table or grid will now take you to that entry (you can still click on other links like normal within the click target, such as subforums or profile links). Click targets are optional and can be disabled via your theme settings if necessary.
 
click-targets.mp4
 
Data Lists (tables)
Speaking of tables, they too have been revamped. Tables automatically adapt to the space they've been assigned to (for those curious, this is done using CSS container-queries), so they're always neat regardless of the screen size, with no overflow or squashed layouts. Behind the scenes, the two columns below are created with identical code, yet they're quite different visually due to the size which they've been allocated. Even with these improvements, tables have received a 25% reduction in CSS.
 

 
Profiles
Profiles have been polished for Version 5 and include some nice improvements such as sticky widgets and tabs. 
profile-desktop.mp4
 
On mobiles, the side column collapses into a carousel, and the sticky tabs allow you to easily flick between content types without scrolling to the top of the page.
profile-mobile.mp4
 

Tabs
You may have noticed in the above clip that tabs on mobiles are now scrollable, compared to a dropdown menu from version 4. We made this change to ensure that tabs are given more equal exposure on small devices, and have managed to reduce the CSS by a whopping 80%.
 
Carousels
Last and certainly not least, are carousels. Carousels are great for displaying large amounts of data in a confined space and they've been rewritten from scratch for version 5. Previously, a Javascript library was used to create the "scroll effect", however this has never been the smoothest experience on laptop trackpads and touch devices.
In version 5, carousels are powered by native smooth-scrolling and scroll-snapping, which results in a much nicer user experience, especially on touchscreens. We've been able to remove a staggering 95% of the Javascript, substituting it with just a few lines of CSS.
 
carousel.mp4
 
To be honest, we've only just scratched the surface here! In addition to these changes, we've modernized (and reduced code) in almost every component throughout the suite including avatars, cover photos, dropdown menus, forms, inputs, buttons, lists, off-canvas menus, side menus, columns and more!
Combined, these changes result in not only a significant reduction in code, but also a polished UI that performs smoothly on desktop and touch devices. We're excited to continue modernizing Invision Community well into the future as new technologies and techniques become available to us, and are looking forward to getting it in your hands in 2024.

View full blog entry

This ability to schedule a future publish date for Topics was actually added sometime over the last year or so.

This is definitely a much needed feature. My Staff would love the ability to schedule posts in advance. Seems like it would be an easy implementation. Swap it out with that scheduled unlock feature which I can't fathom ever having a use for.

Once your member group has permission to post HTML in group permissions, you should see a "Source" button in the editor in the top left:

No
The one titled 'Source' - you said that
...so it had to be assumed that you had. If you didn't then you should check your group to see if you have the "Can post HTML?" setting is enabled for it.
You're adding whatever your html code is
 

You used the HTML option within the Code box button...that literally just posts code as text.
Click the Source button in the editor to edit the html.