- xwiki-devs@xwiki.org - lists.xwiki.org

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 10.1. Starting with this release the Watchlist Application has been disabled and fully replaced by the Notifications Application. We continue to add new improvements to Notifications (filters, preferences, etc.) so make sure to check them out. 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/Data/XWiki/10.1 Thanks for your support -The XWiki dev team

7 years, 6 months

1
0
0 0

[xwiki-devs] Weird issue in security cache

by ktc

Hi XWiki devs, We ran into a weird issue on XWiki security cache. Our entire security cache is purged every 4 hours. Some background about our setup: We retrieve users’ group membership from LDAP We set a 4 hour expiration time on the cache(as below) because LDAP records may update at any time. <local-cache name="platform.security.authorization.cache"> <eviction max-entries="50000" strategy="LRU"/> <-- 4 hours --> <expiration lifespan="14400000"/> </local-cache> To our understanding, each cache entry should have its own timer which expires after 4 hours. But what we observe from JMX dashboard is that the entire security cache is being purged every 4 hours. Security cache JMX diagram: <http://xwiki.475771.n2.nabble.com/file/t396587/Security_Cache.png> Our user group has similar issue but purge irregularly: <http://xwiki.475771.n2.nabble.com/file/t396587/Group_Cache.png> This problem is cause big performance issue in our system. We can’t figure out the root case. Any pointer will be highly appreciated. -- Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

7 years, 6 months

1
0
0 0

[xwiki-devs] [PROPOSAL] Fork the Keypress JS library

by Clément Aubin

Hi devs, In October / November of last year, we integrated the Keypress JS library as a replacement of OpenJS Keyboard in order to better handle keyboard shortcuts in the platform and its extensions and add new shortcut types (such as "sequence" shortcuts) useful for [1]. Moving to this library has also brought some bugs, such as XWIKI-15024 [2]. Currently, that bug can be fixed upstream by the library maintainer, that unfortunately isn't very active on the project. Choosing a library that isn't properly maintained might have been a problem that we didn't really thought of when switching to Keypress JS. In order not to be stuck by waiting for upstream releases, I propose that we fork the library, and fix the problem raised by XWIKI-15024 ourselves by reviewing and integrating a patch proposed upstream, but not yet merged [3]. Of course this solution has pros and cons, the main downside being that we will need to maintain our fork. Also note that, if we fork the project, we will have to choose either to keep the source code in its original form (which is CoffeeScript [4]) or to translate the code into JavaScript, which is more maintainable for us, but that will probably not allow us to integrate other patches from the official project branch. WDYT ? Thanks, Clément [1] http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Keyboa… [2] https://jira.xwiki.org/browse/XWIKI-15024 [3] https://github.com/dmauro/Keypress/pull/137 [4] http://coffeescript.org/

7 years, 6 months

3
3
0 0

[xwiki-devs] [Contrib] Request for a repository for a tool to export documents to spreadsheet

by Anca Luca

Hello all, I would need a repository on xwiki-contrib to publish an extension to allow exporting a bunch of documents to a spreadsheet format: one line per document, with configurable columns read from the objects of those documents. Currently it exports only CSV but we could add other spreadsheet formats (notably xls), so it should have a more generic name than csv. Not sure if it would contain other formats that are not spreadsheet-like, so I think spreadsheet is enough. Thanks, Anca

7 years, 6 months

2
4
0 0

[xwiki-devs] [Proposal] Roadmap for XS 10.2 & 10.3

by Vincent Massol

