xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] [xwiki-users] [ANN] Tour Application v1.0 Released

by Alexandru Cotiuga

Hello Gerritjan, The CSS selectors should be used just like in a CSS file and they are not limited to IDs. In order to grab your <div id="amcResearch"> you should use #amcResearch. The dot (.) have to be used for classes and also nested selectors are accepted (e.g: div>#amcResearch). Hope you enjoy the new application! On Thu, May 12, 2016 at 1:44 PM, Gerritjan Koekkoek <gerritjan(a)cdlsworld.org > wrote: > Nice, > > Tried it immediately? > But what CSS selectors can be used, I assumed the ID's > Tried: > HAMCvragenlijstenvoorbezoekexpertisepoli > (Header in the page) > and > amcResearch > wich is a ID for a Block enclosed as a <DIV>? > > But the boxes appear in the middle of the screen and do not show a Arrow > pointing to the ID? > > XWiki 6.4.x > > > ________________________________________ > From: users <users-bounces(a)xwiki.org> on behalf of Vincent Massol < > vincent(a)massol.net> > Sent: 12 May 2016 11:20:12 > To: XWiki Users > Cc: XWiki Developers > Subject: Re: [xwiki-users] [ANN] Tour Application v1.0 Released > > Nice, thanks Alex! > > -Vincent > > > On 12 May 2016, at 12:04, Alexandru Cotiuga <alexandru.cotiuga(a)xwiki.com> > wrote: > > > > HI all, > > > > A new version of the Tour Application extension is available. See > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Tour+Application#Hv1.0 > . > > You can install or upgrade with the Extension Manager. > > > > Thanks, > > Alex > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

9 years, 1 month

[xwiki-devs] [xwiki-users][ANN] Tour Application v1.0 Released

by Alexandru Cotiuga

HI all, A new version of the Tour Application extension is available. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Tour+Application#Hv1.0. You can install or upgrade with the Extension Manager. Thanks, Alex

9 years, 1 month

[xwiki-devs] [Brainstorming] Move non-core modules of xwiki-rendering in xwiki-contrib

by Vincent Massol

Hi devs, Following our strategy of moving non-core extensions of platform in xwiki-contrib I’d like to discuss moving non-core modules of xwiki-rendering into xwiki-contrib. My real need ATM is to know where I should commit the Markdown renderer I’ve been working on as a proof of concept. It’s working but not everything is supported yet and I don’t plan nor want to commit to make it work in the near future. I also don’t want to put the burden of maintaining it on the xwiki core dev team. And I also feel it should be located in the same module where the Markdown parser is located. So one solution is to move the Markdown syntax module into xwiki-contrib, as a whole. Now, if we do this for the markdown module we might as well agree to do it for other non-core modules, namely: - some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook, doxia, jspwiki, tex (+ markdown of course) - some macro transformations: linkchecker, wikiword - some macros like: the ctsreport one and the jira macro WDYT? Thanks -Vincent

9 years, 1 month

[xwiki-devs] [VOTE] Governance changes for xwiki.org

by Vincent Massol

