[Building Sakai] IMSBLTIPortlet.xml config issues

Thomas, Gregory J gjthomas at iupui.edu
Mon Mar 18 06:20:35 PDT 2013


Chuck,

So, the part of the issue seems to be that none of the values were ever
copied to the SAKAI_SITE_TOOL_PROPERTY table.  When this particular
instance of the tool was added to our my workspace sites, it was done via
a SQL backfill instead of through a quartz job or manually adding them to
the site.  When you drill down into one of these tools from Admin > Sites,
it does fill in what's entered in the IMSBLTIPortlet.xml file.  However,
despite whatever has been entered in the config file, it still doesn't
seem to update based on whatever changes I do to the file.  I can also
confirm there's still nothing written to the SAKAI_SITE_TOOL_PROPERTY
table for a site.  So, I'm still not sure what the issue is why the
instance of the tool is ignoring properties after seemingly being able to
read them.  I'm considering wiping out all instances of the tool and
re-adding them via a quartz job so a more "proper" tool placement occurs.
I'd prefer to have an easier, short term fix without this overhead, but I
haven't discovered it yet.

Thanks,
Greg

On 3/16/13 3:26 PM, "Yegeneswari Nagappan" <ynagappan at unicon.net> wrote:

>Apologies! You are right about the table related to External Tools
>portlet. The 'lti_tools' is used by the external tool module that resides
>in a Lesson Builder.
>
>Thanks
>Esh
>----- Original Message -----
>From: "Charles Severance" <csev at umich.edu>
>To: "Gregory J Thomas" <gjthomas at iupui.edu>
>Cc: "Yegeneswari Nagappan" <ynagappan at unicon.net>,
>sakai-dev at collab.sakaiproject.org
>Sent: Friday, March 15, 2013 9:34:05 PM
>Subject: Re: [Building Sakai] IMSBLTIPortlet.xml config issues
>
>Thomas - That table (lti_tools) has nothing at all to do with the
>External Tools portlet.
>
>All of the data for the external tools portlet lives in
>
>mysql> SELECT * from SAKAI_SITE_TOOL_PROPERTY where NAME =
>'imsti.releasename';
>+--------------------------------------+----------------------------------
>----+-------------------+-------+
>| SITE_ID                              | TOOL_ID
>    | NAME              | VALUE |
>+--------------------------------------+----------------------------------
>----+-------------------+-------+
>| 361e8cde-7279-483e-bedc-d79aa68338fd |
>bde4fb35-a69b-4025-a427-51db3e686392 | imsti.releasename | on    |
>+--------------------------------------+----------------------------------
>----+-------------------+-------+
>1 row in set (0.00 sec)
>
>Of course you will need to reduce this by SITE_ID and placement to get to
>the data for yor particular placement.
>
>The ultimate decision as to whether or not to release names depends on
>the IMSBLTIPortlet.xml combined with the property value in
>SAKAI_SITE_TOOL_PROPERTY - and if something is marked as final in the
>registration they are not allowed to change it.
>
>But here is the key that you are likely missing.   Once a placement is
>created it *copies* the current values from IMSBLTIPortlet.xml into the
>properties in  SAKAI_SITE_TOOL_PROPERTY including the final.* properties.
>
>Another way to find these properties is use the Admin / Sites tool to dig
>down to the tool placement and look at the properties.
>
>Hope this helps.
>
>/Chuck
>
>On Mar 15, 2013, at 2:43 PM, Thomas, Gregory J wrote:
>
>> Esh,
>> 
>> Excellent suggestion!  Unfortunately, that looks like that table was
>>added
>> in https://jira.sakaiproject.org/browse/BLTI-156, which has a version
>>fix
>> of 1.3.6 and we currently have 1.3.5 deployed to our Sakai 2.7.1 code
>> base(and that table doesn't exist). :(
>> 
>> I'll definitely keep that in mind while we're upgrading to 2.9, but
>>still
>> need a short term answer/fix.
>> 
>> Thanks,
>> Greg
>> 
>> On 3/15/13 1:08 PM, "Yegeneswari Nagappan" <ynagappan at unicon.net> wrote:
>> 
>>> Hi Gregory,
>>> 
>>> If a default configuration specified in IMSBLTIPortlet.xml is not set
>>>as
>>> 'final', then its editable during the tool set up. So I'm guessing in
>>> your case during the tool set up (existing instances) when the
>>> imsti.releasename value was 'off', it was not edited and the same value
>>> was saved to the table. The table that you need to check is 'lti_tools'
>>> and column is 'sendname'. The value stored in table is overridden
>>>during
>>> launch, only if a value for the same property is specified in Sakai
>>> configuration i.e in sakai.properties.
>>> 
>>> Any configuration changes you make in IMSBLTIPortlet.xml will be
>>> reflected only for new tools and not for existing lti tools.
>>> 
>>> Hope this helps!
>>> 
>>> Thanks
>>> Esh
>>> 
>>> ----- Original Message -----
>>> From: "Gregory J Thomas" <gjthomas at iupui.edu>
>>> To: sakai-dev at collab.sakaiproject.org
>>> Sent: Friday, March 15, 2013 9:16:19 AM
>>> Subject: [Building Sakai] IMSBLTIPortlet.xml config issues
>>> 
>>> 
>>> 
>>> Currently dealing with an issue of names not being released to an
>>> external tool we have. It's definitely true that we're missing
>>> <configuration name="imsti.releasename" value="on"/> in our
>>> IMSBLTIPortlet.xml file for the default on this particular tool.
>>>However,
>>> adding this back in and testing it on our existing instances of the
>>>tool
>>> doesn't seem to matter. I've confirmed with a manual edit of the debug
>>> properties via the Sites superuser tool what's being passed. However,
>>>if
>>> I try to make <configuration name="imsti.debug" value="on"/> a default
>>>or
>>> anything else (e.g. <configuration name="imsti.releaseemail"
>>> value="off"/> ), these still don't seem to be updated. Email is still
>>> always passed and debug is never turned on for other instances of the
>>> site. 
>>> 
>>> 
>>> I've cleared my browser cache, used multiple browsers, and multiple
>>> accounts. Same results of defaults not being updated every time.
>>> 
>>> 
>>> There's not been anything written to the sakai_site_tool_property
>>>table,
>>> which I'm unsure if that's an issue or not. My assumption is a tool id
>>> defined in this xml file will use defaults defined in there and if
>>> something is different, that will be written to the table.
>>> 
>>> 
>>> Anyway, if anyone has any ideas on what could be wrong, I'd greatly
>>> appreciate it! 
>>> 
>>> 
>>> Thanks, 
>>> Greg 
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> 
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to
>>sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>"unsubscribe"
>



More information about the sakai-dev mailing list