ESI - Endpoint for Corporate Hangar Divisions for non-Directors please?

EVE Technology and Research Center Third Party Developers
1

Hey there CCP,

Is it possible to add an endpoint to the swagger interface that allows to list assets from a specific hangar name/ID for people that do not have a Director role assigned?
It would definitely enable some corp officers to aggregate asset data in one place for corporation project use, especially with the Project Manager getting it’s own role for Opportunities :wink:

In essence - an endpoint that lists specific corporate hangar contents in various locations if the authorized character has access to see what is inside those specific hangars.

2

How would you know those locations ?

How would you make the path accessible so that the ESI cache works correctly ?

In Sinq Laison, I believe this is too much work. Much more than you present it.

Currently to get corporation assets :
the path is corporations/corpid/assets EVE Swagger Interface
When accessing the resource, it checks that you are connected and your character corporationid matches the path variable corpid, then that you have the correct scopes in your token and roles in your corp.
Then the resource is fetched if cache miss, then returned from cache .
The fetch select all assets whose owner is the corporation.

What would be the process for that new feature ?

3

This endpoint works, but ONLY if you have the Director role.

image
image1273×1014 81.7 KB

The thing is corporations can have ranks that are allowed to see certain corp hangars, but not others (which is fine) - but the only way to get a list of corp assets is to get them ALL or none at all. You cannot use ESI to grab only assets your character has access to see. This makes things difficult sometimes, because only a corp director could use that ESI endpoint, and sometimes it might be too much priviledge to give to a player depending on what a certain corp hangar would be used for.

iirc corporations in eve have a limited number of hangar dividers which they can rename, so specifying a corp ID, the number of the hangar and then checking for role authorization for that could give us that solution.

4

I totally understand your need and agree with it.
What I’m asking for, is a more in depth description of what could be implemented.

For example, if the data access is varrying with the groups, you need at the very least to be able to list those groups.
Then to have esi resources for which the path contains the id of those groups, to make the cache work.
Then to get a correct query for the fetch.

For example, the 1st corp hangar are represented as a flag CorpSAG1 on an asset. BUT that’s only for the top level : a corp hangar that contains containers will require more complex queries.

5

I am not sure how to implement this, hence I’ve asked if it’s actually even possible :smiley:

6

I’m not asking you to implement it, but to give formal requirements.

The general goal is to have asset access to people who are in specific groups, without the need for director role.

Let’s start by the simplest : what would the variable be ? What would the result be ? I believe at least corporation and sub group id would be required, while the return would be the same as for present assets/ ?

7

I think that specifying a role/subgroup inside the corp would be unnesecary, only the corp ID and hangar division number (1-7). Since our characters have roles that allow them to access to certain Hangar Divisions the endpoint can check for that and either retrieve the request or retrieve an “error: character not authorized” as it is with the Director role now.

so again, we specify as variables:

  • corporation ID
  • number of the hangar division we want to access

in return we receive:

  • a list of corporation assets in that hangar division including:
    is_blueprint_copy, is_singleton, item_id, location_flag, location_id, location_type quantity, type_id (as it is in character asset fetching)
  • OR an error “character not authorized”
8

ok so the group would be the division right ? And instead of director role required, you would only need that the user would have the role to “Hangar_Query_1” for division1 on the “other”, “hq” AND “base” on his titles (EVE Swagger Interface ) or personal roles ( EVE Swagger Interface ) . Of course having the director would also be good.

This means something like path : corporations/coporationid/divisions/divisionid/assets
And I guess this would return the same result type as the corporations/assets endpoint.

amiright ?

but then how to fetch the data ? the DB only have “division” for top level items.

9

Funny side story.

I’ve been snooping around a little with GESI, and it turns out that I can see corp assets I have access to when pulling my own characters’ assets. However, when queried for locations / structureID’s via Universe/Structures/{StructureID}/ for the assets that I can see there the endpoint responds with “error:Forbidden” (probably the Director role thing)