Hi everyone, Here’s a proposal already discussed with Thomas, Caty, Guillaume and Marius. 10.2 (March): * Finish moving to FS-based attachments by default (it was planned for 10.0 already) - Assignee: Thomas ** Note that the work is done but we’d make it the default in 10.2, giving us more time to do additional tests * Prevent accidental move/renames - http://jira.xwiki.org/browse/XWIKI-14591 - Assignee: Thomas * Start designing the work for "Discourage or disallow users to edit an extension's page “ - http://jira.xwiki.org/browse/XWIKI-14377 (see also http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensionDiscourageCodeEdit) - Assignee: Thomas * Finish work on Notifications - Assignee: Guillaume ** Known bug fixes ** Add the ability to select default notifications on the administration - https://jira.xwiki.org/browse/XWIKI-14106 ** Enable page ('XWiki') notifications by default - https://jira.xwiki.org/browse/XWIKI-14129 ** Enhance the notifications application so it can replace Activity Stream - https://jira.xwiki.org/browse/XWIKI-15016 ** (Nice to have) Live emails notifications should be grouped by XWiki pages - https://jira.xwiki.org/browse/XWIKI-14844 ** (Nice to have) Add an entry in the Alert menu to explain what it's for - https://jira.xwiki.org/browse/XWIKI-14978 * Continue preparation/discusssions about usability proposals listed at http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/Tasks5/Prioritiza… - Assignee: Caty 10.3 (April): * Fully replace the AS with Notifications (leftover from 10.2) - Assignee: Guillaume * Introduce notion of blacklist for the Navigation panel and provide an Admin UI for it. Goal: remove the XWiki space by default using this blacklist (users can be seen in the User Index). Assignee: Marius * Slot reserved for one usability improvement from those explored by Caty. Assignee: Marius * Slot reserved for one usability improvement from those explored by Caty. Assignee: Guillaume * Finish "Discourage or disallow users to edit an extension's page “ - http://jira.xwiki.org/browse/XWIKI-14377 (see also http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensionDiscourageCodeEdit) - Assignee: Thomas * Start work on performance. Goal: be as good as XWiki 8.4.x - Assignee: Thomas Let me know if you have any comment or disagreements or if you’re interested in contributing something yourself to these roadmaps! Thanks -Vincent

7 years, 6 months

1
1
0 0

[xwiki-devs] Questions related to underlying logics for XWiki security and group cache

by ktc

Hi devs, We run into a complicated issue related to XWiki cache and permissions. In order to fix the issue, we would like to know some underlying logics for XWiki security and group cache: 1. Why XWiki cache purge happens every 4 hours? 2. From our dashboards, we notice that every 4 hours, the security authorization cache purge will wipe out most entries(from 50K to 5K). Why this happens rather than selectively expiring 4-hour-old entries over time gradually? 3. From our dashboards, we notice the user group cache dumps on an irregular cadence. The number of entries will drop to nearly 0 on 12:00 and bounce back at around 16:00 nearly every weekday. Do you know some reasons behind that? 4. What's the underlying logic of XWiki purges SecurityCache entries? We assume it will happen in one or both of the following cases: 1. when a given page's permissions are changed 2. when a given user is removed from a (XWiki-internal) group Is that correct? 5. We have a custom code called LDAP service. When our wiki user calls that service, we wish to keep the cache for only a few minutes and then invalidate the cache. So if our user calls again after a few minutes, it will try to get reply from the service instead of the cache. For our case, what method do you suggest to use when we invalidate SecurityCache entries? Is there any side effect if we do that? Thanks a lot for your help! -- Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

7 years, 6 months

1
1
0 0

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

by Alex Cotiugă

Hello devs, This Thursday is BFD#167: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -92 bugs over 365 days (1 year) * -74 bugs over 500 days (between 1 and 2 years) * -295 bugs over 1600 days (4.3 years) * -691 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#167 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13952 Happy Bug Fixing Day, Alex

7 years, 6 months

1
0
0 0

[xwiki-devs] [Usability] Create a dedicated Logo section in Administration

by Ecaterina Moraru (Valica)

Hi, As some of you know, in January we had another session of usability tests performed. As a result of those tests, I have prioritized [1] some issues that we might want to improve in our next 10.x+ Roadmaps. One of the entries from that list is: "Create a dedicated Logo section in Administration". Although we made some improvements in this area, users still struggle to find the Logo changing area (takes more than 3 minutes). Plus there is a lot of confusion between the Skin and ColorThemes overriding. This is a proposal to explicitly have a Logo section inside the Themes section of Administration http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaChangeLogo#HSolution1-1 Let me know what you think, Caty [1] http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/Tasks5/Prioritiza…

7 years, 6 months

7
27
0 0

[xwiki-devs] [Proposal] Admin targeted applications should be available in the Administration

by Ecaterina Moraru (Valica)