Dear XWiki Developers, In order to better ensure the long term success of the xwiki open source project, we need to work on making xwiki.org a place where sponsoring companies (the main one being XWiki SAS) can thrive and get some revenues from their contributions to the project (thus allowing them to invest and even increase their investment in open source). Actually we've already started this a while ago by defining our governance process at http://dev.xwiki.org/xwiki/bin/view/Community/Governance. This mail is about going further in this direction and providing more leverage for sponsoring companies. Without further ado, here's a list of actions I'm proposing: A) On the download page, introduce a form (that can be skipped) to let user enter their details (name, email) to accept to receive offers, discuss business projects, and provide onboarding help/tips from companies creating XWiki. Since XWiki SAS is currently hosting and maintaining xwiki.org, I'm proposing that the user details will be sent by mail to some XWiki SAS email address (i.e. XWiki SAS will be operating user data gathering on behalf of xwiki.org, which has no legal entity). On the other side, XWiki SAS will provide those information to other companies offering a good level of code contribution to the development of XWiki: I'm proposing the threshold of 3 active committers to be able to receive those contact details. B) Similarly, inside the XWiki product, on the Admin user creation screen in the Distribution Wizard or elsewhere (place to be defined), have some checkbox to accept to receive news/onboarding tips/offers from companies creating XWiki. It'll work the same and send an email to some XWiki SAS-operated email address. And again XWiki SAS will redistribute the information to companies having more than 3 active committers on the project. C) Add a Support/Offer Panel inside the default XWiki flavor where companies creating XWiki can advertising their services/offers. In addition, find a place, maybe in some Admin UI menu for providing the same information + a configuration option to remove this panel from the UI. D) Allow companies creating XWiki to publish blog entries to present new offers/services/extensions. We don't want this to turn into spam so the rule could be no more than 1 such blog entry/mail per month to start with and those entries need to be presented in a nice community-oriented way. E) Similarly, allow top sponsoring companies (XWiki SAS at the moment) to create a monthly newsletter sent to the users list, gathering news about the xwiki ecosystem in general (product news, events, new offers/services/paying extensions, tips, etc). There could also be surveys. XWiki SAS is happy to start this effort and to gather such news from other sponsoring companies to include them in the newsletter. The idea is to let the community be more aware of all news that exists be them free or for pay, and in addition also advertise conferences at which xwiki is represented, etc. F) Find a good place in the XWiki runtime (maybe rework the Admin UI home page to remove the current icons which don't bring any useful information) to display the xwiki.org blog. The idea is to provide news from inside XWiki but not make it intrusive to users (hence the idea of locating it somewhere in the Admin UI). Of course we need handle the fallback when the instance is not connected to the internet or behind a proxy. G) Since XWiki SAS is paying for hosting and maintaining xwiki.org, the idea is to mention this on xwiki.org, possibly in a panel or in the footer (as we do our other sponsors) H) Put some company logos of companies using xwiki on the home page or somewhere visible to advertise more the xwiki software: "hey, look, those companies are using XWiki”. I) Increase the visibility for the top sponsoring company. Today we have an issue is that the company that sponsors the big majority of the source code is not much more visible than companies which sponsor less than 1% of the code. Right now we're saying on [[http://dev.xwiki.org/xwiki/bin/view/Community/Governance]]: "The commercial offerings are listed in the order of their contribution levels, the biggest contributor getting the top spot. In order to keep it simple the contribution level corresponds to the number of active Committers.". I'd like to keep the spirit but I believe we need to change the implementation. Right now all companies are put one under another. This has the effect of making it more confusing for users to choose and doesn't reflect the level of contributions of companies. So the new rule I'd like to have is that on all pages where we list companies, we make the top contributing company displayed very visibly and have a link for other companies, leading to another page where they advertise for their services and offers. J) Allow sponsoring companies to have paying extensions on extensions.xwiki.org, under any license (open source or not). Here’s my +1 Thanks -Vincent Massol Hat 1: CTO XWiki SAS Hat 2: XWiki Core Committer

9 years, 1 month

[xwiki-devs] Question about rights precedence

by Clemens Klein-Robbenhaar

Hi devs, while trying to figure out how to fix http://jira.xwiki.org/browse/XWIKI-13269 " Multiple values for one permission pair handled wrong " I ran into a question about now to resolve conflicting rights/permissions. I guess that resolving rights conflicts assigned to the same object/level (i.e. page or wiki) but different principal (i.e. user and a group of that user) is not much different than resolving a conflict with rights for the same principal (as happened in the bug report, getting two rights for the anonymous user after an upgrade conflict) If I understand the documentation here: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Permission+types/ then usually "deny" takes precedence over "allow", except for the "Special Permissions": "admin", "programming", "register", "crate wiki" and "script". However when I look at the implementation in org.xwiki.security.authorization.Rights I can see the rights have a "tieResolutionPolicy", which is "ALLOW" for "register", "admin" and "programing", but not for "create wiki" and "script". Is the "tieResolutionPolicy" something different than the priority order? If not, who is right, the implementation or the documentation? (However, no matter how the answer is, the UI needs to be updated, as it always assumes that deny takes precedence, giving the wrong answer at times) Thanks, Clemens

