One wrinkle is that we (I) moved these tasks in 1.7.1 such that they are
no longer scheduled tasks executed by the OpenMRS scheduler, but rather
tasks managed directly by Spring's built-in scheduling mechanism. The
main reason for making this change was that I didn't like how the
OpenMRS scheduler-based Scheduled Tasks hung around after the module was
un-installed and also because I was running into some Classloading
issues. With Spring-managed scheduled tasks, these issues disappear -
the tasks are run if the module is installed, and not run if it isn't.
The main drawback is that the end user can't start / stop / delete these
tasks from within the management pages, but these are not meant to be
optional or configurable - they are things the reporting module relies
on working in a specific way, so shouldn't be end-user modifiable.
On 04/10/2012 06:37 PM, Ben Wolfe wrote:
The gps should not be set by openmrs after 1.7 the daemon user is used
instead. The reporting module should work like the logic module and
only authenticate if pre 1.7.
I like the idea of clearing the scheduler gp, but that might mess up
modules like reporting that haven't updated to not use the
authenticated user.
Isnt there an authenticate() method that should be called? Is that
still looking fur the scheduler username/pw in gps?
Ben
On Apr 10, 2012 6:24 PM, "Darius Jazayeri" <[email protected]
<mailto:djazayeri%[email protected]>> wrote:
Wyclif,
That won't solve it--when you go through the setup wizard, you are
required to enter a strong admin password ("test" is not allowed),
so what Mark is describing is the issue that as soon as you've set
up OpenMRS for the first time, you are guaranteed to have
incorrect GP values for scheduler.username and scheduler.password.
As a result, your admin account will soon be locked out, and it
will stay that way forever due to the scheduled task.
Options:
1. clear the scheduler.password property, and make sure that
scheduled tasks don't try to run as admin if that isn't set
2. the setup wizard could set scheduler.password to the new admin
password (but this is insecure)
3. change the reporting module to /not/ use those GPs, but rather
to use an anonymous user, but grant proxy privileges...
-Darius
On Tue, Apr 10, 2012 at 2:29 PM, Wyclif Luyima <[email protected]
<mailto:[email protected]>> wrote:
Are you running the standalone or are you using the 1.9 demo
data from the demo data downloads page?
If yes to any of the above, I ran into this and i think the
password for admin was changed from *test*, try *Admin123*, we
need to change it back to *test*
Wyclif
On Tue, Apr 10, 2012 at 4:55 PM, Mark Goodrich
<[email protected] <mailto:[email protected]>> wrote:
I’m having problems logging in to OpenMRS 1.9 after doing
a clean install (as opposed to an update of an existing
database). Has anyone else run into this issue? This is
what I think might be happening:
https://tickets.openmrs.org/browse/TRUNK-3272
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
