Is it possible to mass archive content in a scalable fashion via API?
Adobe is wondering how they might be able to mass archive that is older than 6 months old into a private category only viewable to admins. They are looking at something that could be invoked via API so they are hoping for an API call that includes category and date.
Would this be possible with any of the discussion endpoints in APIv2?
Basically, I am trying to find out if there is any current method within Vanilla, likely through the API, that Adobe could set up a system of mass-archiving content older than 6 months.
If not, and I suppose this would ultimately be a Todd question, could that supported through some form customization or R&D work that would allow that to be possible.
Comments
-
Vanilla's only archive functionality is to put discussions into a category that is archived.
- You can create/edit an archived category over API.
- You can move a discussion to an archived category over API.
So I assume what you're asking for is a way to query for discussions whose date of last post is older than 6 months. That's a fairly basic API v2 request that could go in an upcoming release.
Is there anything else they need here?
0 -
@Linc said:
Vanilla's only archive functionality is to put discussions into a category that is archived.- You can create/edit an archived category over API.
- You can move a discussion to an archived category over API.
So I assume what you're asking for is a way to query for discussions whose date of last post is older than 6 months. That's a fairly basic API v2 request that could go in an upcoming release.
Is there anything else they need here?
Rather than actually toggling the archive I think they would prefer move it to a hidden category.
This is the task https://vanillaforums.teamwork.com/#tasks/8208084
"We would like to have an automated solution which can be invoked through API, since moving individual posts would be too much of an effort for admins to go through periodically.
I would imagine it being an API that accepts date and categories and moves all posts older than the date in those categories to an archived section of the forum to which only Admins have acces"
-query discussions older than 6 months
-move to hidden category0 -
That's not really an appropriate task for the core API. That would need to go in as an estimate for approval etc.
0 -
I would say this is a great use-case for combining API calls:
This is something that is possible with the APIv2.
- Get category list with
GET /api/v2/categoriesorGET /api/v2/categories/search. - Get the discussions for each category using
GET /api/v2/discussions?categoryID=123&dateInserted=<yyyy-mm-dd(That less than sign needs to be URL encoded) - Move the discussions one-by-one with
PATCH /api/v2/discussions/id {categoryID: newCategoryID}
0 - Get category list with
-
Adobe is also wondering the following in relation to all this:
1.The token generated for v2 APIs is tied to an account. Can the system user generate a token and share so that we are not impacted by specific people moving out of the project?
2.Would a token generated on the hub work for every node that is present under the hub?
Does APIv2 support multisite yet? Does this call we described actually work for Adobe's use case given how they use the API to manage the vast number of nodes?
0 -
1.The token generated for v2 APIs is tied to an account. Can the system user generate a token and share so that we are not impacted by specific people moving out of the project?
I'd suggest making a separate "API User" in that case rather than trying to piggyback on the System account for no good reason.
2.Would a token generated on the hub work for every node that is present under the hub?
No.
Does APIv2 support multisite yet?
I don't know what "support" means, here. Are you re-asking question 2?
0 -
For the last question I was thinking of this APIv1 end point https://docs.vanillaforums.com/api/multisites/ - I get the impression Adobe uses that quite a bit.
I guess I am trying to imagine how exactly Adobe would use APIv2 for their use case. Maybe I am unnecessarily confused.
If for example, Adobe wants to add users to a specific role on node /abc, would they need the multisite endpoint to get a list of their sites, select the correct site then modify the user's role?
Part of my problem is that for this suggestion they need to use APIv2 but I am not positive if our current endpoints sastifies what exactly it is they do. I do not know for certain what they do. I just am trying to see how this might work with a hub/node setup like theirs. Maybe the answer is "no differently".
0 -
I see. I thought you were asking for an endpoint on hub that made copies of the request and sent it to every node.
Adding APIv1-equivalent multisite support is something we can add to the 2.7 release.
0 -
I asked that Adobe give me details on which API calls they currently make with v1 to make sure there aren't any blind spots in what we are building out in v2.
I told them that there would not be a token generated at the hub that would work on every node present under the hub and they said that would be a blocker for them.
They say they "We must have a way to either use the same API token across all nodes within the hub or have a way to programmatically query the API token for a specific node by using the hub API token."
Is that what the multisite endpoint will do in 2.7?
0 -
@BrendanParm said:
Is that what the multisite endpoint will do in 2.7?No, nor is it the way it works in API v1. The docs are pretty clear about what it does: get/create/modify Node sites and run the sync. That's it.
Getting/setting an all-nodes access token is a @Todd request.
0 -
@Linc said:
@BrendanParm said:
Is that what the multisite endpoint will do in 2.7?No, nor is it the way it works in API v1. The docs are pretty clear about what it does: get/create/modify Node sites and run the sync. That's it.
Getting/setting an all-nodes access token is a @Todd request.
Okay so I am thinking once they outline to me in more detail their current process, I will have a better insight into what they're doing.
There's SOMETHING they're using APIv1 for that works for them and I'd like to believe that would work in v2 as well. I am not sure where that discrepancy will lie.
It seems more likely to me at this point that something isn't being explained properly rather than we are eliminating some key piece of functionality in v2 that Adobe relied on for their use of v1.
0 -
In API v1, the access token is global and set via config. Maybe it's been set in their hub and propagates via sync.
0 -
Adobe would still be using the APIv1 where they've already done work against it. That's why we have separate versioned URLs for calls. We will eventually get APIv2 to do things that APIv2 does, but it may do it in a different way.
In terms of synchronizing the APIv2 tokens between the hub and node I'll have to think about that. Right now they should be able to call APIv2 endpoints with the APIv1 token and they'll take place as the system user. This will be the case as long as the APIv1 addon is enabled which should be the case with Adobe.
0 -
Whoops, I was wrong about the access token working with APIv2. I think that is a valid use-case for a transition between APIs so I'll make that work.
0 -
I've got a PR open for this change.
0
