MS Outlook improvements for 1.4.1 shows only empty fields

[laszlo.elbert@…]

Dear Ryan,

I updated the e-mail template by replacing the ${ticket_props} as suggested here in TracNotification#CustomizingContent, with CookBook/Notification/Templates.

--------------------------------------------------------------------------
# set sel = ('Reporter', 'Owner', 'Type', 'Status', 'Priority', 'Milestone',
             'Component', 'Severity', 'Resolution', 'Keywords')
# for a in ticket_props.replace('|', '\n').splitlines()[1:-1]|map('trim'):
#   set a = a.split(':', 1)|map('trim')|list
#   if len(a) > 1 and a[0] in sel:
${'%-*s  %s'|format(12, a[0] + ':', a[1])}
#   endif
# endfor
--------------------------------------------------------------------------

So, notification works - no error, but I have only empty fields in the e-mail as it is shown here below:

#1703: NEST for coping with bunching of regulated traffic
--------------------------------------------------------------------------
Reporter:     
Owner:        
Type:         
Status:       
Priority:     
Milestone:    
Component:    
Severity:     
Resolution:   
Keywords:     
--------------------------------------------------------------------------
Comment (by Laszlo Elbert):

 testx
-- 
Ticket URL: <https://nest-tool.eurocontrol.int/trac/nest/ticket/1703#comment:32>
NEST <https://www.eurocontrol.int/nest>
NEST project

Thanks for the advise in advance Laszlo

[Ryan J Ollos]

I'm not sure, it works fine for me:

${ticket_body_hdr}
--------------------------------------------------------------------------
# set sel = ('Reporter', 'Owner', 'Type', 'Status', 'Priority', 'Milestone',
             'Component', 'Severity', 'Resolution', 'Keywords')
# for a in ticket_props.replace('|', '\n').splitlines()[1:-1]|map('trim'):
#   set a = a.split(':', 1)|map('trim')|list
#   if len(a) > 1 and a[0] in sel:
${'%-*s  %s'|format(12, a[0] + ':', a[1])}
#   endif
# endfor
--------------------------------------------------------------------------
# if ticket.new:
${ticket.description}
# else:
#   if changes_body:
${_('Changes (by %(author)s):', author=change.author)}

${changes_body}
#   endif
#   if changes_descr:
#     if not changes_body and not change.comment and change.author:
${_('Description changed by %(author)s:', author=change.author)}
#     endif
${changes_descr}
--
#   endif
#   if change.comment:

${_('Comment:') if changes_body else
  _('Comment (by %(author)s):', author=change.author)}

${change.comment}
#   endif
# endif
${'-- '}
${_('Ticket URL: <%(link)s>', link=ticket.link)}
${project.name} <${project.url or abs_href()}>
${project.descr}

Please use MailingList in the future for support inquiries, but we can take this one to completion here.

[Elbert Laszlo <laszlo.elbert@…>]

Dear Ryan, I copied 1 by 1 your text, still my tickets are empty, restarted apache2, etc. Nothing in the log. Just it seems to me that values are not filled. Any idea how can I arrive to get it work? Thanks Laszlo

[Ryan J Ollos]

Do you have plugins installed? Trying disabling all of them.

[Ryan J Ollos]

Any possibility you have another copy of that the ticket_notify_email.txt template somewhere on Trac's template search path?

I'd revert and redo each step to confirm, restarting the web server and verifying functionality at each step:

1. Remove ticket_notify_email.txt
2. Add standard ticket_notify_email.txt from TracNotification#CustomizingContent to $env/templates
3. Replace $env/templates/ticket_notify_email.txt with comment:2 template contents

[anonymous]

Dear Ryan, If I use the standard ticket_notify_email.txt, I get the email filled from ${ticket_props} values, but if I replace with comment2 I get empty fields. I have several instances, and the problem is the same, fields are empty, maybe that guy does not get the value a[1]:

#1703: NEST for coping with bunching of regulated traffic
-------------------------------------+-------------------------------------
                        Reporter:    |                           Owner:
  Laszlo Elbert                      |  (none)
                            Type:    |                          Status:
  defect                             |  closed
                        Priority:    |                       Milestone:
  medium                             |  1.7.1
                       Component:    |                         Version:
  Software                           |  1.7.0
                        Severity:    |                      Resolution:
  major                              |  duplicate
                        Keywords:    |                  Estimatedhours:  0
          Quick (<4 hours) to do:    |      Automatic testing required:  0
  0                                  |
Missing in NEST compared to SAAM:    |         Possible impact on DDR2:  0
  0                                  |
                         Private:    |  To revalidate on Merge Network:  0
  0                                  |
                 Fixing revision:    |           Trunk report revision:
                Validation notes:    |
-------------------------------------+-------------------------------------

[Ryan J Ollos]

Replying to anonymous:

… maybe that guy does not get the value a[1]:

You can try debugging the comment:2 template. I'd first make this change:

${'%-*s %s'|format(12, a[0] + ':', a[1])} → ${a}

