500 character ‘Reject Reason’ is too small a limit

ux
1

It seems that when notified to review the application of a new user to my forum, and I reject the application using the ‘Delete User’ option, and in the process select the option to include an emailed note explaining why their application was unsuccessful, I now get ‘422 Error’ as the response.

If I omit the note, I am able to delete the user, as before.

Forum generated emailed notifications to signed up users otherwise still work fine.

The currently installed Discourse version is 3.2.0.beta5-dev

Forum error logs corresponding to the date of this occurance (today) below

5
Deprecation notice: `SiteSetting.min_trust_to_edit_post` has been deprecated. Please use `SiteSetting.edit_post_allowed_groups` instead. (removal in Discourse 3.3) At /var/www/discourse/app/models/co
1:19 pm
15
Deprecation notice: warning: the email parameter is deprecated. all POST requests to this route should be sent with a base64 strict encoded email_encoded parameter instead. email has been received and
1:37 pm
Email can not be processed: Email::Receiver::AutoGeneratedEmailError Received: from smtp-mx-server-8.servers.netregistry.net (unknown [202.124.241.69]) by nz-mail-receiver.localdomain (Postfix) with
1:37 pm
Email can not be processed: Email::Receiver::NoBodyDetectedError Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [104.47.14.50]) by nz-mail-receiver.localdomain (Postfix) with
1:39 pm
2
ActiveRecord::RecordInvalid (Validation failed: Reject reason is too long (maximum is 500 characters)) app/models/reviewable.rb:362:in `transition_to' app/models/reviewable.rb:335:in `block in perform
1:51 pm
2
Failed to handle exception in exception app middleware : ActiveRecord::RecordInvalid : Validation failed: Reject reason is too long (maximum is 500 characters)
1:51 pm
235
Sidekiq is consuming too much memory (using: 557.11M) for 'nzarchitecture.net.nz', restarting
1:54 pm
38
Deprecation notice: `SiteSetting.min_trust_to_create_tag` has been deprecated. Please use `SiteSetting.create_tag_allowed_groups` instead. (removal in Discourse 3.3) At /var/www/discourse/lib/guardia
2:06 pm
33
Deprecation notice: `SiteSetting.min_trust_to_edit_post` has been deprecated. Please use `SiteSetting.edit_post_allowed_groups` instead. (removal in Discourse 3.3) At /var/www/discourse/lib/guardian/
2:06 pm

I am not sure when/under which Discourse software version this issue first started, as I don’t get many applications, and need to reject very few of those that I do get, but certainly I had encountered no such problem before now, and I have used the same pasted message in previous rejection notifications to applicants.

I see reference to a 'reject reason is too long (maximum is 500 characters), and my standard reject reason text is indeed longer than 500 characters - but this seemed to work previously.

I do think this is important to resolve, as providing a full and satisfactory explanation for any rejection is a basic courtesy to intending applicants, particularly if it is not clear that the application was maliciously motivated (If they fall outside the intended membership criteria but are not obviously bots, marketers or other ‘bad actors’).

This is hard to do within 500 characters if we also want to provide advice to anyone who might want to reapply. If necessary, is there a way to increase the character limit?

This has been requested elsewhere, but I would like to reiterate the request (if any developers see this) that we also have a dropdown list of editable standard ‘reject reasons’ to select from.

3 Likes
3

I think limits were recently placed on some of these text fields, though in some cases they were a best guess of what was reasonable. I’ll see if this one can be upped to something higher. Do you have an idea of how many characters you would need?

If you could add your voice to an existing topic that helps show that it’s a popular request and can often bump it up the priority list. :+1:

3 Likes
4

Hi thanks @JammyDodger, my current rejection reason text is 2211 characters long, because it contains advice addressing a few scenarios which do involve some nuance (this is a pretty specialised forum).

Ignoring the drop down reasons list idea for now, rather than this reason being a blank field by default, could this even just default to using a predefined text string? with a tick box allowing the blank field to be used on the fly as a substitute custom text option, should the need ever arise?

Will try to find that separate request thread.

1 Like
5

Yes, correct, we added a database-level limit for this about 9 months ago: DEV: Set limits for text fields in reviewables · discourse/discourse@783c935 · GitHub

Currently there is no possibility to override that on a per-instance basis. I would be open to bumping the limit a bit, maybe to 2000 characters, but first I’d like to see more cases of this being a problem in the wild. For now, trimming down that message (and maybe adding a link to a topic with the rest of it) makes sense to me.

I do think we should improve the UI around this so that the error message is displayed to the user inputting the text that exceeds the limit.

8

A published page might work quite nicely for that if the site is login required. They can be made visible to anons even if with login required set.

2 Likes
9

Thanks guys. I have done that, though would prefer to eliminate the extra step required of applicants who are already feeling a bit irritated - especially since email apps will often block the opening of urls in emails received by default.

I am keen not to unnecessarily aggravate or alienate anyone who might later turn out to be a viable forum user.

And I am still keen not to have to manually copy-paste this message in every single time

1 Like
10

I’ve not seen email apps personally that do that, seems like a strange deault.

11

My own Microsoft Outlook app is one such example. This behaviour seems to be influenced by the trust level it associates with the message received.
A new user/applicant will be triggering an automated email response that may seem a bit spammy if the user has not already added the sending domain to their trusted senders list - which step seems a bit more than a new user can be relied upon to have taken, especially if they have yet to actually be accepted as users.

I have done what I can to maximise my email domain reputation, but some messages sent by my forum still end up in junk mail folders for some recipients - and while they can still be read there, links are always disabled.