I would like to be able to refer to a System Configuration value set in the Zotonic admin interface within a template.
In particular I would like to create a configurable password complexity regex so I can write a validate statement like the following:
{% validate id="new_password" type={format pattern=config.mod_admin_identity.password_regex %}
How do you refer to Config values from the admin interface in Zotonic validators?
The answer is quick to retrieve thanks to Arjan's new search I went from http://zotonic.com/search?q=config to http://zotonic.com/documentation/719/m-config and quickly devised a solution using m_config.
Here is a modification to _action_dialog_set_username_password.tpl that provides password complexity enforcement based on an admin config for module mod_admin_identity with key password_regex that auto-degrades to a simple presence check:
{% if m.config.mod_admin_identity.password_regex.value %}
{% validate id="new_password" type={presence} type={format pattern=m.config.mod_admin_identity.password_regex.value} %}
{% else %}
{% validate id="new_password" type={presence} %}
{% endif %}
Related
I have a scenario where I have to use service name with wildcard since service name starts with a particular name and it contains the version of software. E.g. in server-1, service name is RunningService14.1.0 and in server-2, service name is RunningService15.2.0.
How can I pass the service name dynamically?
Below syntax is not working.
start_service:
service.start:
- name: RunningServ*
Where as below syntax is working fine.
status_service:
service.status:
- name: RunningServ*
We can get the service status with wildcard because the service.status module supports it. Quoting from documentation:
Return the status for a service. If the name contains globbing, a dict mapping service name to True/False values is returned.
But the same is not true for the service.start module, which requires a specific service name.
To avoid using the wildcard, you could keep the version of software in a pillar or custom grain for each server. Example for server-1:
software_version: "14.1.0"
Then your state file can be simple and just have:
start-service:
module.run:
- service.start:
- name: RunningService{{ software_version }}
This will ensure that the appropriate version is picked up for each server, and the corresponding service will be started.
Otherwise, as #β.εηοιτ.βε suggested in his comment, we can get all services, filter and take action only when service name contains RunningServ. Though this will require writing logic in the state file.
{% set all_services = salt['service.get_all']() %}
{% for service_name in all_services %}
{% if 'RunningServ' in service_name %}
start-service-{{ service_name }}:
module.run:
- service.start:
- name: {{ service_name }}
{% endif %}
{% endfor %}
How do make it so that every time the incremental load in dbt runs it just updates the new rows from when it last ran?
{% if is_incremental() %}
/* code */
{% endif %}
Your two main resources for doing this are going to be in the dbt docs already:
How to build incremental models in dbt:
https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models/
Incremental models particular to bigquery:
https://docs.getdbt.com/reference/resource-configs/bigquery-configs/#merge-behavior-incremental-models
Most likely the model will look something like:
{{
config(
materialized='incremental'
)
}}
select <columns>
from <my_table>
{% if is_incremental() %}
where <my_table>.<record_update_timestamp> >= (
select max(<my_table>.<record_update_timestamp>) from {{ this }}
)
{% endif %}
Full example in from docs in:
https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models/#defining-a-uniqueness-constraint-optional
I'm trying to use a variable as a name of another variable.
{% assign key = string[0] %}
{% assign {{key}} = string[1] %}
Is this possible? If not, is there any alternative that I could use that would let me achieve similar things as this variable?
I'm not trying to access a variable, I'm trying to assign it, so this isn't a duplicate of Dynamic Variables Jekyll Liquid.
Assume we have a model called Author as such:
class Author(models.Model):
name = models.CharField(max_length=250)
We also have a feature which enables users to follow a certain author:
class UserFollow(models.Model):
author = models.ForeignKey(Author)
user = models.ForeignKey(User)
If you have a button in your UI that enables logged in users to follow / unfollow these authors. One way to check if this user is already following a certain author is to make a query on the existence of a record in UserFollow. However, when you're fetching a list of 10 / 20 .. etc authors, how would you check each author for the currently logged in user?
The usual approach would result in +X number of extra queries depending on how many items you're loading per page. Is there a more efficient way to achieve the same effect?
Thanks in advance
you can fetch all instances of UserFollow in view, pass it as a variable to the template and then you can check if given author is in this list
def my_view(request):
following = list(UserFollow.objects.filter(user=request.user))
template_context = {
'following': following
}
template:
{% for author in authors %}
{% if author in following %}
{# do some magic #}
{% endif %}
{% endfor %}
I have two tables: Actor and Images. The Images table is linked to the Actor table through a Foreign Key. I might make a query on Actor that pulls a list of all the actors with first name beginning with the letter A. Let's say I store this query result in actor_list and pass it to the template. I can get a list of all the Images through the template by iterating. Something like:
{% for actor in actor_list %}
{% for image in actor.img_set %}
{{ image }}
{% endfor %}
{% endfor %}
Is this costly to the database? Does the associated img_set come through with the initial actor object list, or does a new query hit the database every time I call for the actor.img_set?
You should install the Django debug toolbar and see what SQL queries are happening under the covers.
If you are getting too many queries, you can try using select_related() to pull in the related data in the initial query.
Better than using the django toolbar is using the connections library. With Debug set to True:
>>> from django.db import connection
>>> for actor in actor_list:
>>> for image in actor.img_set:
>>> image
>>> connection.queries()
This will show all the queries that were executed and the amount of time that each took.
The debug toolbar is cool, though, for many uses. :-)