Development

Unified condition engine

It would be nice to have some sort of a universal condition engine. (like in ITSM change management)

Such unified it could be used to define ACLs as well as change conditions in a centralized way. Workflows could be modeled in a simple way.

One could ether use a GUI (as used with changes yet) ore to define it config style (like the ACL definition today).

Submitted by (@yorfeix)

Voting

4 votes

User Experience

TicketACL with Info Message

I suggest you to enhance the TicketACL with a little Message option that appears in the OTRS Header if an ACL applies to a ticket. Example: -- $Self->{TicketAcl}->{'ACL with little message'} = { # match properties Properties => { Ticket => { Type => [ 'Unclassified' ], }, }, # set possible options (white list) Possible => { ...more »

Submitted by (@nilsleideck)

Voting

5 votes

Development

ACL RegExp negation (was: ACL PropertiesNot Extension)

I suggest to extend the ACLs to have an PropertiesNot available. This would allow to match for all Tickets where you need to look for a not existing value. Example: Do not aállow to close tickets if there is no service assigned. This would actually require min. 2 ACLs, where you will always have a problem with later extensions overwriting your service restrictons (beacuse ACLs do not sum up) So the new ACL should say: ...more »

Submitted by (@nilsleideck)

Voting

13 votes

IT Service Management

ACL for ChangeManagement

I suggest to extend ACL for ChangeManagement. TicketAcl is so powerful that is should it be availabel for ChangeManagement as well. Example ....$Self->{ChangeAcl}->{'0010-ACL-ChangeTemplates'} = { ........Properties => { ............Frontend => { ................Action => ['ChangeAdd'], ............}, ............User => { ................Group_rw => ['[RegExp]Emergency'], ............}, ........}, ........Possible ...more »

Submitted by (@nilsleideck)

Voting

9 votes