Como

I assume that when I delete a usergroup, this does not affect accounts; it is just the group which is deleted - yes? What happens to member accounts if they are in a single usergroup and I delete the group?

Re: https://invisioncommunity.com/forums/topic/483796-monthly-quota-images-etc/ It would be very helpful to have a monthly upload limit per usergroup. It is also something which could be monetized. Perhaps two limits: one for images (which are usually the problem); and another for all other files. Fuller explanation at the linked page.

Does anyone know of a way to apply a monthly upload quota for images? I'm not seeing a way to achieve this. So, is there a third-party app for this, or an app which gets somewhere close enough to this to make a conversation with the developer worthwhile? This seems like a very obvious way to generate income for forums. A base monthly allowance, and a potential upgrade plan (or plans). As it stands, all we can do is apply a limit which affects all members, those who upload infrequently and judiciously; and those who post the largest images they can get away with and frequently. Yes, we can have different usergroups and charge to access those. But it is an inelegant solution because it is still a hard, lifetime limit. It would be nice to differentiate between long-term members who make infrequent use of uploading images. They should be able to continue to do this without obstruction because they usually bring other things to the table. If we up the lifetime limit to a level where they are unaffected, newer members who post images in scatter gun fashion can also take advantage of the same, high limit. This is a poor solution. Any ideas? Any third-party developers who might like to look at this or incorporate into an existing product? Thanks.

Yes. At the top of forums where members are restricted to viewing only the topics they started. They should not be able to see which other members are there too.

I probably misunderstand,* but in the Page Editor: Pages > Raw HTML * I probably do misunderstand, since there is nothing like that in the posts editor.

Absolutely!

When 'Users can see topics posted by other users' is disabled in Forum Permissions, 'Also here' should be disabled for that forum too. Since the most common reason to disable seeing other topics is for HelpDesk-type spaces, and since it is common for forum HelpDesks to deal with inter-member problems, it is better that members are not made aware of other members making potential complaints. Further, when 'see other topics' is disabled, there is no general utility in being aware of who else is using a HelpDesk forum.

Ah. I added several buttons in v4. But that v5 framework is almost certainly beyond my abilities. Irrespective, thank you for the link.

OK. Will do. (Tagging @Matt Finger to alert him to my previous comments.)

I think this should be revisited by the Invision team. I feel @aia's approach to be a much more intuitive solution, and it surely cannot be any more complicated to implement than what is there now. Anything on this? Thanks.

Hi. To me, I think this probably qualifies as a bug, but I'll post it here. It is common to have a 'back to contents' (or similar) link/button at the end of sections on longer webpages. But there is no ID for the Table of Contents (widget) div. Instead, I must target #ipsLayout__main which takes me to the top of the page. But this far from ideal as ToCs sometimes appear after an introduction. Does anyone have work around for there being no ToC div ID?

Oh. I see, I think. You mean float the ToC to the left or right and have the content flow around it. I've just taken a look - I've managed to hack this. I'll send you a link via DM. Scroll down a bit to a 'test' block. It is a bit rough, but perhaps good enough. If looks interesting, I'll write up some instructions. It takes just a couple minutes per page.

Hi @Dreadknux Maybe it has changed since your post, but you can certainly place the widget in the main column. I am already using it. You can also select when the widget will appear (for desktop and/or tablet and/or mobile), though it is buggy. I've added a report to the bug tracker - I expect it will be fixed. I also noted that the widget being displayed at the bottom of the page in narrower (but not narrow) viewports. (I had selected that it should be visible only in desktop mode). Surely, with visibility only for desktop, it never should be moved to the bottom of the page. Anyway, looks like it will be a useful widget when the bugs are ironed out.

