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
Comment #2
thedut CreditAttribution: thedut commentedHello Johnathan
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 :
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.
Comment #3
jsibley CreditAttribution: jsibley commentedI'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.
Comment #4
jsibley CreditAttribution: jsibley commentedIs 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.
Comment #5
jsibley CreditAttribution: jsibley commentedI 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:
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.
Comment #6
thedut CreditAttribution: thedut commentedThanks 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.