image

But I can totally see the type ID and amount of it in the character assets pull. It would now just be great to confirm the exact location for them :sweat_smile:

10

If you see a “corp asset” in your own assets, it means that asset belongs to you (you are the owner)

11

OK. So.

The “Forbidden” error is no the Director thing. And those were not the assets within the corp hangars.

That’s because the assets I wanted to access are not in a station, but in a container within the station. Running a query for those locations with /Characters/CharacterID/Assets/Locations/ returns an item ID of the container. Querying then for /Characters/CharacterID/Assets/Names/ gives the names of the ships or cans that the thing was in.

So we’re back. :stuck_out_tongue:
@stefnia_Freir Can you elaborate on " the DB only have “division” for top level items."?

12

an item is a line with its parent location (can be a system for corp structures), its state (packaged/not) , quantity if packaged, owner (corporation or user id), and a flag that contains the position inside the parent location.

https://esi.evetech.net/ui/#/Assets/get_corporations_corporation_id_assets

structure 
{

is_blueprint_copy boolean
title: get_corporations_corporation_id_assets_is_blueprint_copy

is_singleton* boolean
title: get_corporations_corporation_id_assets_is_singleton

item_id* integer($int64)
title: get_corporations_corporation_id_assets_item_id

location_flag* string
title: get_corporations_corporation_id_assets_location_flag
Enum:
Array [ 121 ]

location_id* integer($int64)
title: get_corporations_corporation_id_assets_location_id

location_type* string
title: get_corporations_corporation_id_assets_location_type
Enum:
Array [ 4 ]

quantity* integer($int32)
title: get_corporations_corporation_id_assets_quantity

type_id* integer($int32)
title: get_corporations_corporation_id_assets_type_id

}]

This location_flag (actually a string) is what tells if an item is in the corpAG1 hangar, impounded, deliveries, or for example an item inside a container.

values

[ AssetSafety, AutoFit, Bonus, Booster, BoosterBay, Capsule, Cargo, CorpDeliveries, CorpSAG1, CorpSAG2, CorpSAG3, CorpSAG4, CorpSAG5, CorpSAG6, CorpSAG7, CorporationGoalDeliveries, CrateLoot, Deliveries, DroneBay, DustBattle, DustDatabank, FighterBay, FighterTube0, FighterTube1, FighterTube2, FighterTube3, FighterTube4, FleetHangar, FrigateEscapeBay, Hangar, HangarAll, HiSlot0, HiSlot1, HiSlot2, HiSlot3, HiSlot4, HiSlot5, HiSlot6, HiSlot7, HiddenModifiers, Implant, Impounded, JunkyardReprocessed, JunkyardTrashed, LoSlot0, LoSlot1, LoSlot2, LoSlot3, LoSlot4, LoSlot5, LoSlot6, LoSlot7, Locked, MedSlot0, MedSlot1, MedSlot2, MedSlot3, MedSlot4, MedSlot5, MedSlot6, MedSlot7, MobileDepotHold, OfficeFolder, Pilot, PlanetSurface, QuafeBay, QuantumCoreRoom, Reward, RigSlot0, RigSlot1, RigSlot2, RigSlot3, RigSlot4, RigSlot5, RigSlot6, RigSlot7, SecondaryStorage, ServiceSlot0, ServiceSlot1, ServiceSlot2, ServiceSlot3, ServiceSlot4, ServiceSlot5, ServiceSlot6, ServiceSlot7, ShipHangar, ShipOffline, Skill, SkillInTraining, SpecializedAmmoHold, SpecializedAsteroidHold, SpecializedCommandCenterHold, SpecializedFuelBay, SpecializedGasHold, SpecializedIceHold, SpecializedIndustrialShipHold, SpecializedLargeShipHold, SpecializedMaterialBay, SpecializedMediumShipHold, SpecializedMineralHold, SpecializedOreHold, SpecializedPlanetaryCommoditiesHold, SpecializedSalvageHold, SpecializedShipHold, SpecializedSmallShipHold, StructureActive, StructureFuel, StructureInactive, StructureOffline, SubSystemBay, SubSystemSlot0, SubSystemSlot1, SubSystemSlot2, SubSystemSlot3, SubSystemSlot4, SubSystemSlot5, SubSystemSlot6, SubSystemSlot7, Unlocked, Wallet, Wardrobe ]

