On 06/21/2012 02:34 PM, Jason Guiditta wrote:
On 20/06/12 18:09 -0400, John Eckersberg wrote:
Previously, the default admin user was created by aeolus-configure, but this approach was confusing for users. By creating the admin as part of the database seeds, we are guaranteed to always have a usable admin user at first login. The expecation is for administrative users to be managed via the web UI (or API), not via configure.
src/db/seeds.rb | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
I have not tested this, but looks reasonable on quick viewing (this is not an ack or nack btw). However, I am wondering if this could/shoudl be added $elsewhere, like scott did with the new roles, which I believe gets called via our rake dc:upgrade script. I guess it might be safe for an existing installation, and I wil roll with that if you think it is, just wanted to make sure we thought of that case before introducing new seed data.
-j
This isn't relevant to the current patch, as that's been reverted/abandoned, but I wanted to clarify one thing. You're referring to my recent patch that changed a couple role definitions. Since role defs are defined in seeds.rb, my patch _did_ include a change to seeds.rb. Of course, seeds.rb is only executed on a new db load, so the issue was that only changing seeds.rb works for new installs, but upgrades to existing installations don't get the change. Therefore role updates needed to show up in two places: 1) in seeds.rb, since that's the canonical place (at least for now) for this data to be loaded from, so not putting it there would break new installs 2) somewhere else that gets executed only on upgrade. It could have been a migration, but we decided not to do that, since there's no actual schema change involved. Therefore we decided to create a new mechanism -- a 'dc:upgrade' task to be run after migrations on an existing installation to do various other upgrade-oriented work that doesn't involve migrations/schema changes.
This patch (if we were sticking with that plan) handles 1) already. We wouldn't need to handle 2), since if we're upgrading an existing installation, the admin user will have already been created, so it wouldn't matter that the default 'load new admin' procedure had changed.
Scott