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
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
VOTE 1: Disable the Watchlist by default and enable all Notifications
features on XWiki 10.1 RC 1
+1
VOTE 2: Disable the Watchlist by default and enable all Notifications
features on XWiki 9.12.3 so the LTS has good options enabled by default
+1
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi,
I would like to request the "macro-kanban" repository to publish a macro
which allows to make kanban views of AppWithinMinutes data. It also allows
to drag and drop items to change the value of a field.
Thanks
Ludovic
--
*Ludovic Dubost*
*Founder and CEO*
ludovic(a)xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
<http://www.xwiki.com/en/products/try-xwiki-cloud> - Try Cryptpad: Secure
realtime Wysiwyg Editing <https://cryptpad.fr>
Hi devs,
Here’s a proposed roadmap discussed with XWiki SAS devs (Thomas, Guillaume, Caty) who are available to work on 10.1.
Scope
=====
* Finish moving to FS-based attachments by default (it was planned for 10.0 already) - Assignee: Thomas
* Finish polishing/tuning/fixing Notifications and remove watchlist - Assigne: Guillaume
** Idea: enable mails by default when notifs are enabled.
* Prevent accidental move/renames - http://jira.xwiki.org/browse/XWIKI-14591 - Assignee: Thomas
* Start discussions to agree about usability proposals listed at http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/Tasks5/Prioritiza… so that the first ones can be done during 10.2 and 10.3 - Assignee: Caty
* Skin refresh investigation (including Bootstrap 4) - Assignee: Caty
Dates:
=====
* 10.1RC1: 19 Jan 2018
* 10.1Final: 26 Jan 2018
Let me know if you have any remarks/issues or if you wish to contribute something extra to this roadmap.
Thanks
-Vincent