Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote.
We have waited way too long and I think we really need to find a
solution even if none of the committers use Windows since a long time.
Every time a Windows dev even think of contributing he is very quickly
discouraged...
As a reminder the issue is that working on XWiki source code is a pain
for MS Windows developers because of the (impossible to understand I
agree) limitation on path size.
So the idea is to find a new logical rule to drastically shorten our
paths and Sergiu proposed the following: remove duplicated information
from our paths to maven modules.
Here is an example:
xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro
(131 chars)
would become
core/rendering/transformations/macro (36 chars)
So WDYT ?
Here is my +1
I also find it nicer when navigating using cd and tab in a unix shell anyway.
Planning to do it in 5.1 if everyone agree.
--
Thomas Mortagne
Hi devs,
While building the new signed script solution with Thomas, we have the need
to create a new kind of entity references for macros. This will allow us to
keep reference to signed macros.
Those references will have entityReference as parent, since macros may be
contained in document, but also in object properties. Currently we do not
need a syntax for those references, since these will only exists as
objects. So, no string serializer is planned.
So, we need to agree on creating macroReference that will have at this
point a unique identifier (to be discussed later) and a parent that could
be either a documentReference or an objectPropertyReference.
Here is my +1,
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi devs,
I'd like to make it easy in XWiki to use javascript frameworks required by extensions.
I've found the webjars project (http://webjars.org) which packages javascript frameworks in JAR files available in Maven Central.
They work out of the box if you drop them in WEB-INF/lib in a Servlet 3.0 container (like Jetty 7). It works because the 3.0 spec says that any files located in META-INF/resources/<path> will be made available by the servlet container as static resources (accessible as <path>).
However the servlet 3.0 specs doesn't support adding those JAR dynamically outside of WEB-INF/lib so it doesn't work with our extension mechanism.
Thus I'm proposing the following (which I have tested to work):
* Add a new WebJarFilter filter to web.xml
* The URL to access, for ex, angular.js packaged in the http://repo2.maven.org/maven2/org/webjars/angularjs/1.1.5-1/angularjs-1.1.5… jar would be: /xwiki/webjar/angularjs/1.1.5/angular.js
This allows for example to have a dep on:
<dependency>
<groupId>org.webjars</groupId>
<artifactId>angularjs</artifactId>
<version>1.1.5-1</version>
<scope>runtime</scope>
</dependency>
Then in a JSX object:
require(["/xwiki/webjar/angularjs/1.1.5/angular.js"], function() {
…
});
WDYT?
Thanks
-Vincent
Hi,
we studied the source code of the gwt wysiwyg editor but we found no
official way to integrate an custom plugin.
We have the impression that it should be relatively easy to establish a
public API for registering customer plugins.
The customer plugin would be delivered as javascript code with a global
javascript function that implements PluginFactory interface.
The WysiwygEditorConfigClass would have an addition property
customerPlugins, containing a comma seperate list of strings of the
PluginFactory method names.
Do you think that this is doable?
Regards
Richard
--
View this message in context: http://xwiki.475771.n2.nabble.com/Adding-a-customer-plugin-to-the-wysiwyg-e…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
*Short version* for voting:
*A*. Creation of a new wiki on xwiki.org farm that will hold development
process details about a specific feature. This wiki will deprecate
dev.xwiki.org:Design and incubator.myxwiki.org
*B*. Vote on naming alternatives for this new wiki:
design.xwiki.orgincubator.xwiki.org
*C*. UI on how a Proposal will be displayed in this new wiki (example
AppWithinMinutes):
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki
------------------------------------------------
*Long version: *
Right now development process activities are located in multiple places:
- Analysis + Architecture: http://dev.xwiki.org/xwiki/bin/view/Design/
- Analysis + User Interface:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/
- Other: http://xwiki.markmail.org/, http://jira.xwiki.org, chats, git
comments, etc.
This process can be hard to optimize and information is hard to track if
you are looking for specific information.
And the worst part of it is that is hard to automatize and lots of the
items need manual gathering or search.
*Part A. *
This mail is about combining http://dev.xwiki.org/xwiki/bin/view/Design/andhttp://incubator.myxwiki.org/ work in a single place.
This has already been discussed several times before (
http://xwiki.markmail.org/thread/kc32dufsf7nyyt6s and
http://xwiki.markmail.org/thread/izj6aiyodwqia4vl) and the vote was
favorable in this direction.
The proposal was to create a new wiki called design.xwiki.org that will
contain the combined information and that will target developers.
The new wiki will be used to gather only proposal's development process
information: requirements, architecture, solutions alternatives, user
interface variants, planning, etc. for a specific feature/idea/improvement.
After the proposal is implemented it will be properly documented in the
right location for users (ex platform.xwiki.org).
It is acceptable to have CSS + JS code on this wiki in order to demonstrate
the functionality of the proposals, but we should not add
experimental/dangerous code (groovy scripts, jars, etc.). For this case it
is advisable to use a test machine, share your own instance or use the
contrib.xwiki.org repository for hosting.
The version upgrades will be handle by a community admin and the wiki
gardening by me.
The data from incubator.myxwiki.org and dev.xwiki.org:Design will be moved
gradually after the new wiki is created.
*Part B. *
You should state your opinion regarding which name is better for the new
wiki:
- design.xwiki.org
- incubator.xwiki.org
- we accept other proposals.
*Part C.*
I've made a proposal on how a proposal page would look like:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki
The proposal page will gather all the information related to it, making it
easier to track it's progress.
The entries will be separated depending on 4 categories: Analysis,
Architecture, User Interface and Implementation, each category having it's
own status, participants, jiras and timeframe.
Categories are not mandatory for all proposals, smaller proposals will have
just the related pages for certain areas.
Each proposal will store it's data in a dedicated space.
The implementation of the proposal will be handled by me.
Let me know what you think.
Thanks,
Caty
Hi devs,
For content pages, the bottom tabs (comments, attachments, history,
information) are very useful features. But does it make sense to keep
those active for very technical pages?
For example, when viewing details about a tag, (Main/Tags?do=viewTag),
why should people be allowed to comment? They might wrongly think that
they're commenting on a tag, but that's just one complex page that
handles almost everything about tags, so a comment like "this tag has a
typo" doesn't help at all.
Other pages should have no bottom tabs as well: user directory, blog
category management, the whole scheduler space, share by email...
While the homepage is a technical page (by default), it does make sense
to leave the comments active, since it's the entry point for every user
(although I think that the messaging system is a better way to send
global messages).
IMO, the advantage is that we're hiding actions that are rarely useful,
but could be misused. The disadvantage is that we're breaking the
universality of the UI.
I'm +1 for hiding, fewer mis-usable features is always better.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
I am currently running Tomcat 7.0.39 as well the Xwiki 5.0.3 WAR. I
imported the Xwiki database into MySQL from an older version of Xwiki which
could be the cause of the problems below...
When I enter "Administer Xwiki" and choose "Groups" I am sent to the
following which lists the groups as expected.
/xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin§ion=Groups#|t=groupstable&p=1&l=10&wiki=local
When I click on the "pencil icon" to add a user to a group the same page URL
is refreshed and shows a lot of white space followed by a list of users in
that group at the bottom of the page.
There is no option to add the user to a group. So somewhere along the line
I believe something became corrupt during my Xwiki update.
I tried copying some VMs from the templates subdir back to my main webapp
directory but that didn't work.
Any suggestions on where to look?
Screenshot attached.
<http://xwiki.475771.n2.nabble.com/file/n7585667/part2.png>
--
View this message in context: http://xwiki.475771.n2.nabble.com/Unable-to-add-user-to-group-after-Xwiki-u…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
We need to solve http://jira.xwiki.org/browse/XWIKI-9157
I'm proposing to simply move all ScriptService implementations out of the internal package and make that a rule.
These classes are used by introspection and as such as not used as components and thus they should not be in the internal package.
Here's my +1 and I'm proposing to handle the move.
I can't think of anything that would break except some users who would have had an import in a groovy script on some internal Script Service but that's ok IMO.
Thanks
-Vincent
Hi devs,
As you may have seen I've started working again on xwiki-platform-url module (http://jira.xwiki.org/browse/XWIKI-3951) and I now need to add wiki alias support for it. Right now wiki alias support is in oldcore and the url module must not depend on oldcore so I need to extract wiki alias support to a new module. I'm proposing to create a xwiki-platform-wiki module which should contain in the future all modules related to multi wiki handling for stuff not in the model (stuff in the model will go in xwiki-platform-model).
Right now I'm proposing to have:
xwiki-platform-wiki
|_ xwiki-platform-wiki-descriptor
where xwiki-platform-wiki-descriptor will implement description of wikis as xobjects in wiki pages (XWikiServerClass), i.e. what is currently in oldcore's XWiki#findServer.
In the future the idea will be to rewrite xwiki-platform-wiki-manager and to move it to xwiki-platform-wiki/xwiki-platform-wiki-manager for example (or with another name).
WDYT?
Barring negative feedback I'll try to start working on this in the coming week.
Thanks
-Vincent
Hi everyone,
I have played some more with Xwiki over the week-end, and some security
issues came up, namely:
1) User own profile:
Any given user has the right to edit his own profile, so far so good
when the given user is in normal mode and the edit defaults to the
inline form. Now things get ugly when he switches to the advanced mode
and suddenly can add/update/delete objects and rights. For example he
can delete his Xwiki.users object and instantly completely break his
account. He can mess up with permissions, like granting others
permissions to his profile.
I am using a custom authentication/sso mechanism and when I create the
user on the fly, I among other things, store the userId from our system
into the XWiki.users (added one Int property). Suddenly, the user can
even change that value...
He can also rename his profile, effectively renaming his username...
which in a sandbox environment might not be too much of an issue, even
if I find it a little weird that users can change their identity on
their owns as often they want but when the wiki system in coupled with
another system, it's just a disaster...
2) User in advanced mode
Generally speaking, users in advanced mode seems to be able to do things
that I didnt foresee with just the edit permission :
- I could grant myself the delete permission on pretty much any
page I have edit permission and therefore deleting the pages
- I could add/update/delete pretty much any objects on any page I
have edit permission including XWiki.XWikiRights instances which seems
to cover the ACL specific to the page. I granted there myself
programming rights, it does not seem to work however the ACL is saved
just fine...
Regarding the ACL, I strongly suggest that on the Access Rights page,
when the permission is blank (delegating upstream), the given permission
should be still visible (with a tooltip indicating from where the
permission has been inherited), maybe in parenthesis just after the
checkmark box. It is crucial that on any page/space/wiki, an admin is
able to review the effective permissions of that given page/space/wiki.
Otherwise, it makes reviewing permissions a nightmare really quickly.
3) HTML macro
This is more a question on the best way to make sure the HTML macro will
filter out specific stuff to prevent script injection ? From what I
understand, the macro cannot be removed at the moment but I am not sure
what is the best way to secure it.
Regarding 1 & 2, hopefully I am overlooking something but I looked
around and could not find any thing obvious.
Using Xwiki Enterprise 5.1
Thanks in advance for your help !
--
Chris