Como

I just received notification (the bell-notification at the site) that (minutes earlier) a post from a new member needed approving. However, the post is from nearly 60 hours earlier. Does anyone understand why this might be the case? Actually, it is even weirder than this. I now see that the member only joined only half an hour ago, and obviously posted their introductory shortly thereafter. But the post appears further up in the thread, with several (days-old) posts in the interim. Any ideas?

Thanks @Marc Stridgen

Hi @WP V0RT3X I do. And this occurred to me. But the number of posts does not appear to match. And since clubs have their own area in stats, it seemed unlikely anyway. I wasn't sure if you were speculating or informing me about this - so I changed topics to threads to test this. Yes, you are correct - that's the answer! But it does not make sense to me since clubs have their own stats. Well, thank you for the explanation.

I've a lot of old, archived content. So I double- and tripple-checked that I do not have a forum called 'topics'. This is for one month, but it appears in prior months too. I didn't capture it here, but when I hover topics in the key, the corresponding datum block is highlighted in the graph.

Hi all, I do not mean the obvious - I mean this: ACP => Statistics => Forums => Topics => Topics by forum => Topics (listed as a forum) ACP => Statistics => Forums => Posts => Posts by forum => Topics (listed as a forum) I do not have a forum called 'Topics'. Thanks.

Yes!

On a couple of occasions since writing the above, I really needed to use multi-quote for an opening/seed post, but could not. It seems like a bug or oversight, as I cannot think of any reason for preventing this behaviour.

I discovered that multiquotes work across threads and messages - this is very nice. Just what I was hoping for when I tested it. However, there is no multiquote 'quote x posts' option when creating a seed post (I have not tested it with messages). Hopefully I am just missing something. And it is not available when editing the seed post, but is for subsequent posts. Seems like an oversight or bug.

Perhaps they just need an 'x' to remove them. And, a mark all as read option too.

I am not sure I entirely follow, @marklcfc. But would not a 'mark all as read' button get you there?

So, you are making a distinction between 'unread' and 'new unread'. And the bubble will show 'new unread'. I think that's probably an unnecessary complication. And there is some utility in knowing the number of actual unread notifications; a bubble indicating '0' when there are unread notifications has a downside too. I understand your reasoning, but in the round, I do not agree.

Just to add: I note that 'reported content' (which presents information very similarly) only marks as read those items actually read. Is the behaviour in the notifications list an oversight or bug?

I have to agree - it would be better if they were marked off individually. Them all being immediately marked as read in the notifications dropdown is unexpected behavior and certainly inconvenient.

Thanks, Marc. I am sure that's just what I am looking for. 🙂

Ah. I see. Thanks, @Jim M I did not know this is possible - and I did look. Where do I change the setting?

Sorry, Marc. That's just not true. As I explained it above, and later linked to an analogous case, I would need to switch to US locale. But this would change other things, such as commas and periods in numbers and currency, and even formula functions will change in some languages. When the dates are in US format, they are misinterpreted in other regions. Up to the 12th in the month, the month and date are swapped in interpretation; from the 13th onwards,* the date is not understood as a date at all and considered to be general data. If it goes into another month, it will swap again, and again. But will never interpret any of the dates correctly. * Because there are only 12 months. If the user recognises the problem and understands the cause, it can be worked around. But it creates more work. Using the international date format removes all the complications. And from that (because that date format is understood by Excel in all locales), it extremely easy to switch between date conventions for selected cells (because all the data is correctly interpretted in the first place).

Cheers, Marc. Yeah, I did not realise that regular email from the regular support address was a ticket. Thanks.

Hi @Stuart Silvester And which 'language pack' do you suggest people use who do not live in the US? Changing locale affects everything, for all files, comma/period use in numbers/currency, some excel formula notation, etc. - not just dates. https://edu.gcfglobal.org/en/excel-tips/understanding-regional-differences-in-excel/1/ I just found the below explanation/tutorial. Not exactly the same situation, but analogous. All the difficulties for those outside of the US would be avoided if instead IPS used the international date format. As I understand it, the international date standard is recognised by Excel in all locale, including the US. https://www.excelatwork.co.nz/2022/02/09/change-date-format-in-excel/ Well. That's my feedback. If you feel that it is unimportant, so be it. All I know is that I immediately ran into problems because of the US date format used in the CSVs.

Thanks.

I do not have a ticket. Or, if I do, I have not received an email with a link to it.

So, the chosen date format is intended to be incompatible with the world outside of the US? 🙂 1. Those dates before the 13th of the month are inverted (April 7, 2023 becomes 4 July, 2023); and dates from the 13th onwards are not recognised as dates at all (by Excel, at least). However, using the international date standard (2023-04-07) should work everywhere. If this is not recognised early on, it can mess up a lot of work. And even if recognised, it can take a fair bit of work to rectify (depending how adept the person is with Excel). And I doubt it is just Excel which is similarly affected. 2. And (maybe a small thing) dates in the download are off by a day compared dates in the stats area in the ACP. (This is surely a bug).

Hi, We recently migrated to IPS. I've just become aware that none of the account name bans have carried across - I can live with that. What is more troubling is that more than 700 accounts* which have ever been suspended (over 19 years) - including a large number of account holders who requested 'time-out' limited suspensions - have had their IP and email addresses banned. * It is actually half that amount, but for some reason they all are entered twice, under two different dates. I can resolve this, but I have to go through each and every IP 'ban' and each and every email address 'ban', one-by-one, and remove them from the list. I am not happy - the converter obviously does not handle bans correctly - I need a more practical solution than removing more than 1,400 entries, one-by-one. Thank you.

I've have the same error - I've logged it with CleanTalk last week. They offered to have a look, but I have bigger problems right now, so wished to rule them out first as the cause. I suggest that you contact CleanTalk - they already have at least one other report!

Seems there is an explanation for my above post here: I am not sure I fully understand, but it appears to be benign and expected behavior.

I suspect the following is related to the above. The URL to user profiles, as displayed next to posts, is appended with an apparently superfluous string of characters. I disabled all apps and plugins and retested - same result. I note that no similar extra characters appear here when I hover/click usernames beside posts. https://xxxxx.xxx/profile/USER-ID-USERNAME/?wr=eyJhcHAiOiJmb3J1bXMiLCJtb2R1bGUiOiJmb3J1bXMtY29tbWVudCIsImlkXzEiOjI3MDg3NywiaWRfMiI6MzQ0NDU3NX0= The appended string is different for every post. Thanks.