On 6 Mar 2020 3:30 pm, Kamil Breguła <kamil.breg...@polidea.com> wrote:
> I think it won't be a problem to modify this solution and store permission
> information only in the code for the API. We will not use the permission view
> table completely.
Can you expand on how you propose we manage permissions?
If we aren't using the database then we loose almost all of the benefit of FAB,
specifically around the "Security" screens where custom roles can be created
and granted very fine-grained permissions.
On Mar 6 2020, at 3:42 pm, Kamil Breguła <kamil.breg...@polidea.com> wrote:
> We have conn_id and connection_id. connection_id refers to the ID
> field in the connection table. This field is unique.
We have "id" which is unique but never shown to any user, and "conn_id" which
is not unique and dangerously similar to "connection_id". Seeing
`/connection/{connection_id}` I expected it to operate on the conn_id form as
that is what all other APIs take. Also there is no way to get connection(s) by
the string-form, which feels like a gap in the API.
> > GET xComValues: This endpoint support reading resources across multiple
> > Task Instancce by specify a "-" as a !! - as a separator is not going to
> > work. That is a valid character in task ids.
> In my opinion, we can block the creation of tasks that have the exact name
> "-". I don't think anyone consciously creates tasks with that name. However,
> this may be the result of a developer error.
What do you propose do with users that already have tasks created with this?
Rather than placing arbitrary restrictions on the allowed characters, if we
want this "multi" option we should create a dedicated end-point for it
/dags/{dag_id}/xcomValues that takes array/multiple values for task_id and
execution date pairs -- that way it is unabigious what the user intended, and
doesn't require us to break backwards compatibility.
-ash
