I can try to point the easy changes (like board or role names) but I can't know exactly what parts will need to be modified to fit your community structure.   For example, the component has a drop down to pick the destination board. In our English community all the archive boards are on the same Category, so the component requires that Category ID to pull the board's names and ID to set the destination for the archived threads. Our non English communities decided they wanted to have the archive boards inside their corresponding product boards, so I had to modify some parts of the component to make it happen.     Like I said, I'm happy to share the components but unfortunately I can't guarantee they will work on your communities "out of the box".  I'll attach the components and a brief explanation on my next reply.   Cheers! ... View more

Hi @VF_MikeHales   Not exactly, that's like a general description of how it works.   I can share with you the actual code but since it was built specifically for our community it needs a certain degree of personalization for it to work on a different environment (archive board structure, board names, roles, styling, etc).  ... View more

Hi,   Sure. It's a two part tool; we have a custom component on each of the category/board pages visible only to admins/mods where they can select a time range (two simple form date fields), the board we want to 'clean' and the destination board (or archive board). Additionally we added a few options in the form of checkboxes to archived only solved threads, or archive them by original post date instead of conversation.last_post_date.   This component then calls an endpoint and send all this information as parameters. This endpoint uses an API v2 call to pull the threads   SELECT count(*) FROM messages WHERE conversation.last_post_time <= ${endDate} AND conversation.last_post_time > ${startDate} AND depth = 0 AND board.id='${board}' Then loop through the list and move each thread individually. We add a couple of tags to preserve the original board id and mark the thread as Archived. <#assign apiResults = rest('/messages/id/${post.id}/tagging/tags/add?tag.add=Archived') /> <#assign apiResults = rest('/messages/id/${post.id}/tagging/tags/add?tag.add=source-board-id:${post.board.id}') /> <#assign apiResults = rest('/messages/id/${post.id}/move/board/id/${moveTo}?move_message.include_replies=true&move_message.ignore_notification=true') /> It might be a good idea to pull the threads in batches. For example we're processing 100 threads at a time (getting the total number of threads in scope, dividing it by 100 and then use that "page" number with OFFSET to ) <#assign resultPages = (postCount/queryLimit)?int+1 /> <#list 0..resultPages as page> <#assign postsToArchive = rest(apiVersion, "/search?q=" + "SELECT id, board, conversation, view_href, metrics, post_time FROM messages WHERE conversation.last_post_time <= ${endDate} AND conversation.last_post_time > ${startDate} AND depth = 0 AND board.id='${board}'${notSolvedQuery} ORDER BY conversation.last_post_time DESC LIMIT ${queryLimit} OFFSET ${page*queryLimit}"?url).data.items /> ... <#/list> I also added an extra step to make sure the post's conversation.last_post_time fell into the specified date range. I think there was a bug on the API call that was returning threads that didn't meet the contraints.   Finally, the endpoint returns a JSON with useful information, like the IDs of all the threads that were moved. You can choose to create a report with this information or just ignore it.   Hope that helps, let me know if you have any questions.     ... View more

Hi,   Following up on this. The 100 thread cap is a setting that the Support team can change, all I had to do was contact them and ask them to change it.   Thanks for all the sugestions anyways! ... View more