9 years, 1 month

[xwiki-devs] [ANN] XWiki 8.1 Release Candidate 1 released released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 8.1 Release Candidate 1. This release candidate brings a couple of improvements and bugfixes to Extension Manager and other bundled components. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki81RC1 The following people have contributed code to this release (sorted alphabetically): Alexandru Cotiuga Clemens Robbenhaar Denis Gervalle Ecaterina Moraru (Valica) Guillaume Delhumeau Thomas Mortagne Thanks for your support -The XWiki dev team

9 years, 1 month

[xwiki-devs] [Brainstorming] Improving easiness of creating wiki links

by vincent＠massol.net

Hi devs, A user has reported the following, mentioning it was taking a lot of steps, and we’ve all experimented that creating wiki links could be easier: “ 1. Go to page you want to link to (Target Page). a. Copy URL 2. Go to page where you want to add the link (Source Page) 3. Edit it using Wiki Syntax Editor 4. Create the link i. Write [[ ii. write label iii. write >> iv. paste the link pointing to Target Page v. Remove https://w.amazon.com/bin/view from pasted link vi. Replace manually all encoded URL strings (like + and other symbols) vii. Replace “/” with “.” viii. Add WebHome ix. write ]] 5. Save 6. Done. " So I’d like to brainstorm about what we could do to make it easier to creating wiki links. Some ideas: A) Remove step 4. ix with http://jira.xwiki.org/browse/XWIKI-12920 B) The label>> parts (steps ii and iii) can be omitted, especially when the link label generation is configured to use titles C) The real solution for me is autocomplete on links: http://jira.xwiki.org/browse/XWIKI-206 This should probably be implemented in the autocomplete extension: see http://extensions.xwiki.org/xwiki/bin/view/Extension/AutoCompletion+API and http://extensions.xwiki.org/xwiki/bin/view/Extension/AutoCompletion+Applica… D) Using CTRL+G helps since it provides the reference and helps in finding the page to link to. It can be considered as a simplified autocomplete, ie a simplified impl for C). E) Marius mentioned elsewhere: "I would also like to have a common Insert Link dialog between the CKEditor and the Wiki Editor. You click on a button on the tool bar, you get a dialog where you can search for the target page (or select it from the tree) and then click Insert, which will generate the wiki syntax for your. The Insert Link dialog can have a shortcut key for quick access. Of course autocomplete is nicer but it's more work, while the Insert Link dialog is a must for the CKEditor anyway.” F) Marius mentioned elsewhere: "We can also implement a dedicated "Insert Reference" dialog for the Wiki Editor that offers a text input where you can paste an URL and the dialog attempts to extract the entity reference from the URL and inserts it in the Wiki Editor text area to be used for links but also for macros or anywhere where you might need a document reference. This can be implemented as an XWiki extension.” G) Add the ability to paste a full URL in the reference part of wiki links and upon save the Rendering will automatically transform it into a document reference if it’s a local link. And if you want a real url for a local link then you’d need to use the “url:” prefix. Implementation: One relatively simple solution is to parse the URL (using a ResourceTypeResolver/ResourceReferenceResolver) and then serialize it and verify if the result matches the passed URL. If it does it means it’s a local URL. H) Caty mentioned elsewhere: "We could display the reference of a page in: a. a Permalink dialog (containing the URL + reference) that the user can copy paste in browser input or editor b. Information tab c. other?” IMO the best (possibly not the easiest) are C) and G). With those 2 we would get: * easy pasting of existing URLs * easily finding the page you want to link to when you don’t have its URL Now, even if we agree to do C) and G) in the future I still think that all the other ideas (ie. E, F and H) could also be implemented. WDYT? Thanks -Vincent

9 years, 1 month

[xwiki-devs] Design and questions about Android-authenticator

by fitz

Hi our dear community, I have tried to implement most of the functions for android-authenticator in these days(https://github.com/xwiki-contrib/android-authenticator/tree/feature-au…. But there are still a lot of detailed issues that need to be handled, like security, volume, bad network state, cache and so on. I will try to deal with these problems as soon as possible. Here, this time, first I would like to discuss whether my implementation is feasible enough, and second there are some other problems which need my mentor and our community to help me. Thanks first of all. 1. *First introduce my design* and implementation of the synchronization and authenticator. 1.1 *Synchronization:* 1.1.1Server->Client There are two choices, including synchronizing all users or synchronizing the users of selected groups. We use the same method for these two cases. 1) Add Update Each time while calling the method SyncAdapter.onPerformSync, we get data from server that has been modified since the last modified time. The data that we get must be updated or added to the local contact2 database. Also only these data need to be updated or added. 2) Delete What data should be deleted from the local database? Because the server does not return data that needs to be deleted, or maybe I don not know how to query the deleted objects? :). Therefore now I just get all the user IDs(HashMap<id,Ojbect>), traverse every user of the local database, find the data that are not in the IDs map, and then delete it. 1.1.2 Detail: For synchronizing all users: 1) Get all users as List<SearchResult> searchResults 2) Add Update: SearchResults include the last modified time. So according to the time, we can filter what data should be updated or added. Then call the function ContactManager.UpdateContacts to update local db. 3) Delete: searchResults already have user ids, so we can get the IDs(HashMap<id,Ojbect>), then traverse the local database to find what data should be deleted. For synchronizing users of selected groups: 1) Get all selected group ids from local sharepreference xml, as List<String> groupIds 2) Get the users’simple information(ObjectSummary) of each group one by one. The ObjectSummary only has the user’id without the last modified time. 3) Add Update: According to the user ids, we get the last modified time for each user, if before the given last sync time, continue; if after, we update the user (but we need first get the detailed information of the user). 4) Delete: at second step, we get ObjectSummarys which include all the user ids. So with these ids, we can find the data that should be deleted. 1.1.3 Client->Server For this part, As we will first request and update the data in server while editing the contact, Therefore, unnecessary synchronization mechanism is not required. If the server’s response is that the editor has no permission, we just return; if has been updated in the server, we will update the local database at the same time. 1.2 *Authenticator:* 1.2.1 How to grant the permission for third party apps when they calling getAuthToken? (Here, AuthToken is equal to Cookie.JessionId). Basically, only 3 useful interfaces, like AddNewAccount, getAuthToken, invalideAuthToken, are available for other third party android apps. The most widely used is getAuthToken. How should we grant permission for third-party apps? And when we grant? If adding XWiki account from one app, then we can trust this app and grant the getAuthToken permission. But if not, we should check the permission for every getAuthToken request of third-party apps. So the checking logic code should be in the function getAuthToken. But XWikiAuthenticator.getAuthToken will never be called if AcountManager has cached the authtoken corresponding to AuthTokenType. Therefore for first granting permission to third-party apps, the app should not pass the same authTokenType when calling getAuthToken function. Or the authToken value will be directly returned by AcountManager according to the same AuthTokenType and the method getAuthToken will never be called. So different apps should use the different AuthTokenType param to call the function getAuthToken so that the <AuthTokenType, AuthToken> will not be cached before granting permission for this app. AuthTokenType=FULL_ACCESS+PackageName. So in XWikiAuthenticator.getAuthToken function, if we check that the third-party app has not been granted, we startActivity(GrantPermissionAcvivity) to grant permission for this package by checking the user’s input password. And in addition the packageName can't be forged because we can use the bundle option.getCallUID from binder to verify the pakageName. 1.2.2 How to maintain authToken consistency for different third-party apps with different AuthTokenType? When will appear inconsistent? There are mainly two key cases, the authToken is expired or the third-party app calls the invalideAuthToken function. Now, I use the following solution to these problems. 1) When the authToken is expired, xwiki authenticator app will login again and refresh all the cached authToken for every AuthTokenType. 2) When the third-party app calls the invalidAuthToken function, then corresponding cache will be clear and getAuthToken will be called, then XWikiHttp.login will be called to get a new token and refresh all the cached authToken for every AuthTokenType. 3) So if any one finds the authToken has been expired, then login and refresh all the cached authToken to maintain consistency. In addition, I suggest that if the third-party app find the authToken is expired after a period of time, then first call getAuthToken again. If the token is different, then maybe authenticator has already update the token. If the token is the same, just call invalidAuthToken and getAuthToken again. 2. *There are also some questions* that need help. 1) Is the above methods ok? How should I test effectively.? Or Maybe these implementations exist more problems that I have overlooked? 2) Gradle or maven in Jenkins CI? Now gradle is the default, great and perfect tool for building android app. http://gradle.org/maven_vs_gradle/. And It's convenient for us to develop android apps in android studio. Also it's very easy to integrate with jenkins and maven repository, And I have already tried it and successfully build my android apps in jenkins with gradle.(https://github.com/xwiki-contrib/android-authenticator/blob/feature…. However If we use maven to build apps, it's not conducive to our post-maintenance and integrated development for android developers. So could I use gradle instead of maven to build our android apps? and can I use it in the jenkins? or I have to use maven? 3) Should I create issues in JIRA? Should I include the JIRA issue when I commit something ? 4) HttpClient or HttpUrlConnection? Or OkHttp/Volley library? HttpClient(org.apache.http.client) has been deprecated and HttpUrlConnection is a recommended way. So now I use this UrlConnection and write a simple request library to communicate with server. Maybe I can use okhttp/volley in the future as the way of http request to efficiently process data, but it may increase the size of the application. But maybe it has more features like cache, spy, connection pool and so on. The cache should be very useful if large volume of users’ data have to be synchronized, Especially when network is not very good and we request server again and again. Should I use the okhttp library instead of my custom implementation of http library? Or other serializable library like gson/xstream instead of the XmlPullParser? 5) Other ideas and contributions? Maybe after completing this authenticator app, I could rewrite the android-client app with android studio and update the application interfaces and something out of date. Maybe I can do some translation in Chinese ? Maybe I can update some document? Or maybe I can solve some useful bugs in JIRA for XWiki platform or extension? You know, now I'm not very familiar with such a huge code and even do not know how to start after looking at some of the code. I still need some time to explore. I think now maybe I should first well finish the android-authenticator. :) And then be familiar with the entire code architecture as soon as possible, and try to find and solve a small problem. What do you think? Could anyone give me some tips? Thanks, Fitz Lee -- View this message in context: http://xwiki.475771.n2.nabble.com/Design-and-questions-about-Android-authen… Sent from the XWiki- Dev mailing list archive at Nabble.com.

9 years, 1 month

[xwiki-devs] [XWiki Day] BFD#102

by Alexandru Cotiuga

Hi devs, This Thursday we celebrate BFD#102: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 134 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#102 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13610 Happy Bug Fixing Day! Thanks, Alex

9 years, 1 month

[xwiki-devs] [Proposal] Add mechanism to allow following only contrib related mails

by Anca Luca

Hello all, Since http://xwiki.markmail.org/thread/jrug6cbbqpia5bx4 (but not only) the rule says that we should discuss contrib related stuff with the community. In my case, I cannot manage to follow all the mails on the devs(a)xwiki.org (because they are a lot) but I would be particularly interested of not missing the ones about contrib extensions. However, today, I don't know how to differentiate them, I would need to read all devs(a)xwiki.org to not miss one. There are multiple solutions that I can propose for this, please let me know what you think: 1/ have a contrib mailing list 2/ have an alias for the contrib that would send on the same list, this way we could filter by the "to" field 3/ have a convention about mails related to contrib (e.g. [Contrib] in the subject) that would allow to filter 4/ any other technical solution that I didn't think about that would allow to automatically decide if a mail is about contrib or not, without reading it :D 1, 2 and even 4 are perfectly fine with me, 3 is a bit risky because people might not follow conventions. What do you think? Anca

9 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs