Hi,

I believe that dp_tid is the primary key for limesurvey tokens tables and that it corresponds to dp_aid in the limesurvey answers tables. However, I don't see it in the list of fields that can be displayed in views and I can't use it in rules.

Also, I'm guessing this is related, when creating a view based on limesurvey tokens, the default field that appears in the view is the created date, not dp_tid. I think that it would make sense for it to be dp_tid.

Is there any chance that you could fix this? Unfortunately, due to your clever (I mean this, it isn't ironic) use of abstraction, I can't find where the problem is.

Thanks!

Comments

jsibley created an issue. See original summary.

thedut’s picture

Hello Johnathan

I believe that dp_tid is the primary key for limesurvey tokens tables and that it corresponds to dp_aid in the limesurvey answers tables

This assumption is wrong.
The system is quite simple : The Drupal LimeSurvey answer entity is the exact copy of the corresponding row in the LimeSurvey answer table. It is the same for the Drupal token entity.
Columns from LimeSurvey are prefixed with 'ls_' into the Drupal entity.
Extra columns into the Drupal entity are prefixed with 'dp_'.
In the LimeSurvey answer table, the primary key is 'aid', it matchs the 'ls_aid' in the Drupal answer entity.
In the LimeSurvey token table, the primary key is 'tid', it matchs the 'ls_tid' in the Drupal token entity.
The 'dp_aid' is the internal Drupal identifier of the Drupal answer entity, wich is different from the 'ls_aid'.
The 'dp_tid' is the internal Drupal identifier of the Drupal token entity, wich is different from the 'ls_tid' and the 'dp_aid'.
The LimeSurvey response entity is a set of a Drupal answer entity on 'dp_aid' and of a Drupal token entity on 'dp_tid'.
That's the architecture. So you need the response entity in order to match a 'dp_tid' and a corresponding 'dp_aid'.
If you want to display in Views an answer and its associated token you can either :

  • create a views based on limesurvey response and add relationship to Drupal answer and token (on 'dp_aid' and 'dp_tid')
  • or create a view based on token entity, and add a relationship to the Anwser entity on ls_token
  • or create a view based on answer entity, and add a relationship to the token entity on ls_token

when creating a view based on limesurvey tokens, the default field that appears in the view is the created date, not dp_tid. I think that it would make sense for it to be dp_tid.

Strange behavior, but it is just about user experience, you just have to add the fieds you need manually. I will spent time on more interesting evolutions. but thank you for reporting.

jsibley’s picture

I'm sorry. I think that I wasn't clear.

I meant to be talking about the Drupal Limesurvey tables, not the tables in Limesurvey, itself.

Isn't the primary key of the Drupal Limesurvey Tokens tables the field dp_tid, which is serialized and unique? Is there a reason one shouldn't be able to use it as a column in a view? I think that is my question and I made that unclear with the rest of what I wrote.

The reason this would be helpful to me is that I have an entity that I created using ECK and would like to have a reference to a corresponding token, but need that reference to use dp_tid.

Hope that helps.

jsibley’s picture

Is it particularly difficult to make dp_tid in the limesurvey_sync_token_xxxx tables available to views and rules?

I've tried, but I must have missed something.

Thanks.

jsibley’s picture

I think I have made progress on making the dp_tid more usable:

in limesurvey_sync_token.class.inc

in schema_custom_fields we need something like this added:

$schema['dp_tid'] = array(
'type' => 'int',
'unsigned' => TRUE,
'not null' => FALSE,
'default' => NULL,
'description' => 'Drupal Key of the LS token table',
);

and in entity_property_info_custom_fields we need something like this added:

$info['dp_tid'] = array(
        'label' => t('TID, Drupal LimeSurvey token ID'),
        'description' => t('Drupal ID of LimeSurvey token ID'),
        'type' => 'integer',
        'validation callback' => 'entity_metadata_validate_integer_positive',
        'schema field' => 'dp_tid',
        'required' => TRUE,
     );

I'm not sure whether this covers everything, but now I can see the field in views, which was not possible before. I can also see dp_tid in rules.

thedut’s picture

Status: Active » Fixed

Thanks for providing fix to this issue.
It should be fixed into the v7.x-3.x-beta1 release.
I close this issue as fixed. Feel free to reopen it.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.