Requires Moderation Flag logic via API
Hi Lithium Developers, Say a moderator has the Show Moderation Required Column setting turned on and the Clear Moderation Required Flag When Message is Read setting turned on. In a custom com...
Forum Discussion
Aha. It looks like if I grab the board of my unique message, I can use the board node's messages / moderation / required API to get a list of all messages in the board which require moderation, see if my msg is in the list. If yes, show icon to those moderators who have the show icon setting enabled.
Well, looks like I still need help. I can't figure out how to use the board node's / messages / moderation / required API to match the Lithium out-of-the-box behavior with regard to the RM flag icon.
When my admin and mod user has the Clear Flag When Message Is Read setting enabled, when either of them reads the unmoderated topic, I notice the Lithium flag is cleared immediately from the Forum page. But the board node's / messages / moderation / required API list of messages still contains the topic.What I'm really after is:
1. A per-message data point to know whether my custom RM flag should be shown or not to mods/admins, next to original posts or replies.
2. A per-thread data point to know whether my custom RM flag should be shown or not to mods/admins, next to threads.
In LiQL, for 1., I'd love for moderation_status to change from "unmoderated" to some other value after a mod or admin with the Clear Flag setting enabled has read the message, or for-real moderated the message in the mod manager.
In LiQL for 2. I'd love to get a conversation.moderation_status data point in the message response which follows the same logic as the standard Lithium RM icon behavior for threads.
Is it possible that the API "updates" the response later due to caching (Lithium caches stuff internally for performance reasons), e.g. 15 mins after the moderator viewd the topic/message the API will return the correct moderation status or does it remain "wrong" forever?
But I totally agree, this is way too complicated right now for such a small thing, the API thread AND message objects just need an additonal field like "rmflag" or whatever, DougS don't you think?
