In addition, when an import has started set a session variable that the preExecute checks for. If the session variable is set, redirect to page with message that an import is busy. If the session variable is unset, continue with import. Once an import finished unset the session variable.
On Mon, Oct 25, 2010 at 1:15 AM, Daniel Lohse <[email protected]>wrote: > Are those all admin-generated modules? If so, you can specify the base > class to use. Just create a new class (myActions or so) and specify this > base class in all generator.yml files. This base class must inherit from > sfActions. You can then provide your own preExecute method and do the logic > check in there — don't forget to call the parent's preExecute method though, > otherwise your modules will not work correctly. In your own preExecute > method you can forward to a landing page telling the user that an import is > running etc. — you probably already have something in mind for this. :) > > Hope this is helpful, > > > Cheers, Daniel > > Sent from my iPad > > On Oct 25, 2010, at 12:04 AM, Joshua <[email protected]> wrote: > > > I have an admin application with various modules set up. In one of the > > modules a user can schedule an "import" can often take a considerable > > amount of time to complete. While the import is running, no changes > > should be made to the database. > > > > I'm looking for a solution to lock down the admin while the import is > > running. I want to prevent any modules from making admin changes > > through the forms. How can I insert a global logic check to see if an > > import is running? The alternative would be to have the code for the > > logic check in every module action, which is not preferable. The only > > other way I can think of is to put the code in the layout, but you're > > not supposed to run queries from the templates. > > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > > > You received this message because you are subscribed to the Google > > Groups "symfony users" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<symfony-users%[email protected]> > > For more options, visit this group at > > http://groups.google.com/group/symfony-users?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-users%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- Gareth McCumskey http://garethmccumskey.blogspot.com twitter: @garethmcc -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
