Recently I was just thinking along the same lines (must be result of our other discussions :D )
The export/import functionality is heavily used and for many different purposes, so no matter what policy we would implement, there will be always the cases that would not fit. That is specially true when you take in account the fact that you can select different behavior in regard to UUID on import. Having the incorrect status is indeed more dangerous in case of using the Synchronization (which BTW should be able to do the complete sync soon, not only the previously activated content). What happens technically is that Magnolia takes the bootstrap file and passes it through to the JCR API at which point there is no direct control in Magnolia about imported content. Either it is valid and will get imported or not. If you want to tweak anything here, there are only few options: - either pre-process the xml (parse and update the value accordingly) or - post process the imported content via combination of observation and custom import command. - another possibility would be to modify export to automatically set all status to unactivated while streaming the xml to the client. None of the above is ideal or desirable in all cases, which leaves it in the hands of developer to be careful about the status. If you can find out solution that would cover most of the cases while leaving the options for the rest and would not introduce extra overhead on import/export, the contribution would be most welcome. Another possibility that came to my mind was about either allowing more status values or keeping the origin of the node (and set it to "imported" for all imported nodes). HTH, Jan On Dec 6, 2010, at 12:06 PM, Jörg von Frantzius wrote: > Hi, > > if I'm not mistaken, Magnolia currently exports the activation state of > content, and also imports this state unmodified along with imported content. > There already exists an issue "MAGNOLIA-2189 Imported node incorrectly shown > as activated", which has been marked as "Won't fix". Possibly this had > already been discussed elsewhere, but here's my 2 cents on this one anyway... > > When e.g. content is exported from a staging system and then imported on a > live system, it may show up incorrectly as published on the live system (if > it had been activated on the stage system previous to the export). It's easy > to imagine all kinds of confusion that arises from this among editor users, > at the latest when a user other than the person who imported the content sees > the publication state, and starts to wonder why it does not show up on the > public instances, or worse, may assume that it is already published when in > fact it isn't. > > From what I understand, this can become more dangerous when using the > Synchronization Module for setting up a new public instance: then content may > get activated only on the new public instance, while it is not activated on > the existing instances, so consistency of published state becomes violated > among the public instances. > > IMHO, Magnolia should at least check for existence of imported content: when > importing new UUIDs, the respective nodes should be shown as red (never > activated). When importing existing UUIDs, it would be perfect if Magnolia > could perform a comparison of content (ignoring creation date and last > modification date): when an imported node is not equal to an existing node, > then it should be flagged as changed, otherwise the publication state should > stay the same it was in the repository. Ideally, this would be a bit like SVN > determines outgoing changes. > > I'm not sure how hard this kind of comparison is to do, though... > > WDYT? > > Regards, > Jörg > > > > > > > > > -- > Dipl. inf. Jörg von Frantzius, System Architect > Email mailto:[email protected] > Phone +49 30 283921-318 > Fax +49 30 283921-29 > Aperto AG - In der Pianofabrik > Chausseestraße 5, D-10115 Berlin-Mitte > Web http://www.aperto.de > HRB 77049, AG Berlin Charlottenburg > Vorstand: Dirk Buddensiek > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