Hi devs, The purpose of this mail is to decide on some rules for where admin related applications should be located. This mail resulted after a discussion with Vincent and it was initially started by the proposal to move Menu application inside Administration [1]. Some mentions: - Admins should have a central place where they could find all the applications they can use and are intended for them. Having a central location helps discoverability. Administration would be that place. - Applications have configurations and actions. All configurations should be in Administration. If the actions are targeted only to Administrators, they should be listed also in Administration. We will use TABS, one for configuration, one for the actions UI (ex Invitation app). If the actions are targeted also to Users, than this application should be publicly available (ex User Directory). - These mixed target applications, might have admin dedicated actions displayed in place (ex. livetable edit, delete entry. ex. Repository app import). This is fine since it preserves the context, not all admin actions should be present exclusively in Administration. - Application Index should contain only applications that are targeted towards normal users. Admins will have Administration as entry point. - If the application needs to add special permissions to a group of users, these can be added with rights, or provide manual links towards the application in a custom menu/panel (ex Stats app providing access to a particular user). This means several changes for the following applications: Bundled apps listed in AppIndex: 1. Invitation App - Move the actions (Invitation.WebHome) to Administration. Use ConfigurableClass and create a new Tab containing the actions. Remove the AppBar entry (UIExtensionClass). 2. Panels - move to Administration, remove the AppBar entry. 3. Menus - move to Administration, remove the AppBar entry. 4. Scheduler - move to Administration, remove the AppBar entry. 5. Tour - move to Administration since it contains tour definitions. 6. User Index - leave it public, but remove the AppBar entry since there is a dedicated Drawer entry. Recommended apps: 7. Antispam tool app - move to Administration, remove the AppBar entry. 8. Nested pages Migrator - move to Administration, remove the AppBar entry. 9. Filter Streams Converter Application - move to Administration, remove the AppBar entry. 10. Flash Messages Application - move to Administration, remove the AppBar entry. Note: - In case we might have a lot of applications listed in Administration, we might need in the future to reorder them and prioritize some. We might need to introduce the concept of Simple / Advanced administration, where in Simple we could have just the applications that are mandatory for the initial configuration flow. This should be discussed later. Let me know what you think, Caty [1] http://xwiki.markmail.org/thread/romxz7iylujslg36

7 years, 6 months

4
8
0 0

[xwiki-devs] [Brainstorming] Menus vs Panels

by Vincent Massol

Hi devs, I’m following up from the http://markmail.org/message/zegx62ogtq5evbsy thread and creating a new one since this is a side topic. The idea is that right now when the user needs to create side content (ie Panels), it’s confusing since they can use either the Panels app or Menu app. I have the following proposal: Separate the apps * Keep the 2 concepts of Panels and Menus and make them separate: Use the Menu app for creating menus and the Panel app for creating panels * Remove the ability to create panels from the Menu app * Improve the Panel app to make it simpler to create panels ** Introduce a new xproperty for the panel title (and supporting scripting, could be a text area). ** If the panel xproperty content is empty then don’t display the title. This is to no loose the ability to have panels displayed only if some conditions are met. ** Display panel content textarea in WYSIWYG to make it simple for new admins to create panels. * Note that this solves issue https://jira.xwiki.org/browse/XWIKI-10112 since we already have a Panel Wizard! * If we want, we can also easily introduce the concept of visibility for panels. WDYT? Do you see any use case that wouldn’t be covered? Thanks -Vincent

7 years, 6 months

4
5
0 0

[xwiki-devs] [Usability] Menus inside Administration

by Ecaterina Moraru (Valica)

Hi, This mail is also part of the Usability priorititzation list [1] Admins expect to manage custom navigation from the Administration. This proposal integrates the Menu application in Administration, see http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaMenuInAdministration#HP… Let me know what you think, Caty [1] http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/Tasks5/Prioritiza…

7 years, 6 months

4
6
0 0

[xwiki-devs] [ANN] XWiki 10.1-RC-1 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 10.1-RC-1. Starting with this release the Watchlist Application has been disabled and fully replaced by the Notifications Application. We continue to add new improvements to Notifications (filters, preferences, etc.) so make sure to check them out. 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/Data/XWiki/10.1RC1/ Thanks for your support -The XWiki dev team

7 years, 6 months

1
0
0 0

[xwiki-devs] Queries regarding the project

by sidhanshu binani

