[xwiki-devs] [Brainstorming] Document's Hidden flag behaviour with translations?
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. WDYT? Thanks -Vincent
+1 for 2 -0 for 1, I do not forsee any useful case. Thanks, On Thu, Jan 23, 2014 at 12:11 PM, [email protected] <[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.
WDYT?
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
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. 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 -- Sergiu Dumitriu http://purl.org/net/sergiu
+1 for 2), it seems more simpler from the user point of view. 0 for 1) 2014/1/23 Sergiu Dumitriu <[email protected]>
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.
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 -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Jan 23, 2014 at 2:49 PM, Sergiu Dumitriu <[email protected]> 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.
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.
This is not a valid use case, it could be better solve using access rights. Hiding document is not really for user document but is there for hiding technical document from search results and other navigations. It is for sure a bad practice to use it to control a publishing workflow IMO.
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 -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
On 01/23/2014 10:18 AM, Denis Gervalle wrote:
On Thu, Jan 23, 2014 at 2:49 PM, Sergiu Dumitriu <[email protected]> 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.
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.
This is not a valid use case, it could be better solve using access rights. Hiding document is not really for user document but is there for hiding technical document from search results and other navigations. It is for sure a bad practice to use it to control a publishing workflow IMO.
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.
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
-- Sergiu Dumitriu http://purl.org/net/sergiu
On Thu, Jan 23, 2014 at 4:22 PM, Sergiu Dumitriu <[email protected]> wrote:
On 01/23/2014 10:18 AM, Denis Gervalle wrote:
On Thu, Jan 23, 2014 at 2:49 PM, Sergiu Dumitriu <[email protected]> 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.
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.
This is not a valid use case, it could be better solve using access rights. Hiding document is not really for user document but is there for hiding technical document from search results and other navigations. It is for sure a bad practice to use it to control a publishing workflow IMO.
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.
I mean it is not valid because there is a far better practice with rights I am not against a per translation solution if it prove to be really useful, but currently I cannot find an interesting use case, only potential issues and UI complexity.
And access rights can't help here, since rights are objects, which can only be attached to the main document.
I do not get that point ?
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
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
On 01/23/2014 10:49 AM, Denis Gervalle wrote:
On Thu, Jan 23, 2014 at 4:22 PM, Sergiu Dumitriu <[email protected]> wrote:
On 01/23/2014 10:18 AM, Denis Gervalle wrote:
On Thu, Jan 23, 2014 at 2:49 PM, Sergiu Dumitriu <[email protected]> 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.
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.
This is not a valid use case, it could be better solve using access rights. Hiding document is not really for user document but is there for hiding technical document from search results and other navigations. It is for sure a bad practice to use it to control a publishing workflow IMO.
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.
I mean it is not valid because there is a far better practice with rights I am not against a per translation solution if it prove to be really useful, but currently I cannot find an interesting use case, only potential issues and UI complexity.
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.
And access rights can't help here, since rights are objects, which can only be attached to the main document.
I do not get that point ?
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.
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
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Sergiu Dumitriu http://purl.org/net/sergiu
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
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
-- Denis Gervalle SOFTEC sa - CEO
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
I think we should stick with option 1 for 5.x. We can discuss about option 2 for 6.x, although I feel there are more important things to work on :) Thanks, Marius On Thu, Jan 23, 2014 at 1:11 PM, [email protected] <[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.
WDYT?
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I agree with Marius. I’ll try to find the time to do 1) for 5.4. We can then review it later for 6.x. Thanks -Vincent On 23 Jan 2014 at 23:11:39, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:
I think we should stick with option 1 for 5.x. We can discuss about option 2 for 6.x, although I feel there are more important things to work on :)
Thanks, Marius
On Thu, Jan 23, 2014 at 1:11 PM, [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.
WDYT?
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (7)
-
Clemens Klein-Robbenhaar -
Denis Gervalle -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Sergiu Dumitriu -
Sergiu Dumitriu -
vincent＠massol.net