+1 for 2), it seems more simpler from the user point of view. 0 for 1) 2014/1/23 Sergiu Dumitriu <sergiu(a)xwiki.com>

On 01/23/2014 10:18 AM, Denis Gervalle wrote: It is a _valid_ use case, but it is not a very good one. I agree that there are much better ways of restricting access to documents than the hidden flag. And access rights can't help here, since rights are objects, which can only be attached to the main document. -- Sergiu Dumitriu http://purl.org/net/sergiu

On 01/23/2014 10:49 AM, Denis Gervalle wrote: I agree. But you cannot control what users do. XWiki committers have the knowledge required to use better solutions, or peer reviews can correct mistakes when they do happen. However, users can choose the solution they want, even if it's a bad one. Many users do complex stuff far away from the mainstream development, and they are often 2-3 years behind our releases. Curriki is a good example of a complex project that had difficulties upgrading when we broke odd usecases that they relied on. Upgrading does work in the end, and they do get a better implementation, so it's good when we get rid of odd behavior, but it requires a lot of effort from downstream projects. I'm playing the user's advocate here, this is not a usecase I personally would require. Anyway, my main concern is technical, not usecase-related. So, querying for a document translation that is not hidden: from XWikiDocument doc, XWikiDocument mainDoc where doc.translation = 1 and mainDoc.translation = 0 and mainDoc.hidden = 0 and doc.fullName = mainDoc.fullName (and then other actual conditions) In case the query manager is used, then all this can go into the "exclude hidden documents" filter, which can be optionally combined with the "exclude translations" filter, which would require that filters are aware of each other. Or we would have to write a new filter to be explicit, "exclude translations and hidden documents" which makes it harder for query authors to decide what filters they want applied, and it would make the "exclude hidden docs" filter query even more complex: from XWikiDocument doc, XWikiDocument mainDoc where ((doc.translation = 1 and mainDoc.translation = 0 and mainDoc.hidden = 0 and doc.fullName = mainDoc.fullName) or (doc.translation = 0 and doc.id = mainDoc.id and doc.hidden = 0)) (the useless mainDoc == doc condition is required since you cannot add another "from" on just one subset of "where", unless we use a subquery with "exists" which is also bad for performance) Or we would have to add some logic to ensure that every translated document row in the database always has the same value as the main document, which requires a migrator to set initial compliance, more complex doc saving logic (and cache invalidation), more complex and unexpected fromXML behavior (when does the hidden flag on a translation get synced with the master?)... Do I prefer 2) as a user? Yes. Do I feel comfortable making all the changes required to make it work correctly? Definitely not for 5.x, and not without a long time of testing it in real usage. I would rather add this as a required feature for the future model and storage replacements instead of making so many changes in oldcore. If you have a simpler technical solution, I'd be more than happy to hear it. I said that users could want to hide specific translations of a document. You said they can set rights to restrict access to those specific translations. I said they can not set rights on translations, since objects don't take into account translations; objects are global. Not using translations but other documents is a solution, but then it has nothing to do with translations, and the documents aren't related anymore, so it's an entirely different usecase. -- Sergiu Dumitriu http://purl.org/net/sergiu

Clemens, It looks like you mixup 1) and 2), did you ? On Thu, Jan 23, 2014 at 5:21 PM, Clemens Klein-Robbenhaar < c.robbenhaar(a)espresto.com&gt; wrote: -- Denis Gervalle SOFTEC sa - CEO