Great news! :) But the tricky part will be to determine if the parent
ticket should also be marked as seen. No?
Because the counter is computed based on TicketFlag. Not ArticleFlag.
On Wed, Jul 3, 2013 at 12:51 PM, Michiel Beijen <michiel.bei...@gmail.com>wrote:
> Sure, you can do that.
> Use ArticleFlagSet, and let the Event module run on ArticleCreate events.
> Let the module check for the correct article types first.
> Then mark it as 'seen':
>
> $Self->{TicketObject}->ArticleFlagSet(
> ArticleID => $ArticleID,
> Key => 'Seen',
> Value => 1,
> UserID => $UserID,
> );
>
>
>
>
> On Wed, Jul 3, 2013 at 11:46 AM, Bogdan Iosif <bogdan.io...@gmail.com>wrote:
>
>> Thanks for the reply, good point about new users. I'm thinking it can be
>> resolved by using a ~lazy job that corrects their situation.
>>
>> Regardless, can I mark those system articles as read through an
>> EventModule?
>>
>> ------
>>
>> I don't have a very firm position on the best approach for system
>> articles. In our situation, agents REALLY don't want to see them. For
>> AgentTicketZoom this was, fortunately, resolved by enabling filters and
>> then each agent filtered out those system articles. This calmed them down
>> but now they have a new complaint. They feel misled by the
>> tickets-with-unread-articles counter from the main toolbar. They don't want
>> it to take under account tickets that only have unread system articles. The
>> best solution would be to mark system articles as read as they are created.
>>
>> I don't think it's worth your effort to not store auto-replies as
>> articles because they can can be filtered out in AgentTicketZoom. Value
>> would be added - at least in my situation - if you can somehow introduce
>> the option to disregard system articles for unread counts.
>>
>>
>> On Wed, Jul 3, 2013 at 12:18 PM, Michiel Beijen <michiel.bei...@gmail.com
>> > wrote:
>>
>>> Hi Bogdan,
>>> The tricky thing with the read flags is that they are on a per user
>>> basis - so the only possibility is to insert read flags for all users.
>>> And if you add a user later on, he'll still see all system articles as
>>> unread, for existing tickets.
>>>
>>> I understand the issue with the auto-replies marked as unread by
>>> default.
>>> I think I even do not like per se the fact that auto-replies are stored
>>> as articles; I think it would be good to have the possibility to directly
>>> send the autoreplies, marking them of course in ticket history, but not
>>> storing them as articles, what do you think?
>>> --
>>> Mike
>>>
>>>
>>> On Wed, Jul 3, 2013 at 11:12 AM, Bogdan Iosif <bogdan.io...@gmail.com>wrote:
>>>
>>>> Hi list,
>>>>
>>>> Is it possible to write an EventModule that would automatically mark as
>>>> read system articles (OTRS auto replies, etc.) when such articles are
>>>> created?
>>>>
>>>> /bogdan
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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