Hi there, I am new to this platform and it would be very kind of you if you provide me with some insights into this project(TOUR-63) as to how should I proceed to fix this error. https://jira.xwiki.org/browse/TOUR-63 This is the link to the particular issue I am talking about which is about the tour application(TOUR-63) which states about the issue “Tour button ends up under the footer on big screens”. Will be very kind of you if you can assist me with details as to how to proceed with this project. Regards, Sidhanshu Binani.

7 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] XWiki Feedback Survey 2018

by Clément Aubin

Hi devs ! Three years ago, we launched a feedback survey on xwiki.org [1] and on this mailing list [2]. We had the opportunity to gather a lot of good improvement ideas [3], and it seems that today, we managed to fix and improve quite a lot of items mentioned in this survey (missing features, usability issues, …). In this context, it would be nice to organize another survey for this year in order to assess how the user feedback on XWiki has evolved over the past years. In order to do so, we could use this feedback form [4] made by Andreea Chirica and Silvia Macovei, from XWiki SAS. I propose that we advertise this survey on three different channels : * Send an email to the users that have filled the xwiki.org download form * Create a blog post on xwiki.org (here is a draft : [5]) and tweet about it * Create a pinned thread on forum.xwiki.org about the survey The idea is then, as for the 2015 survey, to let it run for about two months and then provide detailed results on the xwiki.org website through another blog post. WDYT ? Thanks, Clément [1] http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiProduct2015 [2] http://xwiki.markmail.org/thread/6y6b3sfws4hrncpi [3] http://www.xwiki.org/xwiki/bin/view/Blog/ProductSatisfactionSurvey2015Resul… [4] https://docs.google.com/forms/d/10q06uZfeWWtsSwdYJrdFXUn0UE0O_z0CRTlpltb3pe… [5] http://www.xwiki.org/xwiki/bin/view/Blog/FeedbackSurvey2018

7 years, 6 months

2
2
0 0

[xwiki-devs] [Contrib] Request for repo for a LaTeX Renderer/Export + architecture/plans

by Vincent Massol

Hi devs, I’d like to work on a LaTeX Renderer + on an Export action for it. Thus I’m asking for a “latex” repo on contrib. What I’m planning to do: Step 1: * Remove the "tex/1.0” syntax from xwiki-rendering. I don’t think it’s necessary to move it to xwiki-attic since it’s always been more of a quick POC than something usable * Add a new “latex/1.0” syntax inside a new “latex” contrib repo: “latex/latex-syntax-10/“ Step 2: * Idea: Implement a FilterStream app export filter for “latex” Step 3: * Provide an export URL for LaTeX that would use the FilterStream filter. Not sure yet about the implementation. Several ideas: ** Introduce a component role for the Exports we have (PDF, HTML, XAR, etc) to make them pluggable so that it’s possible to add new “export” actions. Or more generally, time permitting, refactor the “export” action as a EntityResourceAction component plugged in EntityResourceReferenceHandler ** Don’t use the “export” action and instead introduce a new type with a ResourceReferenceHandler (see https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Architecture/UR…). ** Don’t provide an “export” URL Step 4: * Integrate the export in the UI, using the “Export” menu UI. Would need a UIXP/XClass to make that extensible if that doesn’t already exist. Needs: be able to select page order, toc, list of tables, list of figures, page numbering, etc * Other possibility (less nice): Don’t provide an “export” URL and instead tell users to use the generic FilterStream app when needing to export and if need be, in the future, provide a UI for it. However not sure how to ask the user for the list of pages to export, and the various questions (toc, list of tables, list of figures, page numbering, etc). Thanks -Vincent

7 years, 6 months

1
1
0 0

[xwiki-devs] [VOTE] Enable notifications about XWiki pages by default

by Guillaume Delhumeau

Hi devs. This vote is about enabling notifications about "page" events (create, update, delete, comment) by default, for both notification menu and emails. I think it is important since watchlist is replaced by notifications in the next version. If the user does not enable it, then even if there is a bridge between the watchlist preferences and the notifications, she won't receive emails anymore. Moreover, it makes this feature more discoverable (for sure!). Here is my +1. Thanks, PS: my plan was initially to have it for 10.1RC1 and 9.11.3. Regarding the time-frame, I'm not sure we can do it for 10.1RC1. So either we do it for 10.1 final or 10.2RC1. -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 6 months

3
4
0 0

[xwiki-devs] [Brainstorming] LaTeX Renderer - Styling

by Vincent Massol

