GraphQL and Draft version

[Julien]

I have…

• [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

• [ ] Regression (a behavior that stopped working in a new release)
• [X] Bug report
• [ ] Performance issue
• [ ] Documentation issue or request

Current behavior

When I have a content based on a single schema, the creation of a draft of this content leads to the display of a text present in the draft and not in the version published in GraphQL. The api retrieves the right data.

Expected behavior

Minimal reproduction of the problem

Create unique schema with a localized text field (fr, en) and publish this one. Then, in content, save the text in both languages. Create a draft of this content, change texte value and I query in graphQL/Api.

Environment

• [ ] Self hosted with docker
• [X] Self hosted with IIS
• [ ] Self hosted with other version
• [ ] Cloud version

Version: 5.7.0 (commit a07bccf)

Browser:

• [ ] Chrome (desktop)
• [ ] Chrome (Android)
• [ ] Chrome (iOS)
• [ ] Firefox
• [ ] Safari (desktop)
• [ ] Safari (iOS)
• [ ] IE
• [ ] Edge

Others:

[Sebastian]

I don’t understand your bug report to be honest.

But here is how it works:

• Basically each content has 2 representations. A published version and a draft version. As long as you do not create a draft, they are the same.
• When you create a draft all updates will be made to the draft version and the published version stays untouched.
• The API gets the published version by default, it does not matter which endpoint it is. But if you are authenticated using the frontend application (which you cannot do with a normal client) you will always get the Draft version. This is also true for the integrated GraphQL editor. You can also set the X-Unpublished=1 header to get the draft data.

[Julien]

My problem concerns the data sent back by the GraphQL party. It retrieves the string of the draft and not of the PUBLISHED version

My screen shoot shows the string data of the draft (Title Draft FR), the data of the api which is the one of the last publication (Title 1 FR) while the GraphQL query retrieves the data of the draft (Title Draft FR) with the status PUBLISHED

Maybe I didn’t understand a principle about how GraphQL works

[Sebastian]

The problem is that you make the GraphQL query over the frontend. If you would make the same query over Postman with the access token that you got for your client it should work as expected:

As I said:

This is also true for the integrated GraphQL editor.

Which means: All queries, done via the frontend retrieve the draft version.

[Julien]

Ok, I understand better. But on the GraphQL query avor the frontend, I probably wouldn’t have wondered if the status was DRAFT, so when I saw my draft data and the PUBLISHED status I thought there was a problem
Sorry for the wrong bug

[Sebastian]

@Julien

Sorry for the wrong bug

No problem.

Btw: Do you know why the “New Version” button in you top left screenshot looks so weird? The height is not correct.

[Julien]

@Sebastian

Do you know why th

Apparently it would be related to the .dropdown-toggle::after which returns to the line

[Sebastian]

Thanks, solved that.

[Julien]

With pleasure, I have a small question about the migration to angular 12 (from May 15). You tell me if I open a new support ticket or if I can have an answer directly in this discussion
I wanted to update my local version containing the migration push (621d533) and after that I had frequent errors when deleting elements (fields, content). Result, a js error and the element not deleted.
The error occurred in the confirm-click.directive.ts, before the display of the dialog ‘observers’ contains the destination and very frequently on return of the confirm ‘observers’ must return to its initial state with destination to null, so internal is null at the line const internal = (subscriber as any).destination; and the if (Types.isFunction(internal.next)) crashes at internal.next.
Any idea of the problem?
Thanks in advance

[Sebastian]

Thanks. I will have a look. The master branch is very experimental at the moment. You can either post them here in “Development” topic or in Github.

[Julien]

I thought I saw this with the master branch, that’s why I didn’t want to exceed the commits of v5.7.1

[Sebastian]

You would do me a great favor if you continue testing. It also contains a very great feature called components and I would like to release it asap.

[Julien]

First of all, sorry if my English is not always up to scratch. I’m French and I use a translator…
To be transparent, I work on a white label website generator for a client and my choice for the management of the backend is on this project that I find really top in term of techno and functioning
So, I try to fit everything I have in mind in the philosophy of your dev and I will continue to test, follow the developments and invest myself in squidex to ensure that everything works well for my client (and for me)
I’m trying to make the SchemaBuilder evolve with an ArrayBuilder because I miss this part for the initialization of an app. Or would you have a solution so that I can generate a schema at creation directly with a Json?
For the components, I discovered that yesterday and it looks very very nice but not very user friendly for the moment. The creation of a component generates 2 empty lines in the category selector which confused me at first. Then you have to understand where you can make the link with the component (which even displays the schemas so there is no filter on the components) but my big problem for the moment is that in GraphQL, I have not found how to search for a link in the component as it is proposed with the Array.

[Sebastian]

I’m trying to make the SchemaBuilder evolve with an ArrayBuilder because I miss this part for the initialization of an app. Or would you have a solution so that I can generate a schema at creation directly with a Json?

You can provide a PR for that, but In general I do not recommend to extend Squidex for such stuff and just use the API or CLI for that. I also consider to remove the templates all together.

The creation of a component generates 2 empty lines in the category selector which confused me at first.

I don’t get that. Do you have a screenshot or so?

Then you have to understand where you can make the link with the component (which even displays the schemas so there is no filter on the components)

Yes, documentation for that is missing, but In general, every schema can work as a component. It is not restricted by design.

Is that in GraphQL, I have not found how to search for a link in the component as it is proposed with the Array.

Yes, but this is a problem with GraphQL. In GraphQL you have to define each property you want, which becomes a nightmare with components, because your query becomes super complicated. So the idea is to provide the components as raw json for now in GraphQL. Otherwise you would hav to write a query like

components {
   ...on FooComponent {
     field1,
     field2
     field3
  },
  ...on BarComponent {
    ...field2,
    ...field3
  }
}

[Julien]

You can provide a PR for that, but In general I do not recommend to extend Squidex for such stuff and just use the API or CLI for that. I also consider to remove the templates all together.

My co-worker who works on this point will make a PR to propose the modification. In my use case, the client will be able to connect to the squidex backend and create a new site whenever he wants. New site that will have the initialized schemas/content. I haven’t found an “elegant” way to do this front the frontend in api/CLI but I’m open to suggestions
The best solution, I think, would be to create a front-end to drive part of the administration, but it’s not in the road map for the moment for a question of time…

I don’t get that. Do you have a screenshot or so?

I am still in version 5.7.0(push a07bccf) maybe there is a fix further in master

Yes, documentation for that is missing, but In general, every schema can work as a component. It is not restricted by design.

Ok, I had well imagined that all this was in the end schemas so I understand that there is no restriction by the design

Yes, but this is a problem with GraphQL. In GraphQL you have to define each property you want, which becomes a nightmare with components, because your query becomes super complicated. So the idea is to provide the components as raw json for now in GraphQL. Otherwise you would hav to write a query like

components {
   ...on FooComponent {
     field1,
     field2
     field3
  },
  ...on BarComponent {
    ...field2,
    ...field3
  }
}

This is indeed the observation I made on the raw json, after maybe at least add the typeName in the json to be able to make another query? I’m used to API rest and GraphQL is a novelty for me and I loved the possibility to query directly the linked schemas in one call
I have to study Queries and mutations of GraphQL now (https://graphql.org/learn/queries/)…

[Sebastian]

This is indeed the observation I made on the raw json, after maybe at least add the typeName in the json to be able to make another query?

Which other query do you wanna make? The components are directly embedded in the content.

[Julien]

If the component has a document reference to a page content for example or other, in graphQL, it seems to me that I can only have the document id without its type

[Sebastian]

That’s true, but this can only be solved in graphql with typed components anyway. Perhaps I have to introduce them as well.

[Julien]

Hence my reaction if the raw json returned the schemaId and schemaType without changing anything, the consumer of the api could know where to get the rest of the information if he wanted to

[Sebastian]

The schemaId is already part of the response and you can query content with the ID only anyway.