Prevent copying/pasting tasks

[mfleet1973]

Hi Gang.

I'm using project 2000.

Is it possible to prevent the copying/pasing of tasks? Either by
disabling the menu options or trapping the event and displaying a
message (or any other way as long as it prevents the pasting of the
task).

Thanks a lot.

 

[davegb]

Hi Gang.

I'm using project 2000.

Is it possible to prevent the copying/pasing of tasks? Either by
disabling the menu options or trapping the event and displaying a
message (or any other way as long as it prevents the pasting of the
task).

Thanks a lot.

Project has no built in capability to limit editing other than to make
a file password protected so others can't edit at all. What is it that
you have in mind? Why do you want to limit users from this one kind of
edit? Maybe there's another approach.

 

[mfleet1973]

Thanks a lot for replying.

I wrote an application that exports data into msproject. Users can
also import data as well back into my app. The problem is keeping
track of the relationship between the msproject unique id and my
database's unique id. Right now, when a user exports into msproject,
my app modifies the "Number20" field to store the unique id that exists
in my app. I could not find a way to directly modify the unique id
field to put my db's unique id.

The problem is that when a user copies/pastes a task in msproject, the
value in that field (Number20) is also copied. Therefore, I can't
re-import because the same number is there twice in msp. Even the
"Created" date field is copied when a user does a copy/paste in msp
which I find bizarre.

I wrote a macro which copies and pastes and clears the field that
stores the unique id of my database but this is not a very solid
solution.

Therefore, blocking the ability to copy/paste would be the ideal
solution unless there is another way to maintain integrity between the
two databases which I haven't thought of.

BTW, I'm brand new to MSP and don't know anything about its features.

Thanks a lot!

 

[davegb]

Thanks a lot for replying.

I'm definitely not following what's going on here. I can't make sense
of your explanation, so I'll just ask some questions to help get us on
the same page.

I wrote an application that exports data into msproject. Users can
also import data as well back into my app.

Import data from Project into your app, or from some other app?


The problem is keeping

track of the relationship between the msproject unique id and my
database's unique id. Right now, when a user exports into msproject,
my app modifies the "Number20" field to store the unique id that exists
in my app. I could not find a way to directly modify the unique id
field to put my db's unique id.

I don't know of anyway to change a Project UID. They're deliberately
fixed.
It isn't clear to me is whether or not you've created a lookup table in
your database with both sets of UIDs so that the macro can go there to
determine the Project UID from the db UID and vice versa. Do you have
such a table? If not, would it help?

The problem is that when a user copies/pastes a task in msproject, the
value in that field (Number20) is also copied. Therefore, I can't
re-import because the same number is there twice in msp. Even the
"Created" date field is copied when a user does a copy/paste in msp
which I find bizarre.

If Number20 is in the table that is copied, it will be copied. You can
create a table without Number20 in it if you don't want it copied, but
if you're importing it back into your database, you'd need it to
determine which task it is there. So why would you not want it copied
in the first place?

The "Created" date field will be copied if it's in the table. If you
don't want it to be copied, again, create a table without that value in
it.

I wrote a macro which copies and pastes and clears the field that
stores the unique id of my database but this is not a very solid
solution.

Which field does it clear? The one in Project (Number20) or the one in
your database? How does this help?

Therefore, blocking the ability to copy/paste would be the ideal
solution unless there is another way to maintain integrity between the
two databases which I haven't thought of.

This doesn't make sense to me. If you want your macro to be able to
copy/paste data into Project, and your users to be able to copy/paste
data from Project to your database, why would you want to block
copying/pasting? Wouldn't this defeat the whole purpose of your
external database if you can't exchange data between it and Project?

BTW, I'm brand new to MSP and don't know anything about its features.

And I know even less about databases, so I may not be of much help!

 

[St Dilbert]

Pardon me, but blocking standard application functionality like
copy/paste doesn't sound like an ideal solution. Not even second best
after trying to manipulate an applications primary key (unique id)
which is just as questionable as "first choice idea" for me.

I would take a step back from seemingly apparent solutions on field
level and take a wider look at the design of the systems integration
you're trying to accomplish.

