Why can't you move sub-projects

Robert_Davies_(unlondonadmin_-_(deleted))

Hi folks.We are having a real problem explaining to users why they cannot move subprojects between projects, and frankly using LL Explorer to move the contents into a new project isn't a good solution for us.Can someone please explain the technical reasons why sub-projects cannot be moved? And does anyone have any strategy for getting around the problem?Best regards/matt.

Find more posts tagged with

Comments

Trevor_Sharpe_(trevor_(Delete)_309647)

This is just a theory, but if you take a look at the values for a sub-project in dtree, the parentID is not the same as the OwnerID, whereas for a Project the two values are equal.Perhaps a sub-project cannot be "promoted" to a Project for this reason -- Projects are unique volumes, but sub-projects are not. And perhaps there is no way to proactively hand out volumes"But I can move folders and other types of objects, whose DTREE entries are consistent with sub-projects" you protest.Yes, but Projects are unique volumes. Folders are not. So you can't make an object that isn't a volume into a volume on-the-fly... I can't think of other times when you can promote non-volumes to volumes, so I can't refute my arguement.Hopefully my response will spur someone who *really knows* to reply.If I get a real answer, I'll post it here as well.

Trevor_Sharpe_(trevor_(Delete)_309647)

Well, the bad news is that I was completely wrong.The good news is that someone "in the know" set me straight(er).They explained that copying or moving a sub-project introduces all sorts of issues with respect to permissions, users access, etc. For example, if I copy or move a sub-project outside of the parent, does it retain the same users access as the parent project, or does it only get the existing sub-project participant list. Does the sub-project get users perms from the located where it is being moved.To further compound the issue, a Project is less tangible than say, a folder, or document. Thus it makes it difficult to adequately address expected behaviour -- if I move this or copy it, I would expect that ________ will be the result.If anyone cares to articulate how project copying and moving should be manifested, I would be happy to pass those comments on.Again, I may not be 100% accurate on the technical issues so the usual disclaimers apply.

Robert_Davies_(unlondonadmin_-_(deleted))

Hi Trevor,Thanks for the info, it's helpful to have a view on what's going on.But I have to say (to OTC, not to Trevor) that not including what seems to me to be essential functionality just because it requires implementation policy is hard for me to understand.Ok, there are some thorny issues about permissions and so on. Thats life! As administrator of a system I am used to such issues and having to resolve them.What I am looking for in 8.1.0 is a move project option, even if it pops up a box where I have to decide how the permissions should be altered, and so on. How about it?As to my immediate situation. Well just because it's hard and OTC don't want to include it (yet), doesn't mean my users will understand and/or stop asking for it.So disregarding the side-problems for a moment; How do I make a sub-project of one project into a sub-project of another project? Is it as simple as altering the volumeid/owner information in the DTree table? Can it be done?Best regards/matt.

John__Mackin__(jmackin_(Delete)_1201231)

On the subject of permissions and moving/copying, I'm going to stick my two cents in this thread.I agree that the ability to move/copy a project is a function that could be useful. As it is, some of our project teams need the ability to build a folder structure, with permissions, and then make a copy of it each week. Currently, when you copy a folder it inherits the permissions of the container it goes in. This hurts us for this particular need, but if it's consistent than I can live with it (it's not my project team anyways ;)However, it would be GREAT it when copying a structure like that there WAS an option to say 'Keep permission settings' or 'Inherit permission settings'. Perhaps that functionality could move up to when we can start copying and moving projects around. Or, if the ability was only available when copying sub-projects, then we'd build the template as a sub-project rather than just folders.I will say that I personally was 'bummed' when I converted our database over and I couldn't consolidate my projects into sub-projects. Since we're not a Livelink Explorer site, it's going to be difficult to ask people to move all their files around through the web interface.Okay...maybe that was 5 cents.-J

TCPLAdmin_(Delete)_1433496

We ran into this and got the same explanation at TransCanada, which we vigorously objected to. The end users expect ( nee demand ) the ability to move sub-projects around. How persmiisions issues will be affected is secondary. The end users universally shake there heads in bewilderment when we explain the product hasn't been designed to allow it.I started to do some experiments when this first happened to see what was going on, and found that some of the problems are due to permissions problems of the 'mover'. Sometimes, if you were logged on as Admin, you had enough power to do the move. In cases where that wasn't possible, the laborious method of moving the individula folders, Task Lists etc. to another Sub-Project created where needed was the only way. ( We don't have Livelink Explorer either - we believe it should be included as part of the standard package as that functionality existed in Livelink in version 3 and was taken away in version 7 and then re-introduced as a Livelink module )I add our voice to a strong request for the ability to treat Sub-Projects like any other node object. Otherwise it is entirely inconsistent with the whole concept Livelink employs elsewhere. If there are permissions issues, lets figure out what we need to address them and move forward.