13

I believe these endpoints would be how we fetch the can names inside corp hangars:

image
image1261×81 12.9 KB

This also kinda means that we would need 2 new endpoints for those as well, like:
/corporations/corporationID/hangardivision/assets/locations
/corporations/corporationID/hangardivision/assets/names

However does this mean that it would basically copy data from the all-around endpoint? That would be bad.
This would need to change the whole system then, hopefully not interfering with the old URL - if you do not specify a hangar division number all assets will be attempted to be retrieved. Though I don’t really know how this works exactly.

14

names doesn’t work for some types.
typically small container naming returns an error ^^

locations return your structures IIRC.

Well You’re asking for a new feature so yes it needs to copy the data partially.

And no, you don’t want people from outside the directors to list the structures. naming is fine-ish but listing structures is not.

15

Looks like the whole corp system would need a touch up ;d Unless it’s fine from the standpoint that only assets in specific hangars would be visible, meaning that if a hangar has zero assets at a location that location doesn’t get retrieved.
Although then it’s on the corporation to put stuff in the correct space and we know how that ends sometimes ;d

16

No, it’s a matter of security.
Don’t change the corporation locations. Nobody must know a structure unless they are director.

This idea of giving access to something restricted under a lower restriction is a privilege escalation. This idea is a bug. You remove it from your head please.

Also having access to names or locations is a completely different feature (though related). IMO the locations path and the naming path would both require rework indeed, but with ADDED required actions to enable that visibility.

17

Yep, a specfific structure or location ID array (since that contains cans) would be needed as a variable in the query then. However HOW those IDs would then be obtained is kinda problematic (not the stations, but the containers)

UNLESS the roles also specify which structures a member has access to view. That would even enable in-game corp-asset search for non-directors I think. It would also make role setup so granular for some corporations that I doubt people would like to do it :smiley:

18

No, it’s more complex

You cannot give access to something that is not accessible now. Doing so is a privilege escalation.
For example, if you don’t have access to my assets, being granted access to them with an update is privilege escalation : what you cannot do now, you can do later without the specific requirement from the admin (=directors, or me for my assets). This is a critical security breach.

Whatever the resource is, it must never become easier to access with a patch.

You can however give a way to allow those accesses . Typically for locations, you can add a flag for each structure and division, telling if a corporation member which has access to that division can list that structure .

The important part is that this is an opt-in modification : by default structures don’t have any visibility
Then you can add a corporations/id/divisions/id/locations path that lists all the corporation’s locations that have that flag. But AGAIN this is a different topic.

19

I see, that makes sense. Regardless, a feature like that would help people out for sure, but I get that there would be a lot of additional stuff CCP would have to do to make it happen.

20

Indeed, devil lies in details.

Also the main feature would still not work, because it needs to fetch the items recursively :confused:

(more precisely, to only fetch the items in a corp hangar you would need to execute a 7-join query IIRC while you don’t even need a query to get all items in corporation)

Typically to get the division1 root items :
select * from items where owner=corpid and location_flag=corpag1

to get the second level :
select child1 from items parent
join items child1 on child1.location_id=parent.item_id
where parent.owner=corpid and owner.location_flag=corpag1

etc until the max level reachable (IIRC it’s 7: in a corp can you can place a ship with another ship inside with can that contains items … maybe it’s 5 only )

Meanwhile to get corp assets it’s the first one without location_flag