Make a decision whether there is a clear user role and functionality
distinction between MS project and your custom application ("CApp"). If
the same user groups are meant to use identical functionality (like
"add task") in both MS project and "CApp" then the integration will
always be messy - the more the functional and role overlap the more
different use cases you would have to consider and the risk of making
users of either application unhappy with restricted functionality is
very high.

I don't know anything about the assumptions that went into your effort
to integrate MSP and CustomApp, but questions that spring to mind:
Are you sure, that CustomApp really needs a proprietary unique id?
Would'nt it be possible to use MSP's unique id as a "foreign primary
key" instead? If storing more than one project file's data would be the
issue then think about creating a composite primary key of a "project
file id" and the task unique id of that file. What's the real reason
having CustomApps primary key stored back in MSP's Number20? Do you
have CustomMacro or whatever relying on it or is it just for "bug
tracking"? Can't you redistribute functionality or else so you don't
need CApps primary key stored in MSP? That should make your import
problems go away - that is, if you're not trying to keep MSP users from
adding any tasks at all (not just copy paste). Then there is a way to
know which non-unique "Number20"-import is the original one: MSP always
increases unique id - so you could implement a little logic in the
import to CApp to delete all non-unique Number20 entries except for the
one with the lowest MSP-unique id.

There are probably many more ways depending on what you are really
trying to do - I would urgently recommend some "design-sparring" with
users from both sides of your application landscape before trying to
block basic functionalities in standard applications.

No offense, maybe your situation is very special, but then there is
just not enough information available from the posting.

 

[Rod Gill]

Hi,

One solution is to make the copy /paste issue a training and process issue.
In other words, unless users remember to click and drag tasks (preserves
UniqueID) then you will have to revert to a backup copy so losing their
work.

If you don't have a big enough baseball bat for that action then you can try
copying the Task name as well. If the UniqueID doesn't work, then look for
the Task name. Again you would need training and processes to get users to
only use unique Task names with no copying of design, develop, test task
sequences.

Another way is to have a composite ID of the Unique ID and Number20 so if
they do copy/paste, they lose the original ID/Number20 key and have to
manually correct. For this to work you would need to store Project's Unique
ID in your db.

 

[davegb]

Pardon me, but blocking standard application functionality like
copy/paste doesn't sound like an ideal solution. Not even second best
after trying to manipulate an applications primary key (unique id)
which is just as questionable as "first choice idea" for me.

I would take a step back from seemingly apparent solutions on field
level and take a wider look at the design of the systems integration
you're trying to accomplish.

Make a decision whether there is a clear user role and functionality
distinction between MS project and your custom application ("CApp"). If
the same user groups are meant to use identical functionality (like
"add task") in both MS project and "CApp" then the integration will
always be messy - the more the functional and role overlap the more
different use cases you would have to consider and the risk of making
users of either application unhappy with restricted functionality is
very high.

I don't know anything about the assumptions that went into your effort
to integrate MSP and CustomApp, but questions that spring to mind:
Are you sure, that CustomApp really needs a proprietary unique id?
Would'nt it be possible to use MSP's unique id as a "foreign primary
key" instead? If storing more than one project file's data would be the
issue then think about creating a composite primary key of a "project
file id" and the task unique id of that file. What's the real reason
having CustomApps primary key stored back in MSP's Number20? Do you
have CustomMacro or whatever relying on it or is it just for "bug
tracking"? Can't you redistribute functionality or else so you don't
need CApps primary key stored in MSP? That should make your import
problems go away - that is, if you're not trying to keep MSP users from
adding any tasks at all (not just copy paste). Then there is a way to
know which non-unique "Number20"-import is the original one: MSP always
increases unique id - so you could implement a little logic in the
import to CApp to delete all non-unique Number20 entries except for the
one with the lowest MSP-unique id.

There are probably many more ways depending on what you are really
trying to do - I would urgently recommend some "design-sparring" with
users from both sides of your application landscape before trying to
block basic functionalities in standard applications.

No offense, maybe your situation is very special, but then there is
just not enough information available from the posting.

Exactly! He just said what I wanted to say, but he said it better.