Assign values in ACL

[amolina]

Hello there,

Does anybody know if it is possible to assign a variable value to an ACL property instead of a constant value? I.e., instead of something like this:

$Self->{TicketAcl}->{'100-SomeACL'} = {
Properties => {
Frontend => {
Action => ['CustomerTicketMessage']
},
},
Possible => {
Ticket => {
DynamicField_MyField => ['SomeValue']
},
},
};

I would like to do something in the spirit of (I am asking for help so, obviously, this is not correct):


$Self->{TicketAcl}->{'100-SomeACL'} = {
Properties => {
Frontend => {
Action => ['CustomerTicketMessage']
},
},
Possible => {
Ticket => {
DynamicField_MyField => CustomerUser->UserLogin
},
},
};

Thanks.

[crythias]

You may be able to try _Value, but acl based upon a dynamic field? what's the use case?

According to what you've presented, you want the web interface to allow a customer to create a ticket only if a dynamic field is valid. Easier to do: create a "CreateCustomerTicket" group and assign it to the Module Registration for Customer ticket Message. Once customers are members of that group, they can create tickets.

[amolina]

Thank you for you answer.

The sample was a try to simplify the things and leave just the concept, but obviously I was not successful.

What we want to do is to put into a dynamic field of the ticket the information stored in an attribute of the customer opening the ticket.

Anyway, we finally have done it modifying CustomerTicketMessage.pm.

The only difficulty we are having now is that we need to display the dynamic field if we want the changes to work, so I guess that we will need to modify the tpl so the field is hidden even if SysConfig says that it should be displayed. This way the code will work and the customer will not see the field. But this is another story...

[crythias]

What we want to do is to put into a dynamic field of the ticket the information stored in an attribute of the customer opening the ticket.

Why bother? You should be able to see that information in the Customer's info as you zoom that ticket.

"We need to report on it."
OK, good answer, I guess (?) Something like this in the dtl..?
<input type="hidden" name="DynamicField_redundantfieldname" value="$QData{"CustomerField"}">

we finally have done it modifying CustomerTicketMessage.pm.

... okay.

[amolina]

Why bother? You should be able to see that information in the Customer's info as you zoom that ticket.
"We need to report on it."

There is an attribute of the customer that can change in the future (the province, they can move) but that should remain as an immutable characteristic of the ticket (the province where the ticket originated). So we need to get this information from the customer an copy it into the ticket. Also, it is manipulated so it conforms to more strict rules (the data can be in different languages in the origin, for example) so it is easier to use it in future reports.

Thank you for the clue about hiding the field.

[amolina]

Something like this in the dtl..?
<input type="hidden" name="DynamicField_redundantfieldname" value="$QData{"CustomerField"}">

This did not work, but something suggested in some other of your posts did: in CustomerTicketMessage.dtl, just before the end of js_on_document_complete I added:

Code: Select all

<script type="text/javascript">
   document.getElementById('DynamicField_HiddenField').style.display = 'none';
   document.getElementById('LabelDynamicField_HiddenField').style.display = 'none';
</script>

The only thing to consider is that the default value of the dynamic field to hide should be a valid one (in my case, it could not be '-').

[crythias]

In my *opinion*, you should ask the customer to choose the information and make it mandatory to choose.

If location is important, in my *opinion*, it should be related to the queue because I focus on agent-based queues and in my utopian world, I'd want agents to handle queues in the location(s) relevant to them.

However, Location is a tricky hybrid between customer and agent. I'm not a proponent of customer based queues because it's a real pain to manage: you have to assign agents, customers, and queues to newly created groups for new customers. Meanwhile in agent-based-queue world: Agents get new customers. Services handles it better: Customer specific services are added and applied to the new Customer. Done.

Locations, though ... this is a reasonable utilization for customer groups (but not customer queues). Here, you can assign customers in Territory A to a Customer Group. You can have a queue set attached to this Customer Group, and Agents attached to this Customer Group and therefore Territory A's Queues.
Territories are fairly static, (barring Political issues) and don't need to be changed unless you are accepting a customer in a brand new Territory. (Territory being a generic term for state/country/county/province, etc.)