The PATCH method for the entry should only update what user sent to us and not the whole entry as it was before.
Also, sending tags when patching an entry will now remove all current tags & assocatied new ones.
Listing entries can now be filtered by “public”.
Creating or patching an entry can now set is to public or remove the public.
Entry response now include “is_public” boolean field
While creating a new user using the API, we also create a new client for the current user.
So the app which just create the user can use its newly created client to configure the app.
That new client is only return after creating the user.
When calling the endpoint /api/user to get user information, the new client information won’t be return.
I've added a toggle feature (in internal settings) so that user api creation can be disabled while form registration still can be enabled.
Also, the /api/user endpoint shouldn't require authentication. Even if we check the authentication when sending a GET request, to retrieve current user information.
I've moved all the internal settings definition to config to avoid duplicated place to define them.
I don't know why we didn't did that earlier.
Objects are always passed by reference, so it doesn't make sense to
return an object which is passed by reference as it will always be the
same object. This change makes the code a bit more readable.
Entry API can now have these new fields:
- content
- language
- preview_picture
- published_at
Re-use the ContentProxy to be able to do the same using the web UI (in the future).
htmLawed is used to clean stuff from content, I hope it’ll be enough to avoid security breach.
Lower content validation when we want to update an entry with content already defined. Before, language & content_type were required. If there weren’t provided, we re-fetched the content using graby. I think these fields aren’t required for an entry to be created. So I removed them.
Which means some import from the v1 export won’t be re-fetched since they provide content, url & title.
Also, remove liberation link from Readability import to avoid overlaping import (from wallabag v1, which had the same link)
The only ugly things is how we handle error by generating the view and then parse the content to retrieve all errors…
Fix exposition fields in User entity
It allows to request to delete a tag using query string instead of body parameter (which seems to be the standard).
Instead of breaking the previous behavior, I used a generic way to retrieve parameter (which looks into request attributes, query parameters and request parameters)
Previously it was a 400 but this is more related to a real error.
Using the API user should only know the content got reloaded or not.
If reloaded: 200 otherwise: 304.
Fix controller forward in WallabagRestController.
Update PHPDoc so it is sorted the same way as others one
Duplicate all annotations test to use both api & normal way
Also, make annotation tests independent to each other
The generated error was “Unable to guess how to get a Doctrine instance from the request information.”.
I haven’t checked deeper in Doctrine (I know it was coming from the DoctrineParamConverter).
Anyway, I check for FosRest possiblity to add extra format without allowing them for every route (like it was done in the first place).
I finally found a way but it then seems all request goes to the FormatListener of FosRest so I needed to add a custom rules to match all request to be sure we don’t get a 406 error from FosRest.
Should be ok now …
As per Doctrine said in the debug tool bar:
- The field Wallabag\ApiBundle\Entity\Client#refreshTokens is on the inverse side of a bi-directional relationship, but the specified mappedBy association on the target-entity Wallabag\ApiBundle\Entity\RefreshToken#client does not contain the required 'inversedBy="refreshTokens"' attribute.
- The field Wallabag\ApiBundle\Entity\Client#accessTokens is on the inverse side of a bi-directional relationship, but the specified mappedBy association on the target-entity Wallabag\ApiBundle\Entity\AccessToken#client does not contain the required 'inversedBy="accessTokens"' attribute.
Instead of retrieve all informations about entries of a tag to just count them, we’ll count them before with a fastest query.
Also change the layout of the tag list in material design
When we remove the client, we should ensure that access_token are also removed.
To ensure that, I created a test that generated an access_token. So when we remove the client, this association should be cascaded and shouldn’t generate an error.
Also I moved some Api related stuff to the ApiBundle (like the developer controler and ClientType form)
When the association between a tag and an entry is removed, if the tag doesn’t have other entries, we can remove it.
Also add more tests for that part and ensure TagControllerTest is isolated from the rest of the test suite (finally!)
Also, retrieve tag from the request instead of the query (which will be the same but it's more easy to test).
Moved down `deleteTagAction` because it conflicted with the new action:
api_delete_tag => /api/tags/{tag}.{_format}
api_delete_tags_label => /api/tags/label.{_format}
And finally, throw exception when a tag is not found before removing it.
