Task Summary
Remove the deprecated project feature from the backend and the database schema, following the consensus in #5172. The frontend half is tracked separately.
Scope
| Area |
What goes |
| REST resources |
ProjectResource, PublicProjectResource, ProjectAccessResource and their three Dropwizard registrations in TexeraWebApplication |
| Search |
ProjectSearchQueryBuilder, PROJECT_RESOURCE_TYPE, the project arms of DashboardResource, and the 4 project slots of UnifiedResourceSchema (24 → 20) |
| Workflow coupling |
WorkflowResource project association on create/duplicate/list, DashboardWorkflow.projectIDs, WorkflowIDs.pid |
| Config |
gui.tabs.projects_enabled and GUI_TABS_PROJECTS_ENABLED in default.conf |
| Schema |
the four tables, plus a sql/updates/32.sql migration and its changelog entry |
Tables dropped (in FK-dependency order):
public_project ──┐
project_user_access ──┼──> project
workflow_of_project ──┘
privilege_enum stays — it is shared with workflow_user_access, dataset_user_access and computing_unit_user_access.
Behaviour changes worth reviewing. Two non-project code paths read the project tables today:
| Site |
Before |
After |
WorkflowAccessResource.getPrivilege |
falls back to PROJECT_USER_ACCESS when there is no direct grant |
only a direct WORKFLOW_USER_ACCESS grant counts |
WorkflowSearchQueryBuilder private-access condition |
WORKFLOW_USER_ACCESS.UID = uid OR PROJECT_USER_ACCESS.UID IS NOT NULL |
WORKFLOW_USER_ACCESS.UID = uid |
So a workflow reachable only through project sharing becomes inaccessible and drops out of dashboard search. That is the intended consequence of removing the feature — notebook-migration-service already documents these post-removal semantics — but it should be an explicit review decision rather than a silent side effect.
Note on jOOQ. Generated sources are not committed (common/dao/.gitignore); they are produced by sbt jooqGenerate against the live database. The DDL change and the Scala change therefore have to land together, and the migration must be applied before regenerating.
Task Type
Task Summary
Remove the deprecated project feature from the backend and the database schema, following the consensus in #5172. The frontend half is tracked separately.
Scope
ProjectResource,PublicProjectResource,ProjectAccessResourceand their three Dropwizard registrations inTexeraWebApplicationProjectSearchQueryBuilder,PROJECT_RESOURCE_TYPE, the project arms ofDashboardResource, and the 4 project slots ofUnifiedResourceSchema(24 → 20)WorkflowResourceproject association on create/duplicate/list,DashboardWorkflow.projectIDs,WorkflowIDs.pidgui.tabs.projects_enabledandGUI_TABS_PROJECTS_ENABLEDindefault.confsql/updates/32.sqlmigration and its changelog entryTables dropped (in FK-dependency order):
privilege_enumstays — it is shared withworkflow_user_access,dataset_user_accessandcomputing_unit_user_access.Behaviour changes worth reviewing. Two non-project code paths read the project tables today:
WorkflowAccessResource.getPrivilegePROJECT_USER_ACCESSwhen there is no direct grantWORKFLOW_USER_ACCESSgrant countsWorkflowSearchQueryBuilderprivate-access conditionWORKFLOW_USER_ACCESS.UID = uid OR PROJECT_USER_ACCESS.UID IS NOT NULLWORKFLOW_USER_ACCESS.UID = uidSo a workflow reachable only through project sharing becomes inaccessible and drops out of dashboard search. That is the intended consequence of removing the feature —
notebook-migration-servicealready documents these post-removal semantics — but it should be an explicit review decision rather than a silent side effect.Note on jOOQ. Generated sources are not committed (
common/dao/.gitignore); they are produced bysbt jooqGenerateagainst the live database. The DDL change and the Scala change therefore have to land together, and the migration must be applied before regenerating.Task Type