This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Need an API to disable cut/delete/rename actions for a selected fileobject in the VCS filesystem | ||
---|---|---|---|
Product: | platform | Reporter: | Sadhana Rau <sadhana> |
Component: | Nodes | Assignee: | t_h <t_h> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | asunhachawee, mentlicher, sdeng, tstupka |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 18177 | ||
Bug Blocks: | 22143, 17795 |
Description
Sadhana Rau
2001-03-09 22:30:42 UTC
This would need some support from Open API. Therefore reassigning the issue there. Why the regular delete/rename cannot not work? IMHO it should be supported, it would be consistent with the rest of the ide. Really can't see a reason why delete/rename should not work. In TeamWare, there is a notion of the "history file" for each file that is put under version control. It becomes problematic when we try to have the regular IDE functions (such as Cut/Delete/Rename/Paste) apply to these files under version control. For example - Does Cut/Delete try to cut just the clear file, or should it remove the entire history file as well? We decided that overloading these IDE functionalities may result in dangerous situations for the user since they might not know what the implications of their actions are. Sure, we could pop up a warning dialog "Your history file will be deleted", though this would most likely not be read. so we would rather them use the explicit TeamWare commands to do the "Rename", "Delete from TeamWare", or "Move file(s) and history". So, this is our reasoning for not wanting to enable Cut/Delete/Rename. I don't think this is an invalid request. Please reconsider this. Thanks. Jarda, please elaborate on why you have marked this as invalid. It sounds like a reasonable reuest. thanks, Kartik kartik.mithal@sun.com Here is an example of why I need to disable cut/paste for my filesystem. Cut/paste action implies moving files around. For TeamWare FileSystem (aka TeamWare workspace) moving files within the same workspace is allowed but across TeamWare workspaces and outside the workspace is not allowed. Files are transferred between workspaces via the workspace transactions like bringover and putback. In this case, to correctly support this model for the user, I need disable cut/paste for the TeamWare file system. Looking at the current APIs, we have following APIs for DataObject : isRenameAllowed isCopyAllowed isMoveAllowed isDeleteAllowed But the logic of these only consults FileSystem for FileObject's file permissions and FileSystem's status e,g, readOnly file system etc. Then decides for itself if the operations are allowed. FileSystem is not given a chance to decide if the operation is allowed for a given FileObject. Can we improve the support so that filesystem can override the default logic if it wants to. Thanks, Sadhana Sorry for my delay, I tried to fix as much for 3.2 as possible... Why the moving of file out from workspace does not mean to delete it on the workspace (which would not be really done until next putback)? Anyway, I would like to hit bigger audience, I will write about this problem to nbdev. Please also refer to issue# 11237, seems like I cannot even properly overload the move (cut and paste) action between two file systems. Currently my filesystem.transfer.move implementation , only supports moving files within the same filesystem. For my filesystem in addition to moving the clear file , I also move the history file. So I have to provide my own implementation of move method and cannot use the default implementation , by returning false. Target milestone -> 3.3 Everytime I think about the problem I feel that this is not issue in communication between FS & DataObject, but FS & Explorer. The filesystem can have different expectation and add-ons for behaviour of explorer (new paste types, etc.) and I guess that allowing some hooks in explorer is the right way how to solve this (and a lot of others) problem. Explorer API should introduce an "controler" interface to allow anybody else to plug in its own implementation and modify the set of enabled actions, paste types, etc. Note: The change should be probably done in cooperation with rewrite of Action API. Target milestone -> 3.3.1. Assigned to 17597 owner ... Guys, this issue can be solved by using Looks API (special nodes for objects on VCS FileSystem). So let this depend on issue 18177 and finish looks API before we go on solving this issue. Reassigning, looks and nodes are out of my responsibility at this time. Changing target to 4.0, due to dependency on looks. change subcomponent to nodes. Taking over the node bugs from phrebejk. Reassigning to new module owner Tomas Holy. I guess new VCS support does not need it, right? |