Assign Owner Based on UserLogin

[esaunders]

I know this topic has been covered in previous threads and I just want to make sure I understand my options. I have created an Activity Dialog wherein any Agent who completes the Dialog should automatically be assigned the Owner of the ticket. I understand that I can create an ACL using the UserLogin Property to compare against existing users and limit the possible Owner options. However, this method includes the overhead of creating a separate ACL for each user as well as the maintenance of more ACLs for new users and invalidating ACLs for retired users. Am I correct or is there a way to accomplish this without hard coding user values? Thanks.

[crythias]

This sounds more like a transition action than an activity dialog.

[esaunders]

The owner assignment is just one piece of the dialog, but, yes, I agree that it makes sense to extract that functionality out to a transition action. But doing so wouldn't really change the solution, right? I'd still need user-specific ACLs to check against UserLogin?

[crythias]

I'd still need user-specific ACLs to check against UserLogin?

I have created an Activity Dialog wherein any Agent who completes the Dialog should automatically be assigned the Owner of the ticket.

This happens automatically if the Activity Dialog locks as it's opened.

I don't know overall what you're trying to accomplish... allowing one agent to assign another agent as owner?

Or ... I'm not really sure what. Maybe you're trying to prevent *some* people from using the Owner tab in the ticket? (group membership)
Or Maybe you're trying to limit the agents that can be set as the new owner, somehow based upon the current owner? (Yes, ACL, perhaps)
Or maybe everyone has a fixed set of the same list of owners to choose from in the Activity dialog, and that's the owner to assign. (Transition action SetOwner Owner <OTRS_TICKET_DynamicField_ADFieldNewOwner>)

[esaunders]

Or Maybe you're trying to limit the agents that can be set as the new owner, somehow based upon the current owner? (Yes, ACL, perhaps)

This is the most correct, but the limitation should be based on the user completing the dialog (the currently logged-in agent), not the current owner. The goal of the dialog is to allow an agent to take ownership of a ticket and populate certain field values. I have another dialog that allows agents to assign tickets to other agents, but this dialog expedites that process by only allowing agents to assign the ticket to themselves (also the available fields in each dialog vary).

This happens automatically if the Activity Dialog locks as it's opened.

Sorry, I'm not sure what you mean. Can you clarify?

[crythias]

It's a dropdown on the Activity Dialog (at least in OTRSv4) Required Lock yes.

When Yes, the ticket locks to the current clicker of the Activity Dialog action.

[esaunders]

Using Required Lock looks promising and it does exactly what I want if the user completes the dialog but if instead they open the dialog by mistake and try to click "Undo & close window" after the ticket has been locked they get an "Insufficient Rights" error. I assume this has something to do with the Permission drop-down in the dialog config, but I'm unclear how that works. I've tried changing the Permission to 'owner' and 'rw' to no avail.

[esaunders]

Sorry for letting this thread go cold for a few days but I could still use some help on this issue. The Admin Manual doesn't mention the Permission field in the context of Activity Dialogs and my searches haven't turned up anything. I'm inferring from the use of Permission in other areas that it has to do with the user permissions required to actually open and complete the dialog but, for example, if I set Permission to 'owner' and then open the dialog for an unlocked ticket, logged in as a user that has full rw permissions on the queue but is not the owner of the ticket, it works fine. Still the same error if I try to Undo & Close, tho. Any insight appreciated.

[crythias]

what does system log say on undo?

[esaunders]

There are no log entries for the Undo attempt. Ticket History also doesn't give any indication.