Hi. The blurb at the options interface states: There are three permission levels of the Post Editor: Minimal, Standard, and Advanced. By default, users will use the Minimal Editor for secondary content such as Comments and Posts, and the Standard Editor for main items such as Topics and Blog Entries. Here you can configure which features are available at which levels. To change the levels each group has access to, see the Content tab in the Member Group Settings for a group. And the actual options available for each editor feature: Always; Standard & Advanced; Only Advanced; Never. What do the 'Always' and 'Never' options indicate? Does 'Never' indicate that the option is unavailable to all members? And what of 'Always'? Does this mean that the editor feature is available to all members irrespective of the settings within their usergroup, or something else?

I think your idea was never properly understood by the Invision team. I took/take it to mean that a placeholder is automatically created between quote blocks ready for text or other content. And if it is unutilized, the placeholder space is ignored/removed when the post is published. (Of course, this negates any need for buttons to insert lines.) For many ordinary users, those mouseover buttons will not be readily understood (or even noticed). And the obscured button (below image) does not help. (Tested in both Firefox and Edge.) I think it is a stacking context problem, but the usual fixes did not work for me. (The same bug exists here at the Invision support forum too.) Instead, I added some space below the quote block via a small piece of CSS. I think this is the better solution (adding space) rather than resolving the apparent stacking context problem. /* Fix for Invision quote box overlap of 'add line' button */ .ipsQuote { margin: 15px 0 0 0; }Nothing like the solution you suggested, But it at least makes the button visible. I too created an anchor button in v4 - it was very useful. By the way, why are there 'Insert line before/after' buttons displayed around the smiley, above, using the text editor when creating this post? If it is because Invision wish to have the option to add lines above/below images appearing within quote boxes, maybe the buttoms should not be applied to inline images. And as for other (block) images, I would expect @aia's solution of adding a placeholder space would work for them too. Where do I find this information? Was documentation ever published? Thanks.

Hi, On the forum index page, in Grid view, topics always appear in bold; in Feed view, topics always appear non-bold. Neither case is optimal. Like with forums and sub-forums, I suggest that topics' read/unread status (non-bold / bold) should be displayed on the forum index page.

We don't force new members to post to a particular forum. So, yeah, all the general forums. Thanks, Jim.

Ah. So there is no permission purely for approving posts!? I would need to enable a permission which would allow access to all hidden posts, of all types - yes?

Hi @teraßyte. As I suspected. And it will be across all forums. But thank you for the suggestion. I can probably live with the new usergroup being able to approve other posts from established members too. I'll just need to frame it as a more formal, quasi-moderation role. Having said that, how do I enable the ability to approve posts for a new usergroup? I cannot locate the setting for existing moderators.

How do we control which usergroups can approve content in the approval queue? In particular, posts from new members? I can find no setting in System => Staff => Moderators, for example. I'd like to create a new usergroup where the only added permission is the ability to approve posts/threads from new members. If this would also force allowing the new usergroup to view/approve the entire approval queue, this might be acceptable. I am at a loss to find a setting which controls this for existing moderators, but it surely must exist.

I think this would help. And the ability to bar algorithm inputs from specific forums (solved topics at our Contact forum, for example); and the ability to weight the various inputs to suit each of our sites Having said that, since there is supposed to be an AI behind Community Experts, wouldn't it be ideal to utilize RLHF? I know little about AI, but this seems like a situation where human feedback to the AI from forum operators removing poorly chosen Experts would improve the system no end over time. I am sure it will depend upon how AI has been implemented by Invision - it may not be possible at all.

I think how it works now is correct. Disabling Experts might be only temporary. If we need to remove Expert usergroups (permanently), this can be done in additional to disabling the whole system. Although the logic of how this is implemented is a little iffy, the outcome, I think, is correct. What I think is a bug is when a new member, with nine posts, is elevated to Expert.

Yeah. As I understand it, it is a Cloud-only system.

Community => Forums => Community Experts To remove those already labelled as experts, you will also need to remove the usergroups (same page). It takes up to 24 hours for this to take effect and the label removed from member profiles.

In case you missed it: If you wish, I can send you the name of the account. But since it is no longer listed, it might not help. In any case, I've detailed (above) the likely trigger for the account being added as an expert.