Hi Graeme,
thank you for your nice idea. The patch works fine, even if it's not the preferred way to solve the problem.
Nevertheless, until someone implements a clean solution, I use your suggestion.
Thanks again and best regards,
Sascha
[EMAIL PROTECTED] wrote on 07/28/2005 09:52:10 AM:
> Hello Sascha,
>
> We achieved this by updating Kernel/Modules/AgentCompose.pm:
>
> sub _Mask {
> my $Self = shift;
> my %Param = @_;
> # build next states string
> + #
> + # Set default next state dependent on ResponseID
> + #
> + if ($Param{ResponseID} eq "35") {
> + $Param{'NextStatesStrg'} = $Self->{LayoutObject}->OptionStrgHashRef(
> + Data ="" $Param{NextStates},
> + Name => 'ComposeStateID',
> + Selected => 'In Progress'
> + );
> + } elsif ($Param{ResponseID} eq "40") {
> + $Param{'NextStatesStrg'} = $Self->{LayoutObject}->OptionStrgHashRef(
> + Data ="" $Param{NextStates},
> + Name => 'ComposeStateID',
> + Selected => 'Closed'
> + );
> + } else {
> + #
> + # end
> + #
> $Param{'NextStatesStrg'} = $Self->{LayoutObject}->OptionStrgHashRef(
> Data ="" $Param{NextStates},
> Name => 'ComposeStateID',
> Selected => $Param{NextState}
> );
> + #
> + }
> + #
> # build select string
> if ($Param{StdAttachments} && %{$Param{StdAttachments}}) {
> my %Data = ""> > $Param{'StdAttachmentsStrg'} = "<select
> name=\"StdAttachmentID\" size=2 multiple>\n";
> foreach (sort {$Data{$a} cmp $Data{$b}} keys %Data) {
> .....
>
>
> $Param{ResponseID} is the Response Identifier as held in the list in
> Admin Area -> Responses and the 'Selected' value is the textual
> value of the required (existing) status. As this only selects the
> default from the list, if is still possible to select another status
> if required.
>
> HTH,
>
> Graeme
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> >
> > I have a suggestion for OTRS, probably someone wants to implement this:
> >
> > When creating a response template (Admin Area -> Responses;
> > AdminResponse.pm), it would be nice to have the possibility to define
> > the next ticket state.
> >
> > For example: I have a 'CloseWithStateExplanation' template, and often
> > people forget to change the next ticket state. The result is a nice
> > explanation about the state ('closed'),
> > but the state is of course still 'open'.
> >
> >
> > Best regards,
> > Sascha Rommelfangen
> >
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
