<p>It's a little hard to follow your example/description, but I'll take a stab at it.</p>

<p>The way I interpret your question, you need to pull a single <code>guestList</code> entry that is a) related to the current <code>event</code>, and b) shares a relationship with the <code>partner</code> entry set to the current user's <code>partner</code> field, via a <code>guestAllocation</code> SuperTable field owned by the <code>event</code> EntryModel (I'm assuming there's a <code>guestAllocation.partner</code> column, and that the event section has the <code>event</code> handle).</p>

<p>The first part is easy, although you seem to be confused about the <code>targetElement</code> and <code>sourceElement</code> parameters for the <code>relatedTo</code> method, so I'll try to clear that up:</p>

<p>Basically, in a <code>relatedTo</code> query you either specify the <em>target</em> element or the <em>source</em> element (never both) for the relationship – <em>depending on which element owns the field where relation is created</em>.</p>

<p>In your case, the <code>event</code> entry would be the <strong>target</strong> element, not the <strong>source</strong>, as the <code>relatedEvent</code> field (where the relation is created) belongs to the <code>guestList</code> entry model, not the <code>event</code>. In other words, the elements you <em>want</em> (the guest lists) should have the entry you <em>have</em> (the <code>event</code> entry) selected in a field (i.e. the <code>guestLists</code> entries "target" the <code>event</code> entry), not the other way around. If possible, you should also provide the field handle for the field where the relation is created, i.e. <code>relatedEvent</code> in your case. So, to pull <em>all</em> guestlists related to the current <code>event</code> entry, the correct <code>relatedTo</code> query would look like this:</p>

<pre><code>{% set guestListsForEvent = craft.entries.section('guestList').relatedTo({
    targetElement: entry,
    field: 'relatedEvent'
}) %}
</code></pre>

<p>Obviously, you only want <em>one</em> guestlist – the one that is related to the current user's <code>partner</code> entry (phew!). Trouble is, that relationship doesn't really exist – it's actually more of a <em>condition</em>, where a) the <code>guestList</code> entry needs to be authored by a user with the correct <code>partner</code> relation, and b) the current <code>event</code> needs to have the correct <code>partner</code> entry (i.e. the current user's related <code>partner</code> entry) in its <code>guestAllocations</code> SuperTable field.</p>

<p>The second part is easy – you can set a <code>canCurrentUserCreateGuestList</code> flag inside a loop on the current <code>event</code> entry's <code>guestAllocations</code> field; if the correct <code>partner</code> event is found in the latter, the current user can create a new <code>guestList</code> entry and you should also query for an existing <code>guestList</code> entry:</p>

<pre><code>{% set currentPartner = currentUser.partner.first %}
{% set currentUserCanCreateGuestList = false %}
{% for row in entry.guestAllocation %}
    {% if row.partner|length and row.partner.first.id == currentPartner.id %}
        {% set currentUserCanCreateGuestList = true %}
    {% endif %}
{% endfor %}
</code></pre>

<p>Once you have that flag, you can use it in a conditional:</p>

