currently i've manage to post into strapi, but i cant set post status to draft. I am using graphql, and there is no post status in mutation. what I have to do?
thanks.
The way that I found to do that is just passing the property published_at as null when perform the mutation.
published_at is a default property that strapi assign to each collection.
For the query
mutation CreateRecord (
$recordName: String!,
$published_at: DateTime
) {
createComment (input: {
data : {
recordName: $recordName,
published_at: $published_at
}
})
}
and when is time to send the values
createRecords({
variables: {
recordName: "I am a new record saved as draft"
published_at: null
}
});
What version of Strapi are you using?
The Draft & Publish feature has been released recently. You should definitely give it a try: https://strapi.io/blog/announcing-a-new-draft-and-publish-feature
Related
I have a useQuery that returns data of the first item inserted. For context, I have an ecommerce website with grocery products, suppose I add an apple with quantiy of 4. Next, when I add another order with quantiy 10, it adds correctly in the database and I get correct results in the apollo playground. But when I am pulling data using the below code in Apollo client it has all the orders of that user with different order ids but has the quantiy of the first order made for apple.
const { loading, error, data } = useQuery(queries.GET_USER_ORDERS, {
fetchPolicy: "cache-and-network",
variables: {
userId: currentUser.uid,
},
});
Graphql query:
const GET_USER_ORDERS = gql`
query Query($userId: String) {
userOrders(userId: $userId) {
_id
userId
products {
_id
name
price
orderedQuantity
}
status
createdAt
flag
total
}
}
`;
So essentially I am seeing all products, but with quantity of 4 for each. How can I fix this?
Change fetch policy
fetchPolicy: "no-cache",
also check if you are updating this query result after new order placing mutation (if you are it may cause updating with wrong values )
if you set fetchPolicy: "no-cache" you don't have to update query result after mutation
I'm starting to use GraphQL API and I've seen that the mutation createIssue was recently added but I don't know how to use it. I've tried the following but I'm getting errors:
mutation {
createIssue(input:{
repositoryId:"XXXXXXXXXXXX",
assigneeIds:"XXXXXXX",
title:"TestIssue",
body:"Not able to create an issue"})
}
You need first to get the repository id using the following request:
query FindRepo {
repository(owner: "johndoe", name: "awesome-repo") {
id
}
}
Then you call the mutation request by replacing the id you've got in the response in repositoryId field :
mutation CreateIssue {
createIssue(input: {repositoryId: "[ID from previous call]", title: "TestIssue", body: "Not able to create an issue"}) {
issue {
number
body
}
}
}
You can try both call in the graphql explorer and running first the FindRepo request and then CreateIssue
Or you can do it like this:
As the previous answer said, you have to find the repositoryId first, or you will met the error in the image.
And further more, when you have any issues finding a way to do mutation or query, you can find your answer in the Doc section in the right of the github explorer.
I am using Graphql within AWS AppSync. I can create items with no issues but when i try to delete one i get this error.
ConflictUnhandled - Conflict resolver rejects mutation.
i am using
deleteFavorite(input: {id: "ce8dfa4c-ef87-492e-9a87-f17d2f0b06c8", _version: 1})
from this auto created mutation
export const deleteFavorite = /* GraphQL */ `
mutation DeleteFavorite(
$input: DeleteFavoriteInput!
$condition: ModelFavoriteConditionInput
) {
deleteFavorite(input: $input, condition: $condition) {
id
productID
useremail
userID
_version
_deleted
_lastChangedAt
createdAt
updatedAt
}
}
`;
The answer was to make sure i was passing the same _version back to the delete rewuest
I'm struggling to figure out how this should work. I have an application that has a current user, so, the topmost query looks like this:
query AppQuery {
currentUser {
id
email
...Account_currentUser
...AccountEdit_currentUser
}
}
AccountEdit_currentUser is defined this way:
export default createFragmentContainer(AccountEdit, {
currentUser: graphql`
fragment AccountEdit_currentUser on User {
email
name
nickName
}`
})
on the AccountEdit component. That component commits this mutation:
mutation AccountEditMutation($email: String!, $name: String!, $nickName: String!) {
updateAccount(input: {email: $email, name: $name, nickName: $nickName}) {
accountUpdated
currentUser {
id
email
name
nickName
}
}
}
After that happens, the server returns the correct values for email, name, nickName, etc. How should those new values end up in the store? Because it doesn't seem to automatic. Do I need to write a custom updater? and update config? I tried it a few times but I couldn't get anywhere close to something that even throws a reasonable error.
This updating of the store happens automatically and the reason why it wasn't is because the node_ids of the current user in the original query and on the subsequent query were different. Once I made them the same, it started working.
I am working on a webapp with a nuxt/vuetify/apollo frontend. The backend is a strapi (v3.0.0-beta.18) server with a graphQL endpoint and a mongoDB database (v4.2.2)
It could be a newbie question since it's my first graphql project. I have a query for a collection called tags. It looks as follows:
query Tags($search: String, $selected: [ID], $limit: Int) {
tags: tags(
limit: $limit
sort: "score:desc"
where: { name_contains: $search }
) {
id
name
description
type
}
selected: tags(where: { id_in: $selected }) {
id
name
description
type
}
}
That query is returning every result that should be filtered by the where object, while the sort and limit filters work. The behavior is the same in my frontend app and on the graphQL playground. Am I missing something?
Note that strapi Shadow CRUD feature is enabled.
It turns out that I missed one of the breaking changes when upgrading strapi to the latest version. The mongose connector changed its name: https://strapi.io/documentation/3.0.0-beta.x/migration-guide/migration-guide-beta.17-to-beta.18.html