VENs removed from targets in program content

[benjaminvadurel-tri]

When a program is created at the VTN level, the VENs in the "targets" attribute are extracted and stored in the "ven_program" table. However, when a program is requested, the associated VENs are not retrieved from the table and not included in the response.

Is this the desired behavior ? Shouldn't the VENs be included in the targets attribute ?

[pohlm01]

Thanks for that question, it's a very valid one. I was searching our documentation if I wrote it down somewhere, but it seems that I never properly documented that 🙈.

The reason is as follows. The OpenADR 3.0 specification does not have any way specified that allows to limit access of programs or events to specific client logics (also referred to as VEN clients). Similarly, all client logics can read all reports and recourses created by anyone. To us, this was a fundamental flaw in the design, which is why we added our own, slightly non-standard compliant access restrictions on top. One of such is to use the VEN target to limit access to that program (and all events thereunder) to only the specified VEN clients. Apparently, this also causes the VEN target to disappear from the list of targets specified when retrieving back the program. This is not necessarily what we wanted and due to the fact that we store the VEN link differently in the database to allow efficient access lookups.

Currently, we are busy implementing OpenADR 3.1, which has introduced a system they call 'object privacy'. This is not really the same as we implemented for 3.0, but tries to accomplish similar goals. Therefore, we remove our custom-made (stricter) access control and replace it with the specification compliant 'object privacy'.

For your problem: Did it become somewhat clear, why we behave the way we do? What would be your ideal situation given that new information? Can you wait for the OpenADR 3.1 implementation, or would you need version 3.0 patched? Please note, that right now, we plan to support only 3.1 as we are not aware of anyone requiring 3.0 support. Please let us know if you need support for 3.0, so we can check what's possible.

[pohlm01]

@benjaminvadurel-tri Any feedback on that?

[benjaminvadurel-tri]

Thank you for your explanations, which quite confirm what I thought.

Currently, our work is only limited to OpenADR 3.0 only, and there are no plan on implementing 3.1 on our side. However, there is no urgency for a patch. Currently, I have the openleadr dependency locally in my project and i did a workaround : in openleadr-rs/openleadr-vtn/src/data_source/postgres/program.rs, I insert the original "target" attribute instead of the one with the VENs extracted. Definitely not the best solution as VEN targets are stored twice in the database (in the program table and the ven_program table).

I think the best fix for this would be to retrieve the VENs associated with the program in the ven_program table and append them to the targets attribute when retrieving a program.

Since you are currently busy implementing 3.1, I can provide a patch for this issue during this week.