Propose new functionalities for Decidim software
#DecidimRoadmap Designing Decidim together
Currently the GraphQL Api in decidim lacks of many desired features.
1. Lots of fields (publicly available in the web) are not available if asked via API. For example, description field for a participatory process.
2. Components needs more specific-type definitions (i.e: you cannot extract pages component content from a participatory space).
3. Individual participatory spaces and components should be searchable via slug as well (when applicable).
4. Listing participatory processes and attributes should be searchable via many attributes: find by scope, find by hashtag, etc.
5. Listing elements should be ordered in a consistent way. Ideally this order should be specified by the query.
I intent (as Platoniq organization) to continue improve the API. I'll try to stick the the contribution rules and, of course, let me know anything that you want me to improve in order to accept this and subsequents pull-requests.
The development of this proposal has finished
- Has been reviewed by Decidim Product and complies with the Social Contract
- It is funded by Generalitat de Catalunya
- Developed by Platoniq
- Available in release 0.21
Report inappropriate content
Is this content inappropriate?
7 comments
This is VERY VERY MUCH needed @microstudi thanks so much!
Conversation with Virgile Deville
@microstudi @xabier we've had a few request from our clients about this. The use case case for it is of course open data but also for external analysis also. In the case of the grand débat, where a lot of contributions are to be analyzed, more and more experiments are being implemented using maching learning and NLP to assist the synthesis. Coverage will of course be key here.
But also, we were thinking that creating private access to a more powerful API that would allow intensive request and provide access to more sensitive data to authorize users would be necessary to work on exhaustive synthesis.
Would love to have your feedback.
Pinging @moustachu too, so that he can step in the conversation.
To be more precise :
We do feel that identifying users when requesting the API could provide :
- a complete access to the content visible to the user (even in private space)
- a way to detect, authorize, block intensive usage of the API
Limitations on this matter should only be considered regarding GPDR.
This is exactly the types of cases we have in mind as well.
This proposal talks only about extending coverage so, at least, the content that is displayed as html is available in the API too. Plus adding search capabilities. We think to provide authenticated access to private zones would be the second phase. A nice addition in this regard would be to create a user page where to generate private access keys for the API.
Intensive request could be approached maybe in the server side, providing some cache methods probably. If it's just a matter of limit requests, then there are good gems for R&R that can be useful.
We (as @Platoniq) tried to raise fundings to develop the first phase but it has been withdrawn (for the moment). I'll try to update the status of this development the moment I have more information. In the meantime we probably contribute when we need some specific feature for our needs.
I endorse the above requests. What I miss most at the moment is all content from assemblies. I'd like to be able to query all components that are used in an assembly and access all their content. Right now you can only get the title/description of some components.
Conversation with Ivan Vergés
For those following this proposal. I just want to announce that this is currently work in progress and will be ready for the next Decidim (presumably) version. Coverage will include all available (read-only) public content and some search capabilities.
👏🎉
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...