Just to return to the location topic for a second - you say that only Directors should know about all the structures the corp has. However corp hangars are only present in structures and stations that have corporate offices in them (as far as pos-es go you need a special addon to it that contains a hangar iirc).
The corporate offices can be viewed by any corp member via the corporation details tab. So is that really a problem? Or is it about something else?
No, you’re right that then this becomes a non-problem from the game.
It still is a privilege escalation from the API.
Also I was talking about the structures, not the offices. You can have offices in another corporation’s structure.
You are correct that you can still list the offices by hand in the game and then list the structures along with their owner corporation. This is not a function that was added in ESI.
If I understand correctly, what you want is, once retrieved the list of assets for a specific division, to resolve the location this asset is placed in.
This EVE Swagger Interface is the endpoint you use to know what structure your office is in IIRC. It requires some specific rights (station manager)
IMO the best way to solve that issue would be to drop a container named with the structure name in your own inventory. Something like Jita IV - moon 4 . IIRC that does not work for corporation assets because then the name path does not work (can’t recall which ids are ok and which are not).
What I want from this specifically is to list and aggregate assets placed in a specific corporate hangar division for the purpose of checking material stock levels for corp industrial projects. Getting to know at a glance what is available and where would be of great help.
I can do my own assets just fine, but from the perspective of a corp officer trying to run a program (but not running the whole corp) all I’m left with at the moment is visiting each station that is supposed to have materials (refineries, manufacturing structures) and copy pasting stuff from there into the sheet. Annoying but bearable for small projects, a chore for something bigger.
I agree that this is bad. Hence
So first an advice in the not-so-short term : as an indus you should have your own corporation.
But I know it’s not always possible.
Also I think I was wrong, if you have access to the structure you can use this path EVE Swagger Interface to resolve the structure, so the location of your assets (when they have the location_flag set to corpAgX).
So there should not be a need for a specific locations/ path. Only corporations/id/divisions/id/assets (which has its own issues) and names/ which does not work correctly for corporations (unless it’s been fixed in the last 4 years ?)
Let’s refine the use case :
- user calls the new path corporations/corpid/divisions/divid/assets to list his assets :
- ESI checks that the user is in that corporation, and his roles or titles’ roles grant the access to that division in the hq, base and other . Otherwise he gets a forbidden.
- ESI lists the offices of that corporation that have the flag listESIdivId set to true
- ESI then lists and returns the assets in those offices that are in the corresponding office, and recursively their children
- user rebuild his own asset forest.
- user calls the existing path EVE Swagger Interface to know what structure his roots are in when they are not static (stations).
- user calls the new corporations/corpId/divisions/divId/names/ to get the names of the assets that belong to that corporation, that division. Only work on top level containers (not on ships in containers).
- ESI makes the same checks that in the first path.
- ESI also makes the same resolution for allowed offices
- ESI list the item_id and names of the assets for wich the owner is the corporation id, the location_flag is corpagdivId, the location_id is among those allowed, and the item_id is one of those transmited
Is that right ?
There’s a problem here I think. Since the path calls for assets in a divID there should not be a location specified, nor a location should need a flag set. Hangar division names (and id’s) are the same for every office the corporation has. So for example calling for a list of assets of {corporationID} in hangar {divisionID} should return assets in that hangar in all offices the corporation has. So a location ID should be part of the returned list.
Now technically this should not be a problem since every corp member has access to a list of all corporate offices, and, if they also have query access to a hangar division - go there and see the assets for themselves.
Unless maybe they’re on a blocklist to dock in the structure of their own corp? Is that possible?
This flag is to prevent a privilege escalation. At the moment we can’t access data. So this must be opt-in.
You cannot say all of the sudden, everybody with the role to look at the div in the game, now can do it the same in ESI. Because right now, it’s not possible.
Say you give access to your bedroom to your parents, to living room to your friends, to the entrance to identified people. It may make sense that your kids access your bedroom, but this must be opt-in, you may have things that are not for kids in there.
Therefore :
So for example calling for a list of assets of {corporationID} in hangar {divisionID} should return assets in that hangar in all offices the corporation has which are opted in .
And the location id is part of the return already ? I don’t get it.
ACL only prevent the resolving of the locations in that context (call 2. )
Gotcha and agree.
As for the location part - it’s part of the return in other asset calls through ESI. If I call to return the assets of my character and am authorized to do so a location ID is part of the table returned, and I would suspect it would be the same if a Director called for a return of corporate assets.
So I guess for this part it would also return location IDs for structures that are opted in.
Of course the only part there is the locationID. To get actual location info from that ID one would still need to call the universe/structures/{structure_id}/ endpoint with that ID as a variable.
Most probably depending on the range the ID is in, it would be a structure, hangar division in a structure or a cargo container in a hangar division in a structure 
so a variety of calls would be needed depending on that.
No.
It returns only items in a structure that is opted in (see step 1.2.)
All assets retrieved have their parent. depending on the location_flag you can tell what it is in.
When that flag is corpagX (or deliveries, safety or impounded) then it means the asset is in an office at location location_id
That’s why you need to rebuild your asset forest : each tree has the location (station/structure) at its root.
Say I have a structure with id 1 and a container with id 2 in div 1, and a plex with id 3 in that container.
the structure will be present in assets with parent id as its system.
The container will be present in assets with parent id=1, location_flag corpag1
The plex will be present in asset with parent id=2, locationflag = cargo(not sure)
So if you take only those with divid=1, you will return only the container and the plex (the plex because it is a child of the container, not because it has divid=1, since it does not). Then you build your forest, there is one tree with container at its root, and the location is unknown. So you must resolve the tree location to the structure information.
yes and also the flags provided in the asset.
No need for many calls. Once you made your forest, you just need to list the roots, and find those with a good locaiton_id, location_flag location_type, and resolve those location_id .
That was step 3.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.