Add option to use native removal reason text as comment/modmail body

[SL13PNIR]

Hey,

The removal reasons do not seem to be applied when I use the reason's id in the configuration. I obtained the ids from the recommendation of using the "show removal reason ids" app and confirmed them with praw.

Here is a basic config example that I'm using in my test subreddit, where, if mod changes to the specified flair, the post should be removed and removal reason should be added: [ { "templateId": "b5689986-b075-11ea-9bfe-0ed29ad248c3", "action": "remove", "removalReason": { "reasonId": "58f2b2f7-cfa1-4fc9-9775-61c7de5aa405" } } ]

The post is successfully removed, but the removal reason is not added.

[PitchforkAssistant]

Just to check, are you expecting that to leave the removal reason as a comment/modmail?

Due to the way Devvit works, addRemovalReason only adds a mod log/user history entry. Although even that has been a bit spotty from my own testing.

[SL13PNIR]

Just to check, are you expecting that to leave the removal reason as a comment/modmail?

Due to the way Devvit works, addRemovalReason only adds a mod log/user history entry. Although even that has been a bit spotty from my own testing.

Yes that was what I was expecting! I assumed it was the same behaviour as to "add removal reason" (with an optional note) as a manual action with the mod tools as in the sceenshot:

Could you perhaps just tweak your app's behaviour, firstly by adding toggles to the removal reason context window:

then when true, adding the text of a removal reason as comment or modmail (which your app has the capacity to do with the existing comment and modmail toggles). Config parsing could be kept simple with true or false for the toggles, it would just be a case of getting the removal reason text in place of the specified text no? Modmail subject, comment sticky status and locking would follow the behaviour of the manual mod tooling.

[PitchforkAssistant]

Devvit's addRemovalNote function's options only include itemIds, reasonId, and modNote. Leaving a comment/modmail like on the website isn't even an option.

Although getSubredditRemovalReasons does exist, so I could add an option to populate the comment/modmail body with the corresponding removal reason text. That would mean you wouldn't have to include the text in the flair config itself, but functionally the app would still be leaving a regular comment/modmail.

[SL13PNIR]

The addRemovalNote function is just that, for adding a removal note, so I wouldn't expect it to leave a comment/modmail.

Nor do I think there's any distinction between a regular comment/modmail and one that comes from a removal reason. I think implementation will be up to the developer to use comment/modnail components available, and therefore I think as you stated:

Although getSubredditRemovalReasons does exist, so I could add an option to populate the comment/modmail body with the corresponding removal reason text.

is the correct implementation.

Going by existing behaviour of removal reason comments/modmail:

The removal reason modmail subject should state:

Your post from \<\<subreddit>> was removed

The removal reason modmail body should state:

<> Original post: <>

For a removal reason comment, obviously it's just uses the removal reason text, to keep it simple I'd make the comment locked by default.

[PitchforkAssistant]

Hmm, that would introduce the possibility of the app sending two comments or modmails. I think I would rather have it overwrite the body option under comment/modmail. That way those objects could still be used to define the sticky, lock, archive, etc behaviors.

That still leaves the question of where to add the booleans for that. It would make sense if they were under comment and modmail, but adding them under the removal reason object would ensure the ID is specified because the schema marks that field as required if the object is present.

In the config generator tool, the toggle could visually disable the comment/modmail body fields in either case. Although if it were under the removal reason section, I would need to add a feature to force-enable the comment or modmail sections based on it.

[SL13PNIR]

I think I would rather have it overwrite the body option under comment/modmail. That way those objects could still be used to define the sticky, lock, archive, etc behaviors.

Yeah that's a fair point.

Could you perhaps remove the existing removal reason toggle, and add a removal reason toggle inside both the existing comment and message groups where:

• if the removal reason toggle is true inside the comment group, it hides the comment label and input text box (where the text of the removal reason would be used in its place)
• if the removal reason toggle is true inside the message group, it hides the subject and body label and input text boxes (where the text of the removal reason would be used in its place)
• if either of the removal reason toggles are true, the group displaying removal reason id and mod log is shown with the removal reason id input text box highlighted as required
• if either of the removal reason toggles are false, the removal reason group is hidden