CoffeeCake

Oh, come on, you ducks cheddar muttering sassafrases!

We received a similar error after creating an event in the IPS calendar. From memory, I believe the issue was involving what's in the sitemap.

Please give us a native feature to delete private messages and other content created by a known spammer.

Thanks, @Morrigan. That was a typo here, but in my theme I had it spelled correctly. I dug into the javascript library after posting and saw that there is a split on commas, so the correct syntax (for anyone else wanting to do the same) is data-ipsSticky-disableIn='phone,tablet'.

After trying that and doing a hard refresh (CTRL + F5), I had the desired result. Thanks @bfarber!

I tried adding two strings to the data-ipSticky-disableIn element, yet no go. ='phone,tablet' or ='phone tablet'... but nopes. 😞

I suppose there's not an enableIn equivalent that I could just specify 'desktop'?

@bfarber: Ah! So close! Is there a way to specify to disable for tablet AND phone? (In other words, only be sticky on the desktop viewport).

@bfarber: Thank you for this! This works wonderfully at larger viewports, however would be better if it did not apply to mobile/tablet viewports. How can this be done for large viewports only? For example, when mobileNav appears, remove the data-ipsSticky element from ipsLayout_header?

@Square Wheels: If you use one of the third party mail services that the Mail Bouncer application Adriano linked above supports, it does exactly what you want.

Unfortunately jay5r is probably using either an unsupported service or local smtp due to his content.

Yes, going back four years there. Work on this would be appreciated, IPB.

19 hours ago, TSP said:

Should be possible to achieve currently for future posts. 

1) Make an account with the name Anonymous

2) Choose this user account for the setting "Posts appear as posted by"

3) In your language packs, find the string with key anon_poster_hash. Change it to whatever you'd like. If you wish for it to be removed, I think you can try to just translate it as  

Would it be possible to, rather than associate with a single account (which would have a feed of posts by this placeholder member), instead associate with no account (an actual guest), yet set a static display name (or even give the end user the ability to select their own "guest" display name).

In other words, if we could have this so that we essentially allow "guests" to post, but only when logged in as a member, and that link is kept hidden from non-moderators.

On 11/6/2019 at 5:34 AM, Sonya* said:

Hi, can I replace Guest 63296...646 by just Anonymous? 

• I do not want Guest. It should be Anonymous, so that users see this is not posted by guest but by user who is registered but has an ability to post anonymous?
• I would like to delete the line "Anonymous poster hash: 63296...646" below the post.

 

I would like both these things as well. Is this possible, @TSP?

We'd like to see an easier way to rename applications. While it can be done by editing the furl.json files now, we'd like to see this changed to be included in the ACP without requiring file access or changes, especially for installed third-party applications.

@Adriano Faria: It would be nice to see in the Mod CP menu. Is that something you'd consider?

47 minutes ago, Miss_B said:

Can you please tell me what do you mean by the rest of your post btw?

Cheers!

I meant to say that it would be nice if you could treat this like other consequences--made it a tab in the moderator CP under banning and integrate it into the warning system.

Basically, make it available the same way that bans currently are to moderators instead of just typing in a list of ID numbers.

39 minutes ago, Makoto said:

I don't use that setting anymore. Causes too many reflow issues and is highly inconsistent.

ymmv though.

Do you have an updated full config you'd be willing to post?

Minor note... It was Tachy who went to Coventry. 😁

This would be much nicer if management of the ability to mark who was globally ignored were handled as a consequence to warnings and permission to do so granted as the moderator group level rather than a list of IDs.

Good start though!

FYI, we have not seen process locking with this update yet.

20 minutes ago, Adriano Faria said:

A more powerful tool for this matter: 

 

Adriano, we tried this, yet didn't think it was quite what we were looking for as it didn't produce notifications in quite the same way, but I'll give it another look. Thanks!

It might be the better solution as it is a global list for all moderators with perms.

I would like the ability, as a moderator/administrator to follow a member without alerting the member that I am following. When I deselect "let others see that I follow <MemberX>" I am not wanting the member to be alerted that I'm following their activity.

Perhaps this is a different checkbox or moderator level permission, yet this is an important tool to stay abreast of problematic members as they create new content.

Confirming that the addition of this plugin completely stopped that nonsense.

11 minutes ago, Makoto said:

Hey @Paul E.,

Can you download and upgrade to the latest release and see if this resolves the errors you are experiencing?

Thanks for your patience throughout this investigation!

Thanks, @Makoto. I've updated and will report back. The slight display errors still appear, yet will keep an eye on task locking:

Looking at the element, the words "Deletion Request" are tagged as font awesome, which causes the odd display of a serif font.

Just now, Makoto said:

Hey @Paul E.,

I know you mentioned you couldn't provide ACP access for debugging, but were you able to try simply temporarily disabling Adriano's app and then manually running the process task for Account Deactivation and see if the error persists?

You can manually run the task by searching for "tasks":

Then in tasks, search for the process task,

If you get an error even with Adriano's application disabled, then it's likely something I need to address. If it only occurs when both are enabled, it's a conflict we'll figure out together.

Hi @Makoto,

It doesn't happen every time the task runs--in fact, it often runs without issue. We can't disable Linked Accounts as we use it heavily--doing so would be rather disruptive to our production site. Running the task manually works just fine unless the process is locked. In those instances, unlocking the task and then running it works just fine.

We use cron to process tasks and we have a high volume site, so that there are messages involving guests is odd.

The process lock only appeared when we added the ability to delete accounts. Previously we were only using the deactivate option. We can temporarily disable the deletion option and see if the process lock goes away, yet as mentioned--it's not an issue on every hourly execution--only sometimes.

@Adriano Faria: I have a problem with your plugin and Makoto's Account Deactivation application:

Would you be able to assist to determine if the error (referenced in the post below) is from Linked Accounts?

Thanks!

We'd like to empower moderators to restrict private messaging as a consequence, yet still allow content to be posted/moderated in public areas of the site. Right now, a moderated member needs moderator approval before their public content is displayed, however these members can still use private messaging if it's otherwise enabled for their user groups. That's not always a right fit.

What we'd like is a new consequence option when issuing a warning that would allow us to select whether or not private messaging is enabled for that individual without having to grant access to the admin cp. We don't want to grant access to moderators to access the entire member record, and only give them the ability to enable/disable private message access as a consequence surrounding the warning system.

So, in other words, add the bolded option to warnings please:

• Moderate Content until dd/mm/yyyy hh:mm:ss, indefinitely
• Restrict from posting private messages until dd/mm/yyyy hh:mm:ss, indefinitely
• Restrict from posting public content until dd/mm/yyyy hh:mm:ss, indefinitely
• Suspend from accessing the site until dd/mm/yyyy hh:mm:ss, indefinitely

Many thanks!

Those are enormous files. I would assume the upload of media files like videos would be the likely culprit.

While you could probably safely write and schedule a cronjob script removing files that are older than X days as likely no longer being an upload in progress, I would agree with @SJ77 that there's an expectation that IPS would be applying some logic that would recognize when an upload had been stopped or aborted and clean up after itself.