enable api to handle osc meta -e for attributes

[lethliel]

It is not possible to edit attributes with osc in the way like project meta or package meta can
be edited.

For example:

osc meta -e prj

for the attributes you have to do something like this:

osc meta attribute --attribute 'OSRT:Config' --set 'a very long list'

Describe the solution you'd like
I want the API to be consistent on all meta data

Describe alternatives you've considered
Working the problem around in osc using single POSTs to create each attribute entry.

Additional context
@adrianschroeter suggested to open an issue and fix the API instead.

[vpereira]

Does the backend store it as XML? Because I don't see a way via API to get the attributes of a project in one XML i.e dosc api '/sources/$PRJ/_attributes'

[lethliel]

Yes the backend stores is as one xml

[jberry-suse]

Part of this could be solved by changing the request type from POST to PUT to be consistent. After which I would expect the following to work fine.

osc api -e /source/openSUSE:Leap:15.1:Update/_attribute/OSRT:OriginConfig

Whereas right now the GET works and loads an editor, but saving results in a 404. :/ This is further aggravated by the web interface not properly exposing edit ability to those who are not maintainer, but can edit via API.

[adrianschroeter]

On Dienstag, 16. Juli 2019, 16:58:55 CEST Jimmy Berry wrote: Part of this could be solved by changing the request type from `POST` to `PUT` to be consistent. After which I would expect the following to work fine. ``` osc api -e /source/openSUSE:Leap:15.1:Update/_attribute/OSRT:OriginConfig ```

we could support PUT in addition, but not replacing the POST functionality, because the POST content can be selected attributes. while PUT would drop also the ones not part of the body (after permission checks).

…

-- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: [email protected]

[jberry-suse]

we could support PUT in addition, but not replacing the POST functionality, because the POST content can be selected attributes.

It's fine to support both, but it is also a bit squirly to require restating the attribute given it is already required in the the path. I would not expect to be able to POST and update multiple attributes from a path such as /source/<project>/_attribute/<namespace>:<attribute>. From /source/<project>/_attribute perhaps, but not when I already specified a specific attribute.

Supporting PUT would certainly be a step in the right direction.

[adrianschroeter]

On Dienstag, 16. Juli 2019, 17:32:34 CEST Jimmy Berry wrote: > we could support PUT in addition, but not replacing the POST > functionality, because the POST content can be selected attributes. It's fine to support both, but it is also a bit squirly to require restating the attribute given it is already required in the the path. I would not expect to be able to `POST` and update multiple attributes from a path such as `/source/<project>/_attribute/<namespace>:<attribute>`. From `/source/<project>/_attribute` perhaps, but not when I already specified a specific attribute. Supporting `PUT` would certainly be a step in the right direction.

problem is that each attribute is an own object and has different permission. but yes, the current attribute api is not really sane ...

…

-- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: [email protected]