Forum .LRN Q&A: permission problem with head.
I installed openacs/dotlrn from head. After
login as site-wide-admin and adding myself to
dotLRN I am not able to browse any dotLRN pages.
I keep getting redirected to the page with -
"Thank you. Your registration request has been sent to the System Administrator"
Any idea what could be wrong?
Thanks for any hints.
I'm putting this on hold until changes are merged forward from 4.6 to HEAD.
No one's expecting to be able to run a production site from HEAD at the moment I hope. This isn't the only problem you'll run into and you're not going to get promises of upgrade scripts from old-HEAD to post-4.6-merge-HEAD ...
No one's expecting to be able to run a production site from HEAD at the moment I hope.In fact I'm just about to put a site into production that's based on HEAD, last checkout 2003-03-07.
The main reason for using head is the cool i18n capability, makes more sense to use it rather than to hardcode translations in the .adp files (will contribute is_IS catalog files when I finish translating, or sooner if anyone wants what I already have).
The site does not use dotLRN, just plain OpenACS plus a custom package (which I'd like to contribute when I've generalized it a bit; it offers email subscriptions to RSS feeds and currently has a hardcoded interface in Icelandic, a bit similar to Simon's News Aggregator).
I know HEAD is not as safe as a numbered release, but am I making a seriously bad descision?
After last merge there was some problem which I submitted to bugracker with a suggested fix. Things seem to be running nicely now and I don't think I'll merge with OpenACS HEAD again before going live. But will a non-acs-core hacker like me have trouble keeping up with head in the future?
Reading an entry in Peter Marklund's blog, Back on the Edge of OpenACS Development, made me a bit more confident going this way :)
That will be a lot of changes but hopefully not too many conflicts to resolve.
If you are patching bugs on your copy I would suggest you submit patches since if you do so, they will get applied to head and reduce the number of conflicts you will have to resolve yourself (this is a general suggestion to everyone, not you in particular :) )
I keep a local vendor branch and will be sure to test any merges on a separate checkout before updating the live checkout.
Uploaded a patch to that bug report now, just not sure if it's good for all usecases, haven't studied the changes to that proc well enough.