Hi Densi, yes, I mixed them up :( sorry for that
(now me checking what queries with hidden, translated document really do now ...) > Clemens, > > It looks like you mixup 1) and 2), did you ? > > > On Thu, Jan 23, 2014 at 5:21 PM, Clemens Klein-Robbenhaar < > [email protected]> wrote: > >> On 01/23/2014 02:49 PM, Sergiu Dumitriu wrote: >>> On 01/23/2014 06:11 AM, [email protected] wrote: >>>> Hi devs, >>>> >>>> I’m working to fix http://jira.xwiki.org/browse/XWIKI-9910 but before >> I can fix it we need to decide something since we have 2 possibilities. >>>> >>>> - Option 1: The hidden flag is set at document translation level which >> means when the user check the hidden flag it’s only for the current >> translation >>>> - Option 2: The hidden flag is set at the default document level (not >> set at translated doc level) which means there’s a single hidden flag >>>> >>>> ATM the problem with XWIKI-9910 is that when the user checks the >> hidden flag, it’s set at the translation level but when a translation is >> displayed the value shown is the one from the default document. >>>> >>>> Option 1 offers more use cases but: >>>> - users may be surprised >>>> - users need to be careful to edit the default doc if they wish to set >> the doc as hidden for all translations >>>> >>>> I’m not sure what option I prefer. Initially I was more for option 2 >> but I’m now hesitating and leaning more towards option 1. Note that option >> 2 means one more DB upate when saving a translated doc. >>> >>> I'm not sure 2 is going to work that easily, since by default queries >>> don't filter by the "translation" flag. 2 means that we have to change >>> every query (impossible if we count user queries), or the way the search >>> APIs work (backwards incompatible). >>> >>> So +1 for 1. >>> >> >> When first reading the original proposal I was more for 2) but I have not >> thought about the queries. >> Then I thought more about the queries and I feel 2) might still be better, >> even though it breaks backwards comaptibility. >> But then again I wondered about the relase that wants to get out of the >> door, and feel that 1) is betterfor noe >> and 2) might be added as a "new feature" later on. >> >> >> about 2): Looking at the database structure might such a change make the >> queries actually simpler and faster? >> I.e. "give me all non-hidden docs in language X" : now it needs to fetch >> the default document from the xwikidoc >> beside of the language variant to access the hidden field, but with Option >> 2 it needs only the "current language" >> >> About Backwards compatibility: >> I guess users who are smart enough to be able to wrote HQL are hopefully >> able to read release notes >> and update their queries (or to accept that such stuff breaks). >> >> The bigger risk is that all hidden flags in all translations of hidden >> documents need to be updated everywhere, >> and the queries need to be updated. This is actually looking like 2) might >> introduce a trail of little bugs ... >> normally that should be ok, but maybe not the best idea for wanting to >> have a stable 5.4 release soon? >> >> >> From the users point of view I feel we have less confusion with 1) even >> though it is less flexible. >> Normal users never need to define "hidden" documents, because it is only >> meant for "technical things", >> but they might check that box just to figure out what it does anyway, >> forget about it and create confusion later ;) >> So the less complex that thing is, the better, and having only one >> "hidden" flag makes it easier to figure >> why that document X does not longer show up in the search ... >> >> >> So unless I greatly overestimate the issues with rewriting the queries I >> am more for 1) >> >> >>> Use case: the master document is visible, and it is an important one >>> (legal contract, license, official documentation...). Translations are >>> being worked on. While a translation isn't approved, they'd like it to >>> be hidden. >>> >>> UX proposal: >>> >>> - when a translation is created, it copies the hidden field from the >> master >>> - when a user changes the master's hidden status, a dialog shows up >>> asking if all the translations should be changed as well or not >>> - when a user changes a translation's hidden status, a dialog shows up >>> asking for a confirmation if it's different from the master, warning >>> about the possible issues caused by a difference in the flag >>> - we display the hidden status of the translation in the UI >>> >> >> On the other hand the UX for case 1) is simpler: >> - if editing the default version of the document, keep current UI >> - if editing a translation, show a text displaying the value of the >> hidden flag >> and a note that this can be changed in the default language. >> >> BTW: Would it be much work to hide the "Hidden flag" UI from "simple" >> users, btw? >> (If this affects the "save" method because currently not submitting the >> value >> for the hide-flag makes the save method assuming that is not set, then >> just forget about it now.) >> >> >> Clemens >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > mit freundlichen Grüßen Clemens Klein-Robbenhaar -- Clemens Klein-Robbenhaar Software Development EsPresto AG Breite Str. 30-31 10178 Berlin/Germany Tel: +49.(0)30.90 226.763 Fax: +49.(0)30.90 226.760 [email protected] HRB 77554 B - Berlin-Charlottenburg Vorstand: Maya Biersack, Peter Biersack Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber Zertifiziert nach ISO 9001:2008 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