Hi devs, I’m currently working on improving our TeX renderer (which is really a POC ATM), in an effort to see if it could be used to generate nice PDF exports (you generate LaTeX and then you convert to PDF). The main issue is that LaTeX doesn’t have any technology for applying style to it (like CSS has for HTML). In addition I wasn’t able to find any good HTML+CSS to TeX converter (as we have for PDFs with XSLT+FOP). So right now my idea is to implement some default behavior in the Tex Renderer (that could be configured globally in xwiki.properties and/or in the Admin UI) and give the ability to override specifically in the content. For example, imagine that you need to decide how to position table column content (left, centered, right) or whether the rows and/or columns of your table have vertical and horizontal lines (or other configs, autowrap, etc). The idea is that the Tex Renderer would support some custom tex-specific parameters. For example: (% tex-table-spec=“c | c | c" tex-table-floating="true" tex-table-caption="caption" %) |=A|=B (% tex-table-row-ending="\hline" %)|a|b (by default the table spec would be left aligned with vertical lines, and rows would be separated by horizontal lines). If you have some comments or ideas, please let me know. Inventing a CSS-like mechanism would just be too hard to implement IMO. Thanks -Vincent PS: If you want to see table options in LaTeX, see https://en.wikibooks.org/wiki/LaTeX/Tables

7 years, 6 months

3
8
0 0

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

by Alex Cotiugă

Hello devs, This Thursday is BFD#166: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -88 bugs over 365 days (1 year) * -69 bugs over 500 days (between 1 and 2 years) * -281 bugs over 1600 days (4.3 years) * -682 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#166 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13950 Happy Bug Fixing Day, Alex

7 years, 7 months

1
0
0 0

[xwiki-devs] [IDEA] Create an extension point for the Help application

by Ecaterina Moraru (Valica)

We would need an extension point inside the Help application content in order for the applications to insert their documentation, usage, actions, etc. There are several use cases that would need an extension point inside the Help application: - Templates section: some templates might want to promote themselves with previews; - Macros section: same; - Applications section: same; - Help Homepage -- Tours: there is a proposal that adds a Tour section that lists the available Tours, see http://design.xwiki.org/xwiki/bin/download/Proposal/MultiPageTours/helpHome… and http://design.xwiki.org/xwiki/bin/view/Proposal/MultiPageTours#HHelpTours -- Scripting Documentation Application http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting%20Documentat… could insert itself inside Help section, instead of AppBar. - Not sure if extension points also apply for Sandbox and XWiki Syntax, or if these should be just moved here. WDYT? Thanks, Caty

7 years, 7 months

3
2
0 0

Re: [xwiki-devs] [Brainstorming] Menus vs Panels

by Thomas Mortagne

+1 Le 12 févr. 2018 1:51 PM, "Vincent Massol" <vincent(a)massol.net> a écrit : Hi devs, I’m following up from the http://markmail.org/message/zegx62ogtq5evbsy thread and creating a new one since this is a side topic. The idea is that right now when the user needs to create side content (ie Panels), it’s confusing since they can use either the Panels app or Menu app. I have the following proposal: Separate the apps * Keep the 2 concepts of Panels and Menus and make them separate: Use the Menu app for creating menus and the Panel app for creating panels * Remove the ability to create panels from the Menu app * Improve the Panel app to make it simpler to create panels ** Introduce a new xproperty for the panel title (and supporting scripting, could be a text area). ** If the panel xproperty content is empty then don’t display the title. This is to no loose the ability to have panels displayed only if some conditions are met. ** Display panel content textarea in WYSIWYG to make it simple for new admins to create panels. * Note that this solves issue https://jira.xwiki.org/browse/XWIKI-10112 since we already have a Panel Wizard! * If we want, we can also easily introduce the concept of visibility for panels. WDYT? Do you see any use case that wouldn’t be covered? Thanks -Vincent

7 years, 7 months

1
0
0 0

[xwiki-devs] [GSoC] XWiki has been selected as a Google Summer of Code 2018 mentor organization!

by Eduard Moraru

Hi devs, As most of you already know, XWiki has been accepted to Google Summer of Code 2018! We currently have 12 project proposals and 8 mentors [1]. There is 1 month left [2] before the student application period begins, so if others want to sign up as mentors and/or propose new GSoC projects for the students, please do so on the ideas list [1]. During this period, students are supposed to ask questions about the proposed projects so please don`t hesitate to welcome and help them out! Another thing you can help with is to increase the list of "Trivial" issues that we know about on jira.xwiki.org. You can to set the "Difficulty" field of a jira issues to "Trivial" if you know for a fact that it would be something easy for someone new to XWiki to fix. We`re currently using a JIRA filter [3] to gather all these "Trivial" issues and listing them on the guidelines [4] page to help students discover them more easily. Thanks, Eduard ---------- [1] http://gsoc.xwiki.org [2] https://developers.google.com/open-source/gsoc/timeline [3] https://jira.xwiki.org/issues/?filter=10534 [4] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HIncreasi…

7 years, 7 months

2
2
0 0

[xwiki-devs] [IDEA] Remove Bundled applications from the Recommended definition

by Ecaterina Moraru (Valica)

There are several applications that are listed in the Recommended extensions, but meanwhile they were bundled in Platform. According to the Definition of a Recommended Extension [1] they should be not removed from the Recommended list. Examples of applications: - CKEditor - Help Application - Templates Application - Menu Application - Tour Application - Syntax Highlighting Application Maybe we kept them to promote them or because we forgot. Also there is no list on e.x.o with the bundled applications. Would that be useful? Still kind of hard to differentiate between user related applications and very technical bundled applications. Let me know what you think, Caty [1] http://extensions.xwiki.org/xwiki/bin/view/ExtensionCode/RecommendedExtensi…

7 years, 7 months

2
2
0 0

[xwiki-devs] [Proposal] Switch to USER for the default visiblity for translations + extend to all component-based pages

by Vincent Massol

Hi, Right now we have: xclass.addStaticListField(TranslationDocumentModel.TRANSLATIONCLASS_PROP_SCOPE, "Scope", "GLOBAL|WIKI|USER|ON_DEMAND”); However for wiki macros for example we have: xclass.addStaticListField(MACRO_VISIBILITY_PROPERTY, "Macro visibility", 1, false, "Current User|Current Wiki|Global", ListClass.DISPLAYTYPE_SELECT, PROPERTY_PIPE); The rationale is that it’s safe to use USER first to try out and then to extend to Wiki or Global if it’s working fine. So I’d suggest to change the default visibility for wiki translations to USER and more generally to do this for all component-based xobjects. WDYT? Thanks -Vincent

7 years, 7 months

2
6
0 0

[xwiki-devs] BaseObject ID collisions

by Marc Sladek

Dear XWiki devs We are using the XWiki platform for our applications but sadly are still stuck with 2.7.2. Lately we ran into issues on a large database and noticed "disappearing" BaseObjects. We were able to link it to XWIKI-6990 <http://jira.xwiki.org/browse/XWIKI-6990>, where hibernate IDs collided (hash collisions) and overwrote other objects without any trace - neither visible in the history nor in a log file. We analysed your implemented solution from 4.0+ in XWikiDocument <https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…> and BaseElement <https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…> and noticed that you changed the 32bit String#hashCode to 64bit MD5, which makes a collision less likely. I have a few questions regarding your solution: 1) Is there any specific reason why you have chosen MD5 over SHA-1 or 2? 2) Collisions are still possible and would be extremely hard to notice since they are completely silent. Have you considered to implement a collision detection to at least log occurring collisions - or even better reserve 1-2bits of the 64bit to be used as collision counter in the case of it happening? 3) To question the concept of generating a hash for an ID in general: Wouldn't a database defined "auto increment" be a much more robust solution for the hibernate IDs? A collision would be impossible and clustering/scalability is still possible with e.g. the InnoDB “interleaved” autoincrement lock mode. Why have you chosen a hash based solution in the first place? I'm sorry if these questions were already answered in the dev mailing list or on issues, please link me to them since I couldn't find any concrete answers. Thanks for your time and regards Marc Sladek synventis gmbh

7 years, 7 months

4
11
0 0

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

by Alex Cotiugă

Hello devs, This Thursday is BFD#165: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -95 bugs over 365 days (1 year) * -67 bugs over 500 days (between 1 and 2 years) * -281 bugs over 1600 days (4.3 years) * -685 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#165 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13949 Happy Bug Fixing Day, Alex

7 years, 7 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs