[PATCH] Clone functionality should also be available for users with TICKET_CREATE permission

[franz.mayer@…]

As described in ticket 4686#comment:14, it would be nice to enable clone functionality also for "normal" users, which have TICKET_CREATE permission. As you could copy / clone a ticket manually with TICKET_CREATE permission (by copy-paste) it should be sufficient to check TICKET_CREATE permission in clone.py.

As described in 10856#comment:6 it would also make more sense to put the clone-button on top of the properties table, since when you clone a ticket you clone all properties and not only the description.

[franz.mayer@…]

Possible patch for checking TICKET_CREATE permission and adjusting position of clone button

[franz.mayer@…]

Renaming German wording from noun "Klon" to verb "Klonen", which is more consistent (and looks better)

[franz.mayer@…]

See 5475#comment:119 for German translation improvement.

[Christian Boos]

Will check.

[franz.mayer@…]

patch adjusted to new position of edit links (see also #10856)

[franz.mayer@…]

I adjusted the patch, so it fits to new position of modify link (see also #10856). Works well with Trac 1.1.1.

[Christian Boos]

By the way, what's your take on ticket:4686#comment:22?

[franz.mayer@…]

Well, cloning is in 98% of all cases just an organizatorial thing: As we have the same bug / topic in two milestones / versions we need a clone (this would be obsolete when #4298 has been realized). In the rest of the 2% there is a bug, which was fixed, but occurs again slightly different. Say, most of the cloning it's just a developer and manager thing.

For our (closed) invironment it's no problem permitting clone-functionality with TICKET_CREATE. But I understand ecarter's point. Is it a big deal having a new permission TICKET_CLONE?

Otherwise you could permit cloning only if a user has TICKET_CREATE and TICKET_MODIFY (as you would modify an existing ticket). But it surely is not as clean as a separate TICKET_CLONE.

[Christian Boos]

Replying to franz.mayer@…:

But I understand ecarter's point. Is it a big deal having a new permission TICKET_CLONE?

No probably not, it seems like the best compromise.

But I tried the patch and I'm definitely against the new proposed placement.

The "Modify ↓" link is only there lacking a better visual alternative for jumping directly to the edit form, I'm not that happy with it either so I won't start to expand upon that, rather find a way to "fix" it.

So I went ahead an pushed an alternative (repos:cboos.git:t10948-rework-clone):

• [69f0cac1/cboos.git] Move Ticket's Modify navigation link into the yellow box.

• [4d72f04f/cboos.git] Move Ticket's Delete button to the top of the ticket box.
• [af2842ee/cboos.git] Move Ticket's Clone button to the top of the ticket box.
• [abd2cf9c/cboos.git] #10948: use TICKET_CLONE permission for ticket Clone action.

So we have something which looks like this:

Or this (if only icons are shown):

[Christian Boos]

ticket actions in the upper right corner of the yellow box (captioned buttons)

[Christian Boos]

ticket actions in the upper right corner of the yellow box (symbols only)

[franz.mayer@…]

Replying to cboos:

Replying to franz.mayer@…:

But I understand ecarter's point. Is it a big deal having a new permission TICKET_CLONE?

No probably not, it seems like the best compromise.

Agree. It's the most flexible way of permitting clone functionality.

So we have something which looks like this:

I like that, looks good and saves space!

[Ryan J Ollos]

Replying to cboos:

By the way, what's your take on ticket:4686#comment:22?

I tend to think the additional complexity of TICKET_CLONE outweighs the other arguments. For the case of public facing sites, we could require authenticated users + TICKET_CREATE, but requiring authentication might be unexpected for administrator. A trac.ini option such as require authentication for ticket clone also gets around this, but also increases the complexity of the system. I think that what I ultimately favor is pushing the changes to milestone:1.1.2 without the addition of TICKET_CLONE, and let user feedback determine whether additional restrictions are needed for allowing users to clone tickets. As hinted at in comment:23:ticket:4686, I also think that issues such as this can eventually be dealt with by some sort of fine-grained permissions that don't pollute the existing permissions system, but expose the fine-grained control to users that prefer to go that route. So far, from reading #4686, the majority seems to be against adding the TICKET_CLONE action.

Regarding attachment:t10948-klonen.patch​​, I suspect it would be easier to create a new ticket for the German translation change, that way the ticket can be routed to the German translation team. IIRC, Steffen is doing the German translation these days.

Christian, I'd be willing to test and then push the changes if no issues are found, provided you don't have time to complete the ticket in the near future. Since it involves a change to the user interface and potentially the addition of a permission, would it make sense to move this to milestone:1.1.2? This would give us time to get feedback on the repositioning of the buttons before the release of 1.2.

[Christian Boos]

Replying to rjollos:

Replying to cboos:

By the way, what's your take on ticket:4686#comment:22?

[…] I think that what I ultimately favor is pushing the changes to milestone:1.1.2 without the addition of TICKET_CLONE, and let user feedback determine whether additional restrictions are needed for allowing users to clone tickets.

Together with removing the need for TICKET_ADMIN and only requiring TICKET_CREATE? Yes, we could try that.

Christian, I'd be willing to test and then push the changes if no issues are found, provided you don't have time to complete the ticket in the near future.

I'll try to find it somewhere ;-)

[Ryan J Ollos]

Replying to cboos:

Together with removing the need for TICKET_ADMIN and only requiring TICKET_CREATE? Yes, we could try that.

Right, that's what I had in mind.

[Christian Boos]

Rebased the branch on trunk… more precisely on the branch for #11835. The changes happen to be independent so they're easy to rebase on trunk if needed, but I thought it would be nicer to look at them with newer ticket style.

Changes on cboos.git@t10948-rework-clone-1.1dev, in chronological order:

• [f44c005b/cboos.git] (#10948): move Ticket's Modify navigation link into the yellow box.
• [a6b9873e/cboos.git] (#10948): move Ticket's Delete button to the top of the ticket box.
• [ba7bac39/cboos.git] (#10948): move Ticket's Clone button to the top of the ticket box.
• [92033ec1/cboos.git] (#10948): use TICKET_CLONE permission for ticket Clone action.
• [f88ce91f/cboos.git] (#10948): some polish for the upper part of the yellow ticket box.

[Ryan J Ollos]

Retargeting tickets that I think won't be completed for 1.1.5, but please move back if I'm incorrect.

[Ryan J Ollos]

Narrowing focus for milestone:1.2. Please move ticket to milestone:1.2 if you intend to fix it.

[Christian Boos]

Related to #12685.

[Ryan J Ollos]

TICKET_CLONE permission is needed to resolve spam issue described in #13076.

[Ryan J Ollos]

Replying to Christian Boos:

Rebased the branch on trunk… more precisely on the branch for #11835. The changes happen to be independent so they're easy to rebase on trunk if needed, but I thought it would be nicer to look at them with newer ticket style.

The changes need a lot of work to rebase on trunk. Would you have time to rebase them?

[Christian Boos]

Replying to Ryan J Ollos:

Replying to Christian Boos:

Rebased the branch on trunk… more precisely on the branch for #11835. The changes happen to be independent so they're easy to rebase on trunk if needed, but I thought it would be nicer to look at them with newer ticket style.

The changes need a lot of work to rebase on trunk. Would you have time to rebase them?

Yes, I'll look into it.

[Ryan J Ollos]

Thanks. I'm planning to release 1.3.6 soon, and we can move the ticket back if the changes are ready.

[fschricker@…]

tbh I do not understand the current situation wrt this patch here. What patch can I apply to an existing 1.0 trac? And is it compatible with 1.4 (we're moving soon)?

[Jun Omae]

Replying to fschricker@…:

tbh I do not understand the current situation wrt this patch here. What patch can I apply to an existing 1.0 trac? And is it compatible with 1.4 (we're moving soon)?

The patch is not compatible with Trac 1.4+.

Clone button is always shown since Trac 1.4 if the TicketCloneButton component is enabled. As the result, TICKET_CREATE is required to create new ticket by /newticket page.

[Ryan J Ollos]

Milestone renamed