content permissions rebuilt before scheme is saved [#1093590]

My apologies if this issue is documented elsewhere, or if I am just plain missing something here.

I am planning on applying this module to a production site with an existing taxonomy, but it does not seem possible to set it up in production without at least a little down time, or some form of workaround for this issue.

Once the module is installed and content settings rebuilt, the next step is to start setting things up at admin/user/access/tac_lite. However, once an existing vocabulary is selected and the settings are saved, the content permissions are rebuilt automatically. If I am logged out of the site in a different browser, and I refresh a page (that utilizes the selected vocabulary) at this point, all pages are inaccessible to non-admin users until I grant them permission to view things in a "scheme." I haven't read the code, but perhaps an extra setting for live/setup mode could be added to eliminate this issue during configuration?

Comments

Comment #1

Dave Cohen commented 16 March 2011 at 16:00

Title:

Unable to install for use with existing taxonomy without "Access Denied" errors for Anonymous users during setup

» content permissions rebuilt before scheme is saved

You're saying permissions should be rebuilt after saving a scheme, but not after submitting the taxonomy select form?

Even if that is fixed, I recommend you take the site off-line while you set this up. And of course backup data before setting up as well.

Comment #2

John Carbone commented 16 March 2011 at 16:47

"You're saying permissions should be rebuilt after saving a scheme, but not after submitting the taxonomy select form?" Yeah, that would make sense to me as an alternative method as well. It just struck me as odd that once a vocabulary is selected, the module immediately jumps in and basically sets defaults that lock users out until the module is completely configured.

Regarding taking the site offline, it's a high traffic site and the client is very sensitive to downtime, which is why i raised the issue. Deployments always start with a backup of the db, then an svn switch, then what we call "admin steps" or a list of pages to visit and configuration settings to apply, that have been tested in sandboxes and staging. In the vast majority of deployments, we don't have to take the site offline and try to avoid it if possible. No big deal though. I'll let them know that it's required in this case. I'm just glad I caught it when testing. Thanks for all your work on this project!