Re: Re: ZopeUndo.Prefix is still used
Sean Upton <[email protected]>
| Newsgroups | gmane.comp.web.zope.zodb |
|---|---|
| Message-ID | <CANjV-2PM+FKM=iucuUeAr0sQJyMv3MZTvEUgptkA+O35ddWi0w@mail.gmail.com> |
On Mon, Aug 15, 2016 at 1:03 AM, Maurits van Rees < [email protected]> wrote: > Op 14/08/16 om 15:04 schreef Hanno Schlichting: > >> Hi again. >> >> Looking into this a bit more, I changed the Zope2 code on master and >> dropped the ZopeUndo dependency. >> >> Undo management in Zope2 is now available in its ZMI control panel on >> each configured database object, instead of contextually on ZMI folders. >> > > I *do* consider it handy if I can go to the ZMI on the Plone Site level > and have an Undo tab there. Depending on how you have setup your web > server (nginx/Apache), you may not even be able to get to the Zope root > without resorting to tricks like ssh port forwarding. > Your hosting arrangement adds another wrinkle, too. Adding a path in a transaction note always presumes that you are using the same virtual host, because of the way Zope2's VirtualHostMonster works. I end up jumping through hoops of constructing paths simulating one of my canonical URLs in cron jobs, and then can only access path-specific undo ZMI using just that URL. In the end, when I undo in ZMI, it is from the application root half the time. I have ZMI manage_* URLs blocked by nginx on the primary hostnames used by my sites; using SSH port forwarding or my alternate administrative URL, I cannot Undo by path anyway, for the /VirtualHostBase/* prefix reasons described above. For Plone, I am working out ways to have higher-level restore functionality presenting some users restore/undelete functionality to make Undo-by-path in ZMI less needed; this would present a nice user interface around use of zc.beforestorage under the hood. I intend to write a PLIP and prototype for this sometime this fall -- see some discussion here: https://github.com/plone/Products.CMFPlone/issues/818#issuecomment-213573761 If we can have such higher-level facilities in the application for restoration (un-delete, or restore previous) by path, then path-specific-enumeration of transactions that can be undone seems like less of a need -- making transaction Undo by administrator something done in the ZMI at the application root, as a mechanism of last resort? Sean -- You received this message because you are subscribed to the Google Groups "zodb" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.