> > b) it could be fixed by a custom save handler of the dialog which > > compares modification dates. Tricky but feasible I would say. > > The separation by design may help in most cases, until client's > requirement and business logic don't kick in something. > First reasonable example that comes in mind is that the user can edit > his/hers own email, and the admin can also do that when password > recovery fails. So the email field won't fit in Jan diagram without a > couple of tricks (maybe duplicated fields with the same name in the two > branches, with loading priority). > And by the way, it happened to me that a user closed the mail account > and forgot both password AND username... :-)
just pointing out obvious in this case, not trying to reduce the severity of the problem: since the user forgot password, user can't log in so admin is save to edit even properties that can be normally changed by the user ;) And yes I agree there are always scenarios which you can't fix by design and then you get to use locking. This is simple fact. One has to balance complexity of design choices against the complexity of using the locking mechanisms. > > > The "Backpublishing" option is the best IMO, if you actually need the > > content on the author instance that is. I like this solution because it > > is rather easy to set up and it is fully consistent with the Magnolia > > setup. But maybe I'm really missing something, so I really appreciate > > this discussion. > > We are discussing just to see if there is a general one, and everybody > is proposing the solution that fits better with his clients' requests > and problems encountered. I even started doubting the solution I advised > (dedicated UGC repo set but clustered between author and public) is > really fit for all cases... My biggest issue with this solution is that it goes against the grain of having dedicated disposable public instance. Once clustering goes back to the author, you have just one copy of the data so if given repo gets corrupted on the public, be it for technical reasons or intentional action by humans, the data is lost for good. To keep this intention, perhaps backpublishing & versioning on author after receiving copy of the content from public would be the safest course of action. It still doesn't solve the problem of having to open door in public so that public can go and send data back to author. To solve this last issue, you would perhaps just use scheduled task on the author and periodically pull the data from public rather then having public to push it to the author. Jan ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