That will show us the value that a contains.

[laszlo.elbert@…]

Thanks for the reply. This gives the following below

#1703: NEST for coping with bunching of regulated traffic
--------------------------------------------------------------------------
[u'Reporter', u'']
[u'Owner', u'']
[u'Type', u'']
[u'Status', u'']
[u'Priority', u'']
[u'Milestone', u'']
[u'Component', u'']
[u'Severity', u'']
[u'Resolution', u'']
[u'Keywords', u'']
--------------------------------------------------------------------------
Comment (by Laszlo Elbert):

[Ryan J Ollos]

Next try:

# for a in ticket_props.replace('|', '\n').splitlines()[1:-1]|map('trim'):
#   set a = a.split(':', 1)|map('trim')|list
#   if len(a) > 1 and a[0] in sel:
${'%-*s  %s'|format(12, a[0] + ':', a[1])}
#   endif
# endfor

→

# for a in ticket_props.replace('|', '\n').splitlines()[1:-1]|map('trim'):
#   ${a}
# endfor

[laszlo.elbert@…]

We are getting there, there is a shift by one line as I'm the reporter.

#1703: NEST for coping with bunching of regulated traffic
--------------------------------------------------------------------------
 Reporter:
 Owner:
 Laszlo Elbert
 (none)
 Type:
 Status:
 defect
 closed
 Priority:
 Milestone:
 medium
 1.7.1
 Component:
 Version:
 Software
 1.7.0
 Severity:
 Resolution:
 major
 duplicate
 Keywords:
 Estimatedhours:  0
 Quick (<4 hours) to do:
 Automatic testing required:  0
 0
 
 Missing in NEST compared to SAAM:
 Possible impact on DDR2:  0
 0
 
 Private:
 To revalidate on Merge Network:  0
 0
 
 Fixing revision:
 Trunk report revision:
 Validation notes:
 
 -------------------------------------+-------------------------------------
 Opportunity(justification):
 
 
 
 Traceability comments (doc, test):
 
 
--------------------------------------------------------------------------
Comment (by Laszlo Elbert):

 sdsadasd

[Ryan J Ollos]

I think the issue is that your custom field labels are very long. Can you shorten this one to be something like: Missing in NEST compared to SAAM: → Missing in NEST vs SAAM:?

[laszlo.elbert@…]

Congratulations and thanks, the problem is somewhere there.

#1703: NEST for coping with bunching of regulated traffic
--------------------------------------------------------------------------
 Reporter:  Laszlo
 Owner:  (none)
 Elbert
 
 Type:  defect
 Status:  closed
 Priority:  medium
 Milestone:  1.7.1
 Component:  Software
 Version:  1.7.0
 Severity:  major
 Resolution:
 
 duplicate
 Keywords:
 Estimatedhours:  0
 Quick (<4 hours) to do:  0
 Automatic testing req'd:  0
 Missing in NEST vs  SAAM:  0
 Possible impact on DDR2:  0
 Private:  0
 Revalidate on MergeNetwork:  0
 Fixing revision:
 Trunk report revision:
 Validation notes:

[Ryan J Ollos]

This should work, without worry for the ticket custom field length:

--------------------------------------------------------------------------
# set fields = ('Reporter', 'Owner', 'Type', 'Status', 'Priority', 'Milestone',
                'Component', 'Severity', 'Resolution', 'Keywords')
# for f in fields:
${'%-*s  %s'|format(12, f + ':', ticket[f.lower()])}
# endfor
--------------------------------------------------------------------------

[laszlo.elbert@…]

Thank you very much for your help. The only minor aesthetics is that the name of reporter is chopped off, but is already perfectly usable.

--------------------------------------------------------------------------
Reporter:         Laszlo
Owner:            (none)
Type:             defect
Status:           closed
Priority:         medium
Milestone:        1.7.1
Component:        Software
Severity:         major
Resolution:       
Keywords:         
--------------------------------------------------------------------------
Comment (by Laszlo Elbert):

 And now

[Ryan J Ollos]

Replying to laszlo.elbert@…:

The only minor aesthetics is that the name of reporter is chopped off, but is already perfectly usable.

The issue there is that the userid is being used rather than the User Name that is saved in preferences.

[Ryan J Ollos]

We might want to pass more ticket data to the template rendering so that we provide more control in implementing a custom notification template. An example would be a dictionary with the ticket field names, original values and formatted values (e.g. real name from author name).

[Ryan J Ollos]

It's really unfortunate that we pass the "ticket_values" dict as the "ticket" variable​. Ideally we would pass ticket_values as ticket_values and the ticket object as ticket.

I propose that we populate ticket with the same formatted values that are contained in ticket_props, so that we can use the comment:13 patch and not parse ticket_props as is done in CookBook/Notification/Templates#jinja2, which is problematic due to wrapping (comment:11).

We could also pass the ticket object as ticket.ticket.

That change would be backward-incompatible, but shouldn't affect too many, if any, users. Maybe it should be deferred to 1.5.x?

Thoughts?