LDN - Luminis Developer Network

Hi,

I've noticed that the file system (directories) is different from LP3. For an example, in LP3, rdbm.properties is in $CP_WEBINF/config but in LP4, it's in $CP_WEBINF/uPortal/properties. Where can I find more information about this file system changes?

Thanks,
Arion

Sometimes, I have to rebuild Luminis user accounts. Usually I export the user's full calendar data, then delete the account, recreate it, then import the xml file back into the new account. But I lose...

1) the user's calendar sets and
2) their subscribed list

Anyone know an easy way to maintain this information so the user doesn't have to rebuild these items on their end?

Thanks,

MLC

Hi folks,

I am attempting to create a new fragment in Luminis IV. The fragment is easily created in the Fragment Manager; however, the new fragment's owner is set up as "dlmf_24" (or some other generic account).

How do I change the owner for the fragment (to an account like "newfragment-lo") so that the fragment can be managed by that owner?

If this answer is in the byzantine documentation, please point me to that. I have had no luck so far....

Thanks in advance!

Does anyone have a script to re-deploy banportals? We are running on a load balanced system and for some reason one of our ocj4 banportals_prod instances degrades over time causing 404 errors (among others).

I would like to re-deploy these instances nightly.

Our OAS server is Linix based.

Thanks

Dave

At U of S, we assign some temporary passwords to students and then mail them a letter with their temp password printed on it.

If a student attempts to log in with a temp password, then instead of getting into Luminis, we send them over to our identity management web interface, where they need to set a permanent password.

I have removed the java code for generating and comparing temporary passwords, so it may not compile as-is. However, you will get the basic idea. Also, you will see where we set a cookie on login. You could set your own cookie as needed.

During summit I was reading up on Subversion (http://subversion.tigris.org/). I came across a blog post that said "the blog you are reading now, is a checkout from a subversion repository.

It got me thinking about how I maintain my test and production systems. In particular, the challenge of keeping track of all the changes across the systems. Several times I've had the installation of a patch on our test systems act differently than the same patch installed on our production systems.

There were several great sessions at Summit about using CAS to integrate external applications into Luminis. I found that it was pretty easy to set up phpcas on a web server and bring a simple php app into a tab in the portal.

I found a Wordpress plugin which will basically CASify Wordpress.

However... when including a Wordpress page in the portal using an inline html frame, I have a problem.

Logging out of Lumnis does not seem to kill the CAS credentials. The user still has access to Wordpress, even though they are logged out of Luminis.

Has anyone implemented a custom role generated in Banner and fed into luminis within the Lum IV portal?

According to the docs, it looks simple. We've set up the Banner side easily, and I can see a customrole coming across in our LMG data log, ldi_event_data.log. It appears though, that Luminis is ignoring this. I do not see the custom role being added to the persons ldap record. However, other attributes of the same event do get processed (like a name change), so events in general are working.

I'm running Lum IV on Linux and have developed a cptool problem. We're not quite sure when the problem started or why but here it is ..

When using get user, set user and import ims, ( there are probably others), I get the following message...

ERROR: Event notification subsystem initialization failed. This is
> most likely because the JMS provider is not accepting connections.
> Aborting command.

I haven't changed anything, and those with poking rights say they haven't either...it just stopped working.

Mulling over our cpip connectors made me realise that we should certainly not be using port 8008 as the cpipconnector port - particularly in the case where you are using pickup response rather than putting pickup.html on the external system. The obvious reason is that 8008 is very likely to be providing authentication info to the user's browser, albeit in a form that the user hardly notices, and then submitting it securely to the external system. And port 8008 isn't secure as it stands.