Allowing interpreted Python code was later considered a security risk. 
These fields now use the template language of Django 
( and expect 
a comma delimited output. So the years example would now be:

'1990', '1991', '1992', '1993', '1994', '1995', '1996', '1997', '1998', 
'1999', '2000'

without the brackets.

The second example cannot be done as the template language doesn't support 
range generators. This is some of the reasons switching to the Jinja2 
template language is being considered. It is more secure than Python code, 
is a superset of Django's template language but add many Pythonistic tags 
line range().

With Jinja2 this would be the solution to generate a range of years.
{% for year in range(1990,2000) %}
{{ year }},
{% endfor %}

For a localized list of months, in theory (haven't tested yet) this would 

{% load i18n %}
{% trans 'January' %},
{% trans 'February' %},
{% trans 'December' %}

The first line loads the internationalization tags (` trans `). The trans 
tag marks a text for translation. 

On Monday, April 10, 2017 at 10:34:14 AM UTC-4, Manuel Reiter wrote:
> These examples don't seem to work any more. Am I doing something wrong or 
> has the syntax changed over the last couple of years? What would be the 
> best way now to offer as choices
>    - a range of years
>    - the localized names of the months?


You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to