Hi devs,
I’ve been thinking about how to improve our release process regarding the backward compat checks (we were using clirr for this and now revapi).
In short the idea is:
* Store the revapi config (containing the list of breakages to ignore) in a wiki page on xwiki.org, associated with a given release note. For example in ReleaseNotes.BackwardCompatibilityForXWiki${xwiki.version.major}${xwiki.version.minor} (using http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html)
* Configure our build to download that json file and store it in target/ for revapi, see https://github.com/revapi/revapi/issues/31#issuecomment-200286810
* Work on making it not fail the build when offline (see https://github.com/revapi/revapi/issues/31#issuecomment-200286810)
* Write some groovy script in the release notes template page to automatically generate the “API Breakage” section from the parsed json from ReleaseNotes.BackwardCompatibilityForXWiki${xwiki.version.major}${xwiki.version.minor}
WDYT?
Thanks
-Vincent
Hi,
This is a brainstorming aimed at fixing:
* http://jira.xwiki.org/browse/XWIKI-10384
* http://jira.xwiki.org/browse/XWIKI-12033
In addition I believe we need to support the following use cases:
* UC1: (Simple) users should be able to see documents in the currently selected UI language and documents with no translations
* UC2: (Advanced) users should be able to see all documents in the wiki (i.e. all translations + all docs with no translations)
* UC3: It could be interesting to have an option to limit the translations to the list of configured languages of the wiki
ATM the issues is that:
* the “currentlanguage” query filter is not implemented properly and returns duplicates (the default language + the translation)
* sorting can fail
* there’s no way for an advanced users to see all translations in the AllDocs LT
Also note that Marius (who’s discovered the problem) as commented at http://jira.xwiki.org/browse/XWIKI-9229
There are several solutions I can imagine
Solution 1
========
The idea is to implement a query filter that returns “a given language + the default language if there’s no translation”. It can be done, see http://jira.xwiki.org/browse/XWIKI-9229?focusedCommentId=90654&page=com.atl…
Pros:
- Generic solution that would work wherever we use the query manager in the wiki
Cons:
- it’s “slow”.
- It’s also not solving UC2 and UC3.
Solution 2
========
When the wiki is in multilingual mode, add a “Language” column in the LT and display all docs having translations in one of the configured languages of the wiki + all docs with no translations.
The user will see duplicates but the “Language” column will indicate clearly that they are different translations.
Pros:
- This would fix UC3, partially UC2 and partially UC1.
Cons:
- Not a generic solution; only solves the issue for the AllDocs LT (and the other places where we want to do the same).
Solution 3
========
(initially proposed by Marius)
Have a toggle with several states somewhere in the AllDocs UI (could be outside of the LT) to be able to choose different results:
* Only docs in the current UI language
* Only docs that don’t have translations
* All docs
* All docs in one of the configured languages of the wiki
Note that from a wiki syntax POV, this could be a parameter in the {{document/}} live table.
Pros:
- This would fix UC2, UC3 and partially UC1.
Cons:
- Not a generic solution; only solves the issue for the AllDocs LT (and the other places where we want to do the same).
Solution 4
=========
Modify the DB schema and add a column in the xwikidocs table to indicate if a doc has translations. This would mean updating it when a new translation is created and when a translation is removed.
Pros:
- Fast query
- Generic solution that will work with any query using the query manager
Cons:
- Requires a DB update
Conclusion
=========
Solution 4 seems to be the only real generic solution.
WDYT? Any other idea?
Thanks
-Vincent
Oh, and the value must be 1 to enable.
On 03/21/2016 08:29 AM, Sergiu Dumitriu wrote:
> That's an object property, so you can use a normal page REST call to set it.
>
> page: XWiki.XWikiPreferences
> object: XWiki.XWikiPreferences[0]
> property: authenticate_view / authenticate_edit
>
> On 03/21/2016 08:07 AM, abtv wrote:
>> I would like to deny seen pages for unregistered users. I can do it via the
>> following:
>>
>> Choose `Administration` -> `Users & Groups` -> `Rights` then select
>> `Prevent unregistered users from viewing pages, regardless of the page or
>> space rights` and
>> `Prevent unregistered users from editing pages, regardless of the page or
>> space rights`.
>>
>> But I would like to automate it while deploying xwiki. It means no user
>> interactions with UI. Is there any way to do it? Maybe, config file or via
>> java extension?
>>
>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
1. I'm implementing custom xwiki plugin installations without user
interaction in java (I planned to do it with REST API, but after testing I
have found it's not so convenient as java code). I use the following:
ExtensionManagerScriptService manager =
(ExtensionManagerScriptService)Utils.getComponent(ScriptService.class,
"extension");
InstalledExtensionScriptService installed =
(InstalledExtensionScriptService)Utils.getComponent(ScriptService.class,
"extension.installed");
The problem is that I do it in my custom auth module when user logins into
system. I do this check only once but it smells for 2 reasons:
Utils.getComponent method is deprecated and I think there is an entry point
which I can override to run my code on xwiki start. Could you propose any
solution for this? I have also concern about xwiki start: I use Jetty and
every time I start xwiki I see a message "xwiki is loading..." and percent
counter. It seems that xwiki loads only for the first request. Is it true?
Can I change the behaviour?
--
View this message in context: http://xwiki.475771.n2.nabble.com/How-to-run-custom-code-on-xwiki-start-in-…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hello to interested GSoC students,
I would like to remind you to submit your applications early and not wait
for the deadline. Submitting early allows you to receive feedback on your
proposals and gives you time to improve them before the deadline arrives.
It would be a good idea to use this review process at your advantage!
Also, in case you`ve missed it, 3 new project proposals were added last
week that you might also be interested in:
* RedPen Integration
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/RedPenIntegration
* Presentation Application Overhaul
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/PresentationApplicat…
* Chart.js Integration
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ChartjsIntegration
We now have a total of 16 projects to choose from and 8 available mentors.
Good luck in drafting your proposals, don`t remember about the Pull Request
and don`t hesitate to ask questions!
Thanks,
Eduard
I would like to deny seen pages for unregistered users. I can do it via the
following:
Choose `Administration` -> `Users & Groups` -> `Rights` then select
`Prevent unregistered users from viewing pages, regardless of the page or
space rights` and
`Prevent unregistered users from editing pages, regardless of the page or
space rights`.
But I would like to automate it while deploying xwiki. It means no user
interactions with UI. Is there any way to do it? Maybe, config file or via
java extension?
--
View this message in context: http://xwiki.475771.n2.nabble.com/How-to-setup-Prevent-unregistered-users-f…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
I’m merging the move from CLIRR to revapi in master (for http://jira.xwiki.org/browse/XCOMMONS-891) and this means that master will require java8 to build.
Thanks
-Vincent