<pre><code>{% if currentUserCanCreateGuestList %}
   {# Query for existing guest list, create new list etc #}
{% endif %}
</code></pre>

<p>For the latter – the actual query to pull the <code>guestList</code> entry – a single <code>relatedTo</code> call obviously won't do the job here, but fortunately the workaround is quite simple – keeping in mind that you need to make sure that a) only 1 <code>guestList</code> entry is returned, and b) that entry is authored by a user with the same <code>partner</code> entry as the current user.</p>

<p>Again, the first part is easy – simply use <code>limit</code> and <code>first</code> to pull a single entry (I like to add a <code>|default(false)</code> filter to suppress errors if no entries are returned).</p>

<p>For the second part, you'll first need a list of user IDs for all the users that are related to the current user's <code>partner</code> entry, and then feed that array to the <code>authorId</code> parameter for the <code>craft.entries</code> call:</p>

<pre><code>{# Get the IDs for all users related to the correct partner #}
{% set partnerUserIds = craft.users.relatedTo({
    targetElement: currentUser.partner.first,
    field: 'partner'
}).ids() %}

{# Get existing partner guest list related to the current event #}
{% set partnerGuestList = partnerUserIds|length ? craft.entries.section('guestList').relatedTo({
    targetElement: entry,
    field: 'relatedEvent'
}).authorId(partnerUserIds).limit(1).first|default(false) : false %}
</code></pre>

<p>The above code will return either a single <code>guestList</code> <code>EntryModel</code>, or <code>false</code>, if no related guestlist entries authored by a user with the correct <code>partner</code> entry exists. Whether or not the <code>event</code> entry has the current user's <code>partner</code> entry in one of its SuperTable <code>guestAllocation.partner</code> columns is irrelevant to the query itself, once you've established that the current <code>event</code> does indeed include the correct <code>partner</code> entry in its <code>guestAllocations</code> field (the conditional above).</p>

<p>Here's how the whole thing could look in context:</p>

<pre><code>{# Can the current user create a guest list for this event? #}
{% set currentPartner = currentUser.partner.first %}
{% set currentUserCanCreateGuestList = false %}
{% for row in entry.guestAllocation %}
    {% if row.partner|length and row.partner.first.id == currentPartner.id %}
        {% set currentUserCanCreateGuestList = true %}
    {% endif %}
{% endfor %}

{# Get existing guest list #}
{% set partnerGuestList = false %}
{% if currentUserCanCreateGuestList %}
    {# Get the IDs for all users related to the correct partner #}
    {% set partnerUserIds = craft.users.relatedTo({
        targetElement: currentUser.partner.first,
        field: 'partner'
    }).ids() %}

    {# Get existing partner guest list related to the current event #}
    {% set partnerGuestList = partnerUserIds|length ? craft.entries.section('guestList').relatedTo({
        targetElement: entry,
        field: 'relatedEvent'
    }).authorId(partnerUserIds).limit(1).first|default(false) : false %}
{% endif %}

{# Create, edit, etc #}
{% if partnerGuestList %}
    {# Edit existing guest list #}
{% elseif currentUserCanCreateGuestList %}
    {# Create new guest list #}
{% else %}
    {# Do nothing? #}
{% endif %}
</code></pre>

<p>Note that the above isn't tested and there's a good chance I misinterpreted your question – but hopefully you'll take something away from it.</p>

<p>Finally, as your question also touches on the correct usage of <code>relatedTo</code> queries with multiple relation criteria: Your original syntax for the <code>relatedTo</code> call is close, but when you have multiple relation criteria, you'll need to include either <code>and</code> or <code>or</code> as the first parameter, specifying if <em>all</em> or <em>any</em> of the criteria should be met, respectively.</p>

<p>In your case, this means the <em>syntactically</em> correct multiple relation query for the partner guestlist should look something like this:</p>

<pre><code>{% set partnerGuestList = craft.entries.section('guestList').relatedTo('and', 
    { target: entry, field: 'relatedEvent' },
    { targetElement: currentUser.partner.first(), field: 'guestAllocation.partner' }
) %}
</code></pre>

<p>Obviously, for reasons already explained the above query will return nothing. There's also the fact that SuperTable fields (in your case, the <code>guestAllocation.partner</code> field) doesn't actually work with the built-in relations functionality in Craft – meaning that <em>you can never use <code>craft.entries.relatedTo</code> when the relation is created in a SuperTable field</em>. Instead, SuperTable provides its own method for relation queries, which is explained in <a href="https://craftcms.stackexchange.com/a/12123/1098">this answer</a>. Again, I don't believe a single <code>relatedTo</code> call is the correct approach for your particular use case, but just wanted to mention it.</p>

<p>Just for funsies – here's how you could use SuperTable's <code>getRelatedElements</code> method to pull <code>event</code> entries based on <code>guestAllocation.partner</code> relations:</p>

<pre><code>{% set partnerEvents = craft.supertable.getRelatedElements({
    relatedTo: {
        targetElement: currentUser.partner.first,
        field: 'guestAllocation.partner'
    },
    criteria: {
        section: 'event'
    }
}) %}
</code></pre>

CC BY-SA 3.0
2016-01-01T14:29:03.823Z
Just realized that if multiple Users can have the same 'partner' entry, the above falls apart. Let me know if thats the issue!
Mats Mikkel Rummelhoff
CC BY-SA 3.0
2016-01-01T15:53:06.327Z
Nevermind, I updated the answer to accommodate that issue. It's even longer now! :D
Mats Mikkel Rummelhoff
CC BY-SA 3.0
2016-01-04T14:35:31.097Z
Mats, thank you so much for taking the time to explain in so much detail and with examples! I really appreciate it. This has solved my question (there are more than one user per partner, so thanks for updating it again)
darylknight
CC BY-SA 3.0
2016-01-01T14:18:53.470Z
2016-01-01T15:52:16.840Z
2017-04-13T12:51:00.253Z
Mats Mikkel Rummelhoff
<p>The relevant sections for this question are:</p>

<ul>
<li>Event: One relevant field. <code>guestAllocation</code> (SuperTable). Guest allocation is a table which selects a Partner (<code>Entries</code>) and how many people that partner is allowed to invite to an event</li>
<li>GuestList - Two fields. <code>relatedEvent</code> (Entries) and <code>guestNames</code> (table)</li>
</ul>

<p>Each Partner creates an Entry in the <code>guestList</code> channel. When they want to update the names of who they're inviting, they edit their post instead of creating a new one.</p>

<p>I'm trying to write a conditional which will let me check if there's already an entry in the <code>guestList</code> channel which is both related to that partner AND the event we're currently looking at. I need to check this as I have to update that Entry instead of creating a new one if it exists. The form is displayed on the Event page, so the <code>entry</code> variable is the current event we're dealing with.</p>

<p>I can't get my head round the <code>relations</code> documentation. How do I write this? The following is returning no results:</p>

<pre><code>{% set partnerGuestList = craft.entries.section('guestList').relatedTo(
    { sourceElement: entry }, {# this event #}
    { targetElement: currentUser.partner.first() } {# current partner #}
) %}
</code></pre>

<relations><plugin-supertable>
How to query for multiple relations with SuperTable
# How to query for multiple relations with SuperTable

(Asked by: username_0 on 2015-12-31)

The relevant sections for this question are:

Event: One relevant field. guestAllocation (SuperTable). Guest allocation is a table which selects a Partner (Entries) and how many people that partner is allowed to invite to an event
GuestList - Two fields. relatedEvent (Entries) and guestNames (table)

Each Partner creates an Entry in the guestList channel. When they want to update the names of who they're inviting, they edit their post instead of creating a new one.
I'm trying to write a conditional which will let me check if there's already an entry in the guestList channel which is both related to that partner AND the event we're currently looking at. I need to check this as I have to update that Entry instead of creating a new one if it exists. The form is displayed on the Event page, so the entry variable is the current event we're dealing with.
I can't get my head round the relations documentation. How do I write this? The following is returning no results:
{% set partnerGuestList = craft.entries.section('guestList').relatedTo(
    { sourceElement: entry }, {# this event #}
    { targetElement: currentUser.partner.first() } {# current partner #}
) %}

**Tags:** relations, plugin-supertable


---

## 1 answers

### Answer by username_1 on 2016-01-01. Score: 5 | Accepted answer

It's a little hard to follow your example/description, but I'll take a stab at it.
The way I interpret your question, you need to pull a single guestList entry that is a) related to the current event, and b) shares a relationship with the partner entry set to the current user's partner field, via a guestAllocation SuperTable field owned by the event EntryModel (I'm assuming there's a guestAllocation.partner column, and that the event section has the event handle).
The first part is easy, although you seem to be confused about the targetElement and sourceElement parameters for the relatedTo method, so I'll try to clear that up:
Basically, in a relatedTo query you either specify the target element or the source element (never both) for the relationship – depending on which element owns the field where relation is created.
In your case, the event entry would be the target element, not the source, as the relatedEvent field (where the relation is created) belongs to the guestList entry model, not the event. In other words, the elements you want (the guest lists) should have the entry you have (the event entry) selected in a field (i.e. the guestLists entries "target" the event entry), not the other way around. If possible, you should also provide the field handle for the field where the relation is created, i.e. relatedEvent in your case. So, to pull all guestlists related to the current event entry, the correct relatedTo query would look like this:
{% set guestListsForEvent = craft.entries.section('guestList').relatedTo({
    targetElement: entry,
    field: 'relatedEvent'
}) %}

Obviously, you only want one guestlist – the one that is related to the current user's partner entry (phew!). Trouble is, that relationship doesn't really exist – it's actually more of a condition, where a) the guestList entry needs to be authored by a user with the correct partner relation, and b) the current event needs to have the correct partner entry (i.e. the current user's related partner entry) in its guestAllocations SuperTable field.
The second part is easy – you can set a canCurrentUserCreateGuestList flag inside a loop on the current event entry's guestAllocations field; if the correct partner event is found in the latter, the current user can create a new guestList entry and you should also query for an existing guestList entry:
{% set currentPartner = currentUser.partner.first %}
{% set currentUserCanCreateGuestList = false %}
{% for row in entry.guestAllocation %}
    {% if row.partner|length and row.partner.first.id == currentPartner.id %}
        {% set currentUserCanCreateGuestList = true %}
    {% endif %}
{% endfor %}

Once you have that flag, you can use it in a conditional:
{% if currentUserCanCreateGuestList %}
   {# Query for existing guest list, create new list etc #}
{% endif %}

For the latter – the actual query to pull the guestList entry – a single relatedTo call obviously won't do the job here, but fortunately the workaround is quite simple – keeping in mind that you need to make sure that a) only 1 guestList entry is returned, and b) that entry is authored by a user with the same partner entry as the current user.
Again, the first part is easy – simply use limit and first to pull a single entry (I like to add a |default(false) filter to suppress errors if no entries are returned).
For the second part, you'll first need a list of user IDs for all the users that are related to the current user's partner entry, and then feed that array to the authorId parameter for the craft.entries call:
{# Get the IDs for all users related to the correct partner #}
{% set partnerUserIds = craft.users.relatedTo({
    targetElement: currentUser.partner.first,
    field: 'partner'
}).ids() %}

{# Get existing partner guest list related to the current event #}
{% set partnerGuestList = partnerUserIds|length ? craft.entries.section('guestList').relatedTo({
    targetElement: entry,
    field: 'relatedEvent'
}).authorId(partnerUserIds).limit(1).first|default(false) : false %}

The above code will return either a single guestList EntryModel, or false, if no related guestlist entries authored by a user with the correct partner entry exists. Whether or not the event entry has the current user's partner entry in one of its SuperTable guestAllocation.partner columns is irrelevant to the query itself, once you've established that the current event does indeed include the correct partner entry in its guestAllocations field (the conditional above).
Here's how the whole thing could look in context:
{# Can the current user create a guest list for this event? #}
{% set currentPartner = currentUser.partner.first %}
{% set currentUserCanCreateGuestList = false %}
{% for row in entry.guestAllocation %}
    {% if row.partner|length and row.partner.first.id == currentPartner.id %}
        {% set currentUserCanCreateGuestList = true %}
    {% endif %}
{% endfor %}

{# Get existing guest list #}
{% set partnerGuestList = false %}
{% if currentUserCanCreateGuestList %}
    {# Get the IDs for all users related to the correct partner #}
    {% set partnerUserIds = craft.users.relatedTo({
        targetElement: currentUser.partner.first,
        field: 'partner'
    }).ids() %}

    {# Get existing partner guest list related to the current event #}
    {% set partnerGuestList = partnerUserIds|length ? craft.entries.section('guestList').relatedTo({
        targetElement: entry,
        field: 'relatedEvent'
    }).authorId(partnerUserIds).limit(1).first|default(false) : false %}
{% endif %}

{# Create, edit, etc #}
{% if partnerGuestList %}
    {# Edit existing guest list #}
{% elseif currentUserCanCreateGuestList %}
    {# Create new guest list #}
{% else %}
    {# Do nothing? #}
{% endif %}

Note that the above isn't tested and there's a good chance I misinterpreted your question – but hopefully you'll take something away from it.
Finally, as your question also touches on the correct usage of relatedTo queries with multiple relation criteria: Your original syntax for the relatedTo call is close, but when you have multiple relation criteria, you'll need to include either and or or as the first parameter, specifying if all or any of the criteria should be met, respectively.
In your case, this means the syntactically correct multiple relation query for the partner guestlist should look something like this:
{% set partnerGuestList = craft.entries.section('guestList').relatedTo('and', 
    { target: entry, field: 'relatedEvent' },
    { targetElement: currentUser.partner.first(), field: 'guestAllocation.partner' }
) %}

Obviously, for reasons already explained the above query will return nothing. There's also the fact that SuperTable fields (in your case, the guestAllocation.partner field) doesn't actually work with the built-in relations functionality in Craft – meaning that you can never use craft.entries.relatedTo when the relation is created in a SuperTable field. Instead, SuperTable provides its own method for relation queries, which is explained in this answer. Again, I don't believe a single relatedTo call is the correct approach for your particular use case, but just wanted to mention it.
Just for funsies – here's how you could use SuperTable's getRelatedElements method to pull event entries based on guestAllocation.partner relations:
{% set partnerEvents = craft.supertable.getRelatedElements({
    relatedTo: {
        targetElement: currentUser.partner.first,
        field: 'guestAllocation.partner'
    },
    criteria: {
        section: 'event'
    }
}) %}

> **Comments:**
> **username_1**: Just realized that if multiple Users can have the same 'partner' entry, the above falls apart. Let me know if thats the issue!  
> **username_1**: Nevermind, I updated the answer to accommodate that issue. It's even longer now! :D  
> **username_0**: Mats, thank you so much for taking the time to explain in so much detail and with examples! I really appreciate it. This has solved my question (there are more than one user per partner, so thanks for updating it again)  

---

