Disable the Copy Project feature

[jerflo]

Anyone interested in discussing this feature? Here is the link to the idea within the I-Lab for more detail: https://one.workfront.com/s/idea/0870z000000XiKlAAK/detail.

I would like to learn if you or your users could benefit from this. If so, please respond in this thread.

Thank you in advance.

[CalvinFold]

We haven't seen a need yet, but could see how the issues cited could be a problem. Flexibility to turn off features is something we always advocate because it gives flexibility. Some environments need to be able to lock-down process more than others.

[SarahNa]

Hi Jeremy,

I would be really sad if this feature went away completely - maybe it would be a system or group setting if changed?

We use this to copy over projects that happen yearly. We are a property management company and have different yearly reporting and other requirements for each property; creating a separate template to use for each one every year would be very cumbersome to keep up (226 properties)!

Thanks!

[William--]

Hi Jeremy,

I can't find it right now, but years ago I did submit to the idea exchange the option to control this at the user's Access Level. For users with Plan licenses, the Access Level should determine:

• Can users create projects from scratch? (not from a template)
• Can users copy projects?

(I would add "Can users open projects from templates?" - but that can be controlled by simply not allowing template access to the user.)

There are countless times that copied projects have caused problems, because the user copied a project with an outdated workflow. But that doesn't mean that select users in an instance should not be trusted to copy projects.

Same for opening projects from scratch. For most of our workflows, we need the user to open all their projects from a template that's been provided to them, and we don't want projects that were "made from scratch" to even exist in our system. But, that is not true for a small number of trusted users. Therefore, custom Access Levels seems like the smartest solution to control how users can or cannot create projects.

[William--]

I will also take this opportunity to solicit upvotes for an idea submitted to the Innovation Lab this morning:

https://one.workfront.com/s/idea/0874X000000sYQRQA2/detail

When something is copied (any object type), we want to be able to identify from what object it was copied - both via an entry on the Details tab of the copied object, and also expose the ID/name of the original in Reporting.

[SarahWilkersonCA]

I would like the system admin to set access level for copying projects. Occasionally it is needed but most of the time we want team members to use templates instead.

Secondly, we need to track when a project is copied off of another one and what the name was. Right now it shows the project template that the original project plan was copied from so you can't tell if it was copied or if it really came right from that template.

[RandyRoberts]

I would implement this immediately. It makes more effective governance possible. I do see a need for copying, occasionally and by trusted people. The ability to control this in the access panel would be optimal.

BTW, @Jeremy Flores‚ , I'll talk about it anytime!

[AnthonyPernice]

Yes please. Between users copying old projects and admins not knowing which projects are being copied, the same mistakes can be repeated for years.

[jerflo]

Thank you for your responses @Kevin Quosig‚ @Sarah Nau‚ ‚ @William English‚ @Sarah Wilkerson‚ @Randy Roberts‚ and @Anthony Pernice‚. If we move forward with this enhancement, existing planner access levels will not have copy project enabled by default. You would need to enable it manually. You would not be required to update each user one-by-one, but rather this would mean manually enabling "copy" on existing access levels (for those who would need the ability to copy projects). Is that going to be a problem?

[William--]

Works for us; but if the general consensus from others is “we would prefer ON by default,” we could work with that too. -WE

[CalvinFold]

@Jeremy Flores‚

So to clarify, will this be at the license level (Planner/System-wide), individual (user account), or Access Level (customizable access templates) that this setting would be determined/set?

[jerflo]

It would be set at the Access Level for Planners.

[CalvinFold]

Then my only feedback is to default to "off."

I'm a firm believer that new functionality that involves access should always default to a state to mimic past behavior (i.e., before the new feature existed).

[jerflo]

I agree with you in principle that mimicking past behavior is best.

However, just so you understand and in this particular case, what I am saying is that we would have to default to "on." Meaning those who can copy projects today will no longer be able to copy projects unless you manually set their access level back to "can copy." Is this going to be a problem?

[RandyRoberts]

I think that would be my preferred choice. I think it would be better for us to have "opt-in" rather than "opt-out". We would probably only allow our "power users" to copy projects.

Thanks!

[AnthonyPernice]

Same, disabling it by default would work for me, enabling it via Access Level seems like a great option.

[SarahNa]

I'm with the disable by default group!

[ChrisBudgen]

I'd like to second @William English‚ that a more coherent solution would be preferable. It would be great if we could - per access level - define if the users is allowed to create from scratch, create by copy and/or create by template.

Because in our case we would like to limit it to only allowing creation by template to ensure that all settings are correct.

[CalvinFold]

+1 to this, @Chris Budgen‚

[jerflo]

Thanks for your feedback, Chris. Here is an idea that relates to your comment in case you haven't already voted for it: https://one.workfront.com/s/idea/0870z000000PSAfAAO/detail.

[BenettaPe]

I COMPLETELY DISAGREE - AS WE USE COPY PROJECT FEATURE - DAILY.

Now make disable as a System Administrator setting - I'd agree with.

Thanks.