You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the admin area, I propose that we build a new task-groups page rather than just updating the tasks one. We can later decide whether it's worth merging them together or keeping them separate.
The new page would have a structure similar to the current standard-user task list (in v2/tasks), with a few differences:
The relevant endpoint would be GET /admin/v2/task-group/
We should have additional UI for optionally adding query parameters to this API call:
We should not apply disambiguation to the response data.
The previous point means that we'll need a different aggregation logic, because there will be multiple copies of the same task group. We can start with "no aggregation at all" (that is, one item per task group), and then iterate on this.
We should display additional ownership information, namely which user owns the task-group (as defined in the user_id foreign-key).
In the admin area, I propose that we build a new task-groups page rather than just updating the tasks one. We can later decide whether it's worth merging them together or keeping them separate.
The new page would have a structure similar to the current standard-user task list (in
v2/tasks
), with a few differences:GET /admin/v2/task-group/
user_id
user_group_id
private
active
origin
(one of "pypi", "wheel-file" or "other" - but this first requires Addpkg_name
andorigin
query parameters toGET /admin/v2/task-group/
fractal-server#1973).pkg_name
- requires Addpkg_name
andorigin
query parameters toGET /admin/v2/task-group/
fractal-server#1973user_id
foreign-key).I would start with this skeleton, and then we can decide whether we want to add pagination or fancier aggregation or other improvements - if needed.
The text was updated successfully, but these errors were encountered: