esi-issues
esi-issues copied to clipboard
esi
suggestion for an accesslists endpoint
obviously authed only endpoint
-
[ ] GET /accesslists/ return all accesslist_ids visible ingame
-
[ ] POST /accesslists/ create a new accesslist, possible fields: name, description
-
[ ] GET /accesslists/{accesslist_id}/ return accesslist, possible fields: id, name
-
[ ] PUT /accesslists/{accesslist_id}/ modify the accesslist, possible fields: name, description
-
[ ] DELETE /accesslists/{accesslist_id}/ delete the accesslist
-
[ ] POST /accesslists/{accesslist_id}/members/ add a member to an accesslist, possible fields: id, type, role
-
[ ] PUT /accesslists/{accesslist_id}/members/{member_id}/ modify a members role: possible fields: role
-
[ ] DELETE /accesslists/{accesslist_id}/members/{member_id}/ delete a member of the accesslist
I will add write specs and swagger specs in the next couple of hours…
EDIT: the members endpoint was redesigned to work better with typed languages
'/accesslists/':
get:
description: >-
List all accesslists a character has higher roles MANAGER or ADMIN on
responses:
'200':
description: List of Accesslist IDs
examples:
application/json:
- 1234567
- 8765423
schema:
items:
format: int64
minimum: 0
type: integer
uniqueItems: true
type: array
summary: List all accesslists a character has higher roles MANAGER or ADMIN on
tags:
- Accesslist
post:
description: >-
Create a new accesslist
parameters:
- description: Data used to create the accesslist
in: body
name: accesslist
required: true
schema:
properties:
name:
description: The full name of the accesslist
type: string
description:
description: The description of the accesslist
type: string
type: object
responses:
'201':
description: accesslist created
examples:
application/json: 1234567
schema:
format: int64
type: integer
tags:
- Accesslist
'/accesslists/{accesslist_id}/':
parameters:
- description: An Eve accesslist ID
format: int64
in: path
name: accesslist_id
required: true
type: integer
get:
description: >-
Returns information on requested accesslist, if you are MANAGER or ADMIN on the ACL.
Otherwise, returns "Forbidden" for all inputs.
responses:
'200':
description: Data about an accesslist
examples:
application/json:
name: Test Accesslist
description: ACL Description
schema:
properties:
name:
description: The full name of the accesslist
type: string
description:
description: The description of the accesslist
type: string
members:
properties:
public:
type: boolean
require: true
alliances:
items:
properties:
alliance_id:
format: int32
type: integer
role:
type: string
enum:
- BLOCKED
- MEMBER
- MANAGER
- ADMIN
type: object
required:
- alliance_id
- role
type: array
corporations:
items:
properties:
corporation_id:
format: int32
type: integer
role:
type: string
enum:
- BLOCKED
- MEMBER
- MANAGER
- ADMIN
type: object
required:
- corporation_id
- role
type: array
characters:
items:
properties:
character_id:
format: int32
type: integer
role:
type: string
enum:
- BLOCKED
- MEMBER
- MANAGER
- ADMIN
type: object
required:
- character_id
- role
type: array
type: object
required:
- name
- description
type: object
summary: Get accesslist information
tags:
- Accesslist
put:
description: >-
Change the name and/or description of an accesslists
parameters:
- description: Data used to update the mail
in: body
name: accesslist
required: true
schema:
properties:
name:
description: The full name of the accesslist
type: string
description:
description: The description of the accesslist
type: string
type: object
responses:
'204':
description: Accesslist updated
summary: Update an accesslist
tags:
- Accesslist
delete:
description: >-
Delete an accesslist
responses:
'204':
description: Accesslist deleted
summary: Delete a complete accesslist
tags:
- Accesslist
'/accesslists/{accesslist_id}/members/':
parameters:
- description: An accesslist ID
format: int64
in: path
name: accesslist_id
required: true
type: integer
post:
description: >-
Add a new member to the accesslist
parameters:
- description: data about the new member
responses:
'201':
description: member added to accesslist
examples:
application/json: 1234567
schema:
format: int64
type: integer
summary: Add a new member to an accesslist
tags:
- Accesslist
'/accesslists/{accesslist_id}/members/{member_id}/':
parameters:
- description: An accesslist ID
format: int64
in: path
name: accesslist_id
required: true
type: integer
- description: A member ID
format: int64
in: path
name: member_id
required: true
type: integer
put:
description: >-
Change an accesslist members role
parameters:
- description: data about the member
in: body
required: true
name: member
schema:
properties:
role:
type: string
enum:
- BLOCKED
- MEMBER
- MANAGER
- ADMIN
type: object
responses:
'204':
description: Member updated
summary: Update a member of an accesslist
tags:
- Accesslist
delete:
description: >-
Remove a member from the accesslist
responses:
'204':
description: Member deleted
summary: Delete a member from an accesslist
tags:
- Accesslist
Should also have PUT, POST and maybe DELETE (if that doesn't do horrible things to structures that are currently using it) endpoints for full CRUD cycle.
do you want me to write them already or is read only enough for now? if you want to implement it in one load i will take the time to write the remaining ones tomorrow :)
sorry for this taking so much time, havent found any time lately. just updated the initial post to add the remaining (?) routes, working on adding the swagger definitions now
I could really use reusable schemes here, this is a fucking mess with the members stuff in the root ^^ updated the ACLs, laptop screen sucks, probably missed something
Looking at this could we have the POST for POST /accesslists/{accesslist_id}/members/ return either a 409 or a 422 if the user already exists on the ACL.
409 is defined as
409 Conflict The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough
And seems the most appropriate, the current state being that the value exists, and the user resolution would be to change their request to a PUT instead
should it be possible to POST an accesslist with members? imo no, because it isnt possible ingame either and likely involves two different tasks on the server side fi the create accesslist methods doesnt take a memberlist
imo no, because it isnt possible ingame either and likely involves two different tasks on the server side fi the create accesslist methods doesnt take a memberlist
Let us worry about that. If you think there's a case to be made for posting a whole access list at once then make the case, and we'll figure out the cost-benefit analysis on our side and let you know if it's a problem :)
http://cdn1.eveonline.com/community/csm/Meetings/summit/CSM11-S2.pdf Page 44 Someone remind me to add a logs endpoint.
What's the status on this? It'd make life a whole lot easier for folks managing a lot of citadels with a lot of users.
+1 for this feature. Would be of great help to automatically keep standing lists and access lists in sync.
Any news on this endpoint? Just having a read-only endpoint would already be a huge help for people having to manage user access to multiple structures.
@ErikKalkoken XML Parity still has priority, but iirc @tsuthers-ccpgames has expressed his interest in getting this sorted soon™ after that is achieved.
This is really needed, larger access lists are very hard to manage manually
The XML API has been shut down last month and XML parity has long been reached. Any chance of getting this endpoint?
We are currently managing access to all our alliance structures through one access list. This works well in general, but its error prone and time intensive due to its manual nature. An endpoint just for reading an access list would already be a huge help (to identify errors with a bot), an endpoint that also includes adding and removing would be amazing.
Pretty sure every larger alliance in Eve needs to manage access to to many structures and a daily basis and would love this feature.
They are mostly in bugfixing mode for the existing endpoints, but this is still high up on the priority list for new features
If I'd have known, I'd have asked Santa to bring me this for Christmas.
In the csm summit notes i remember reading that this wasn't going to be practical to implement because of load. is it possible that this interface could submit changes that are processed later during downtime as an interim solution?
Kinda like how bank transfers take place overnight while people are asleep?
Providence copped a beating during blackout as people stopped visiting and gave up on logging in. Some kind of automation, even if it were only applied once a day would really help with quality of life issues for our NRDS region
Of course, what would be perfect is the ability to colour ships on the overview based on ACL's also, because 1000 standings slots for KOS entities hasn't been enough for years......
I think the community would already be super happy with a read-only, heavily cached (1h or more) endpoint for reading access lists. I very much doubt this would cause any load issues if implemented correctly.
The main use case is for alliance apps to verify that the right people are on the access lists, e.g. to make sure that they are in sync with the current list of blues. This is currently a manual process for alliances and a read-only endpoint would help a lot to cut down manual effort.
/corporations/{corporation_id}/structures/ teases us with profile_id of ACL profile, but there's no way to view that profile.
For my fuel expiration calendar and structures list it is a desired information.
Would love it if we hear any more updates about this. As mentioned above even if we have just read access to this from ESI every hour would help greatly that way we can have out of game apps compare to a list of blues and send out pings when one or more characters do not meet blue requirements.
I would love this endpoint because managing the accesslists of corps with lots of alts is a nightmare !
