yongster commented on issue #17706:
URL: 
https://github.com/apache/dolphinscheduler/issues/17706#issuecomment-4524350862

   I would like to add one real-world use case from DolphinScheduler 3.2.1 and 
express interest in contributing this feature.
   
   In our company, we are using DolphinScheduler 3.2.1. When an employee leaves 
the team or transfers to another role, we need to hand over the projects 
created by this user to another user. In practice, the expected behavior is not 
only granting another user access to the project, but also transferring the 
project owner/creator relationship so that the new owner can maintain the 
project naturally afterwards.
   
   Currently, 3.2.1 does not provide this capability from the UI/API side. The 
workaround is to manually update database records, which is risky because 
project, workflow, task, schedule, datasource, namespace and permission-related 
records may be involved, and it is easy to miss some related tables or break 
permission consistency.
   
   We have added a similar capability in our internal version and would like to 
contribute it back to the community. Before preparing a PR, I would like to 
confirm the preferred direction with the community:
   
   1. Should the implementation mainly follow the owner-permission approach 
proposed in this DSIP, decoupling project permissions from the creator field?
   2. Or should the transfer operation also update creator/owner fields for 
important related resources such as project, workflow definitions, task 
definitions, schedules, datasource and namespace records?
   3. For historical records and runtime instances, should we keep the original 
creator for audit purposes and only transfer the active maintainable resources?
   
   My preference is to avoid rewriting historical runtime/audit records, but 
provide a safe project handover API/UI for active resources and permissions, so 
users no longer need to modify the database manually.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to