Re: Updating a "patch" state via REST

2018-10-10 Thread Markus Mayer
On Wed, 10 Oct 2018 at 00:33, Stewart Smith  wrote:
>
> Markus Mayer  writes:
> > I am working on a script that will, amongst other things, update the
> > state ("Accepted", "Rejected", etc.) of patches in our own Patchwork
> > installation. The script is using the REST API. All requests in the
> > script, so far, are GET requests. They work fine.
> >
> > Now, I want to issue a PUT request to update the patch state, also
> > using the REST API. However, no matter what I try, the request gets
> > rejected by the server.
>
> I think you want the PATCH request rather than PUT?
>
> https://github.com/stewart-ibm/pwnm-sync is my script I use to update
> patch status (from notmuch mail tags) and that seems to be the request
> type that works for me (with patchwork.ozlabs.org)

Indeed. That works. Thanks a lot!

Regards,
-Markus
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: Updating a "patch" state via REST

2018-10-09 Thread Markus Mayer
On Tue, 9 Oct 2018 at 15:33, Markus Mayer  wrote:
>
> Hi,
>
> I am working on a script that will, amongst other things, update the
> state ("Accepted", "Rejected", etc.) of patches in our own Patchwork
> installation. The script is using the REST API. All requests in the
> script, so far, are GET requests. They work fine.
>
> Now, I want to issue a PUT request to update the patch state, also
> using the REST API. However, no matter what I try, the request gets
> rejected by the server.
>
> I have been experimenting with a docker installation of Patchwork.
> This is not the live instance:
>
> $ curl -S -i 'http://localhost:8000/api/1.0/patches/1/'
> HTTP/1.0 200 OK
> Date: Tue, 09 Oct 2018 22:23:56 GMT
> Server: WSGIServer/0.2 CPython/3.6.6
> Content-Type: application/json
> Vary: Accept, Cookie
> Allow: GET, PUT, PATCH, HEAD, OPTIONS
> X-Frame-Options: SAMEORIGIN
>
> {"id":1,"url":"http://localhost:8000/api/1.0/patches/1/","project":{"id":2,"url":"http://localhost:8000/api/1.0/projects/2/","name":"Test","link_name":"Test","list_id":"Test","list_email":"...","web_url":"","scm_url":"","webscm_url":""}
> [...]
>
> Okay, so patch 1 exists and we can retrieve information about it.
>
> First attempt to update the state:
>
> $ curl -i -X PUT -H 'Content-Type: application/json' -d
> '{"state":"Rejected"}'
> 'http://patchwork:passwd@localhost:8000/api/1.0/patches/1/'
> HTTP/1.0 400 Bad Request
> Date: Tue, 09 Oct 2018 22:22:58 GMT
> Server: WSGIServer/0.2 CPython/3.6.6
> Content-Type: application/json
> Vary: Accept, Cookie
> Allow: GET, PUT, PATCH, HEAD, OPTIONS
> X-Frame-Options: SAMEORIGIN
>
> {"delegate":["This field is required."]}
>
> Okay, so it wants the delegate field to be present. Not sure why,
> since I don't really want to set the delegate yet, but okay.
>
> Second attempt:
>
> $ curl -i -X PUT -H 'Content-Type: application/json' -d
> '{"delegate":1, "state":"Rejected"}'
> 'http://patchwork:passwd@localhost:8000/api/1.0/patches/1/'
> HTTP/1.0 400 Bad Request
> Date: Tue, 09 Oct 2018 22:25:43 GMT
> Server: WSGIServer/0.2 CPython/3.6.6
> Content-Type: application/json
> Vary: Accept, Cookie
> Allow: GET, PUT, PATCH, HEAD, OPTIONS
> X-Frame-Options: SAMEORIGIN
>
> {"delegate":{"non_field_errors":["Invalid data. Expected a dictionary,
> but got int."]}}
>
> Okay, so delegate needs to be a dictionary.
>
> Third attempt:
>
> $ curl -i -X PUT -H 'Content-Type: application/json' -d '{"delegate" :
> {"id" : 1},"state":"Rejected"}'
> 'http://patchwork:passwd@localhost:8000/api/1.0/patches/1/'
> HTTP/1.0 500 Internal Server Error
> Date: Tue, 09 Oct 2018 22:26:44 GMT
> Server: WSGIServer/0.2 CPython/3.6.6
> Content-Type: text/plain
> X-Frame-Options: SAMEORIGIN
> Vary: Cookie
>
> AssertionError at /api/1.0/patches/1/
> The `.update()` method does not support writable nested fields by default.
> Write an explicit `.update()` method for serializer
> `patchwork.api.patch.PatchDetailSerializer`, or set `read_only=True`
> on nested serializer fields.
>
> Request Method: PUT
> Request URL: http://localhost:8000/api/1.0/patches/1/
> Django Version: 1.10.8
> Python Executable: /usr/bin/python3
> Python Version: 3.6.6
> Python Path: ['/home/patchwork/patchwork', '/usr/lib/python36.zip',
> '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload',
> '/usr/local/lib/python3.6/dist-packages',
> '/usr/lib/python3/dist-packages']
> Server time: Tue, 9 Oct 2018 22:26:44 +
>
> So, does that mean that Patchwork doesn't currently support this type
> of functionality using the REST API? The error message seems to imply
> that code changes to the Patchwork core are needed to make this work.
>
> Can you provide me with some pointers where to go from here?

It starts to work, if I do this:

$ git diff
diff --git a/patchwork/api/patch.py b/patchwork/api/patch.py
index 1f0ead1f799a..f032119f17bf 100644
--- a/patchwork/api/patch.py
+++ b/patchwork/api/patch.py
@@ -81,7 +81,7 @@ class PatchListSerializer(HyperlinkedModelSerializer):
 project = ProjectSerializer(read_only=True)
 state = StateField()
 submitter = PersonSerializer(read_only=True)
-delegate = UserSerializer()
+delegate = UserSerializer(read_only=True)
 mbox = SerializerMethodField()
 series = SeriesSerializer(many=True, read_only=True)
 check = SerializerMethodField()

While a minor change, it is still a code change to the Patchwork core.
Is this an acceptable solution? If so, I can send it as a proper
patch.

Regards,
-Markus
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Updating a "patch" state via REST

2018-10-09 Thread Markus Mayer
Hi,

I am working on a script that will, amongst other things, update the
state ("Accepted", "Rejected", etc.) of patches in our own Patchwork
installation. The script is using the REST API. All requests in the
script, so far, are GET requests. They work fine.

Now, I want to issue a PUT request to update the patch state, also
using the REST API. However, no matter what I try, the request gets
rejected by the server.

I have been experimenting with a docker installation of Patchwork.
This is not the live instance:

$ curl -S -i 'http://localhost:8000/api/1.0/patches/1/'
HTTP/1.0 200 OK
Date: Tue, 09 Oct 2018 22:23:56 GMT
Server: WSGIServer/0.2 CPython/3.6.6
Content-Type: application/json
Vary: Accept, Cookie
Allow: GET, PUT, PATCH, HEAD, OPTIONS
X-Frame-Options: SAMEORIGIN

{"id":1,"url":"http://localhost:8000/api/1.0/patches/1/","project":{"id":2,"url":"http://localhost:8000/api/1.0/projects/2/","name":"Test","link_name":"Test","list_id":"Test","list_email":"...","web_url":"","scm_url":"","webscm_url":""}
[...]

Okay, so patch 1 exists and we can retrieve information about it.

First attempt to update the state:

$ curl -i -X PUT -H 'Content-Type: application/json' -d
'{"state":"Rejected"}'
'http://patchwork:passwd@localhost:8000/api/1.0/patches/1/'
HTTP/1.0 400 Bad Request
Date: Tue, 09 Oct 2018 22:22:58 GMT
Server: WSGIServer/0.2 CPython/3.6.6
Content-Type: application/json
Vary: Accept, Cookie
Allow: GET, PUT, PATCH, HEAD, OPTIONS
X-Frame-Options: SAMEORIGIN

{"delegate":["This field is required."]}

Okay, so it wants the delegate field to be present. Not sure why,
since I don't really want to set the delegate yet, but okay.

Second attempt:

$ curl -i -X PUT -H 'Content-Type: application/json' -d
'{"delegate":1, "state":"Rejected"}'
'http://patchwork:passwd@localhost:8000/api/1.0/patches/1/'
HTTP/1.0 400 Bad Request
Date: Tue, 09 Oct 2018 22:25:43 GMT
Server: WSGIServer/0.2 CPython/3.6.6
Content-Type: application/json
Vary: Accept, Cookie
Allow: GET, PUT, PATCH, HEAD, OPTIONS
X-Frame-Options: SAMEORIGIN

{"delegate":{"non_field_errors":["Invalid data. Expected a dictionary,
but got int."]}}

Okay, so delegate needs to be a dictionary.

Third attempt:

$ curl -i -X PUT -H 'Content-Type: application/json' -d '{"delegate" :
{"id" : 1},"state":"Rejected"}'
'http://patchwork:passwd@localhost:8000/api/1.0/patches/1/'
HTTP/1.0 500 Internal Server Error
Date: Tue, 09 Oct 2018 22:26:44 GMT
Server: WSGIServer/0.2 CPython/3.6.6
Content-Type: text/plain
X-Frame-Options: SAMEORIGIN
Vary: Cookie

AssertionError at /api/1.0/patches/1/
The `.update()` method does not support writable nested fields by default.
Write an explicit `.update()` method for serializer
`patchwork.api.patch.PatchDetailSerializer`, or set `read_only=True`
on nested serializer fields.

Request Method: PUT
Request URL: http://localhost:8000/api/1.0/patches/1/
Django Version: 1.10.8
Python Executable: /usr/bin/python3
Python Version: 3.6.6
Python Path: ['/home/patchwork/patchwork', '/usr/lib/python36.zip',
'/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload',
'/usr/local/lib/python3.6/dist-packages',
'/usr/lib/python3/dist-packages']
Server time: Tue, 9 Oct 2018 22:26:44 +

So, does that mean that Patchwork doesn't currently support this type
of functionality using the REST API? The error message seems to imply
that code changes to the Patchwork core are needed to make this work.

Can you provide me with some pointers where to go from here?

Thanks,
-Markus
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork


Re: [RFC] parsemail.py: Don't search for patches in replies

2014-02-11 Thread Markus Mayer
On 8 February 2014 01:29, Wolfram Sang w...@the-dreams.de wrote:

  Have you ever worked for a 10,000+ employee organization?

 I know about such things, yet we shouldn't break patchwork which is
 probably used by way more users. If your patch solves your issue, this
 is great nonetheless.

Agreed, I don't want to break patchwork for everybody else. When I
sent in the patch, I wasn't sure if there was a use case for patches
in replies or not. That's why I asked for opinions. Now I know that
there is.

 I my instance I don't need to worry about genuine patches being sent
 in replies, only comments.

 So, if you are running your own instance, you could keep this as an
 out-of-tree patch? I'd think so, but it is up to Jeremy, of course.

I'll do that if there isn't a better solution to my issue. I mostly
figured that I'm probably not the only person to have run into this
issue, so I wanted to see what other users of patchwork have to say.
Maybe there's even a way to solve the problem for everyone.

Regards,
-Markus

-- 
Markus Mayer
Broadcom Landing Team
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork