Recent Discussions
Incremental data for users data
I am trying to bring USERS data incrementally though GraphQL API. The only relevant date time filter/constraints we can use is registration date, but the problem is that if a user profile is updated, we won't be getting that in incremental data based on registration date. Can someone please help me with this ? Is there some other datetime filter or constraints we should use to get this data incrementally ? Here is my current USERS GraphQL query for reference: query MyQuery { users( last: 1000 constraints: {registrationTime: {gte: "2024-01-01T00:00:00.000+00:00", lte: "2024-10-01T00:00:00.000+00:00"}} ) { edges { node { id title firstName lastName email viewHref } } } } } Thanks, Aishwarya
Unable to retrieve users using v2 API
Unable to retrieve users from /api/2.0/search?q=SELECT * FROM users endpoint though it's returning 200 response. What could be the reason? Here is the response: { "status": "success", "message": "", "http_code": 200, "data": { "type": "users", "list_item_type": "user", "size": 0, "items": [] }, "metadata": {} }
Facing issue with createTkbArticle GraphQL mutation
Hi, I am using the client credentials to make a server to server GraphQL api call to create a tkb article in one of the tkb board. But I am getting the following Error, for which I see no discussion in the forum or docs. Even Google doesn't show any results. Errors: [ { "message": "Exception while fetching data (/createTkbArticle) : lithium.util.NullArgumentException: defaultErrorType", "locations": [ { "line": 2, "column": 3 } ], "path": [ "createTkbArticle" ], "extensions": { "classification": "DataFetchingException" } } ] I am making the call from a node-express app, and just in case if it helps I am sharing the code snippet : const createTKBArticleMutation = ` mutation createTkbArticle($createInput: CreateTkbArticleInput!) { createTkbArticle(createInput: $createInput) { result { id } errors { __typename ... on NotValidPossibleValueError { message } ... on PermissionDeniedError { message } ... on InvalidHtmlError { message } ... on CustomFieldNotDefinedForEntityError { message } ... on RequiredCustomFieldNotSet { message } } } } `; const createTKBArticleVariables = { createInput: { subject: "Testing GraphQL TKB creation", body: "This article is created using GraphQL API, for testing the API itself.", // teaser: "This is a test teaser for the TKB article", // introduction: "This is a test introduction for the TKB article.", board: { id: "board:knowbler_tkb" } } }; const method = 'POST'; // const query = fetchTKBBoardsQuery; const query = createTKBArticleMutation; const options = { url: GRAPHQL_ENDPOINT, method: method, headers: { Authorization: `Bearer ${creds.accessToken}`, 'Content-Type': 'application/json' }, data: JSON.stringify({ query: query, variables: createTKBArticleVariables }) }; const response = await axios(options);
Subscription for Moderation Approved Event
Hello, Is there any subscription related to the moderation approved event, similar to the message event subscription we already have? We have a requirement where a specific set of code should be executed when a message is approved from moderation. Thanks in advance.2) Which Way is FRT Calculated? (topic or reply?). **EDIT: Appears to be Topic?? Details added:
In Community Analytics, is First Response Time calculated like: Select all TOPICS started in January, and calculate their FRT, ..or.. Select all FIRST REPLIES posted in January, and calculate their FRT --- **UPDATE:** History: A year ago, we noticed avg_thread_response_time seems to be returning "total thread response time." So, my brilliant coworker Kenton wrote a hardcore freemarker function to calculate the average. And it OFTEN aligns w/ Community Analytics: I mean, that's dang good. But leaves a few questions that led to a bit of a WTF moment. (friendly WTF moment.. just trying to wrap my head around the FRT stuff): Why are some boards really far off? (so, I investigated...) ... Looking into our internal Policy forum - System Average Response Time (minutes) Community Analytics 1,366 Kenton's Whizbang FRT Function 5,426 Community Analytics Export: (SS below) 5,426 🧐 Here's the CSV export from Community Analytics: The yellow stuff verifies Kenton's "Only get July's Topics" approach, which starts by getting all TOPICS in that date range: <#local topics_query = "select replies, post_time from messages where board.id = '${board_id}' AND depth = 0 and replies.count(*) > 0 and post_time > ${start} and post_time < ${end} limit 5000" /> And don't forget, this aligns with almost every other CA stat...😅 Let's talk about theBlue Box (old topics that received replies during this time period): I propose those in the blue box(where replies == 1) should be factored into the Average FRT... BUT, that would INCREASE the Average FRT to 26,617. See? Let's update the table: System Average Response Time (minutes) Community Analytics 1,366 Kenton's Whizbang FRT Function 5,426 Community Analytics Export: (July topics only) 5,426 Community Analytics Export: (Including blue where replies == 1) 26,617 🤦 Where is Community Analytics getting 1,366 from? (I feel like I'm missing something obvious). Unsettled, I tried a theory that got me CLOSE but not exact like previous calculations... 👉THEORY: Maybe CA is excluding the extremes? I tried a lot of exclusion scenarios, and the closest I got was this: Exclude everything above 10,000 mins, and Exclude everything below 20 mins This got me pretty close - . 1,344 minutes is close to 1,366 minutes, but is very unconvincing. Back to the table: System Average Response Time (minutes) Community Analytics 1,366 Kenton's Whizbang FRT Function 5,426 Community Analytics Export: (July topics only) 5,426 Community Analytics Export: (Including blue where replies == 1) 26,617 Community Analytics Export: (but ignoring under 20mins and above 10k) 1,344 😂 So what's right? I vote 26,617 is accurate. It's the only one that truly considers all first replies. Doesn't the "Topics" approach create a situation where many first replies are never considered? Those in the blue box weren't considered in their respective months b/c they didn't have replies. And they are certainly not being considered now. -- even if I retrospectively run the report from April 2023, I get an Average FRT of 743 minutes, which is clearly not considering that 678,620 minute response time ... But, I think the 5,426 is more relevant for day-to-day reporting and decision making. While it's technically inaccurate (e.g, because it leaves out topics that are asked in March but answered in April), it avoids the extreme outliers that slip through the cracks and skew the picture. What do you think? Is there like some simple button I'm forgetting to push? 🤪1) is AVG_thread_response_time actually TOTAL thread response time? 😬 😱
I speculated about this a year ago, but this week my intrigue was brought back to life. ...so I did some testing... Using: /restapi/vc/boards/id/PolicyInternal/metrics/name/avg_thread_response_time, I’m getting 64851 minutes for July 1st – 26th: ?date_start=2024-07-01T00:00:00&date_end=2024-07-26T23:59:59 = 64851 minutes That seems way off base…. To test, I split that in half: ?date_start=2024-07-01T00:00:00&date_end=2024-07-13T23:59:59 = 28847 minutes ?date_start=2024-07-14T00:00:00&date_end=2024-07-26T23:59:59 = 36004 minutes 🥁… 🥁 … 🥁 28847 + 36004 = 64851 Is anybody (or nobody) else running into this? Is this luck? Am I using the metrics API wrong?
