[Building Sakai] Sakai floating tutorial

[Matthew Jones]

Yea, I was having this problem too a few weeks ago with some users created
through the sample providers.

If try to get a UserEdit object on these users it throws a "
UserNotDefinedException", so it doesn't seem like you can edit the
properties on the user unless you created them as a local user also and
marked them as provided?

I'm not sure what other people are doing, but I knew that all of these
users internal or external already had an entry in the preferences table,
so just switched to using that instead.

So I guess why is there a SAKAI_PREFERENCES table (often with a user id and
an XML blob containing a ton of preferences) and also a SAKAI_USER_PROPERTY
table (that generally seems to be empty?)

I found this jira as of 2.8 (https://jira.sakaiproject.org/browse/KNL-567)
that supposedly will allow the USER_PROPERTIES to be read for provided
users if they're in there somehow, but still don't see the workflow for
getting them in there other than direct SQL calls.

Is USER_PROPERTIES supposed to be just for internal users properties that
are never exposed to the UI and SAKAI_PREFERENCES (with PREFERENCES_ID key
matching USER_ID) to contain all preferences that users might be able to
set (just as a convention, though you'd think the key would be like
UID:<guid>)?

I remember back a few versions ago when the USER_PROPERTIES wasn't cached
(because nobody was using it) and then it started causing some problems.

As a side note, It would be nice to have a RESTful interface to one of
these tables so client-side only tools can persist small bits of arbitrary
preference data back to the server, though I'd probably prefer to not have
these bits of data encoded in base64 and serialized in XML fields. ;)

-Matthew

On Tue, Jun 26, 2012 at 1:06 PM, Bryan Holladay <holladay at longsight.com>wrote:

> Matt Jones beat me to it and fixed the User Properties issue.  His
> patch users the user preferences instead [1].  I assume this is the
> preferred way since User Properties depends on an internal user?
> Should this dependance be removed?
>
> -Bryan
>
> [1]
> http://source.sakaiproject.org/viewsvn/portal/trunk/portal-impl/impl/src/java/org/sakaiproject/portal/charon/SkinnableCharonPortal.java?p2=%2Fportal%2Ftrunk%2Fportal-impl%2Fimpl%2Fsrc%2Fjava%2Forg%2Fsakaiproject%2Fportal%2Fcharon%2FSkinnableCharonPortal.java&p1=%2Fportal%2Ftrunk%2Fportal-impl%2Fimpl%2Fsrc%2Fjava%2Forg%2Fsakaiproject%2Fportal%2Fcharon%2FSkinnableCharonPortal.java&r1=109685&r2=109684&view=diff&pathrev=109685
>
> On Tue, Jun 26, 2012 at 11:10 AM, Bryan Holladay <holladay at longsight.com>
> wrote:
> > I did... thanks... It's really flexible and uses REST (entitybroker)
> > and JSON/AJAX.
> >
> > You just specify the jQuery selector string and then fill in the
> > details.  If it can't find it, it just goes to the next page.
> >
> > Example: help-component/src/bundle/TutorialMessages.properties
> >
> > then just call it with the function:
> "showTutorialPage("{propertiesPrefix}")
> >
> > So this can easily be added to any tool.
> >
> > -Bryan
> >
> > On Tue, Jun 26, 2012 at 11:03 AM, Adrian Fish <adrian.r.fish at gmail.com>
> wrote:
> >> Did you write this? If so, nice one, well needed.
> >>
> >>
> >> On 26 June 2012 15:57, Bryan Holladay <holladay at longsight.com> wrote:
> >>>
> >>> There's a jira out for this.  I was planning on looking at it next
> >>> week, but it sounds like you've already deduced the issue.
> >>>
> >>> https://jira.sakaiproject.org/browse/SAK-22320
> >>>
> >>> So, why is there a foreign key restraint to Sakai_user and how are you
> >>> supposed to store properties for provided users?
> >>>
> >>> -Bryan
> >>>
> >>> On Tue, Jun 26, 2012 at 10:54 AM, Adrian Fish <adrian.r.fish at gmail.com
> >
> >>> wrote:
> >>> > I think there is an issue with the floating tutorial in trunk. Every
> >>> > time I
> >>> > login as an LDAP provided user I get the tutorial and I think it may
> be
> >>> > to
> >>> > do with the fact that it tries to write a property
> 'sakaiTutorialFlag'
> >>> > to
> >>> > SAKAI_USER_PROPERTY. Trouble is, SAKAI_USER_PROPERTY is foreign keyed
> >>> > onto
> >>> > SAKAI_USER and that never contains provisioned users. I've not
> looked at
> >>> > the
> >>> > code, I'm just guessing.
> >>> >
> >>> > Why is there a foreign key constraint on SAKAI_USER_PROPERTY, just
> out
> >>> > of
> >>> > interest? It seems a bit weird that we can't store props against
> >>> > provisioned
> >>> > users.
> >>> >
> >>> > Cheers,
> >>> > Adrian.
> >>> >
> >>> > _______________________________________________
> >>> > 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20120626/7615885a/attachment.html