Hi All,
I sent 2 emails to the users list without much success and I am hoping
that I might find a more suitable audience for my somewhat technical
issues with the devs.
1) Global users in sub wiki.
In the system I am trying to setup, all the users are created using a
custom auth module in the main wiki (Global users), so there will be no
local users. The issue is that on a sub wiki, when you click on a user
to bring up its profile, you end up on a document not found. From the
auth module, the principal returned is prefixed with the 'XWiki.' so the
system should be able to differentiate between local and global users
and act accordingly.
I checked that I could reproduce the issue even if i am not using any
custom authentication.
Should i log this as a bug in Jira ?
2) Empty servlet path support
The second thing I am struggling with is shortening the urls. I am
following this guide:
> http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs
But no matter what I try, I cannot make it work without the '/bin/
prefix. Please note that the xwiki is running under Jetty as the main
context (mapped as '/') so the url I have is:
server.com/WebHome which according to the short urls document should work.
it appears that the issue comes from StandardXWikiURLFactory:
--------------------
String type = extendedURL.getSegments().get(0);
if (type.equals("bin") ||
type.equals(this.configuration.getWikiPathPrefix())) {
xwikiURL = this.entityURLFactory.createURL(extendedURL,
parameters);
} else {
throw new UnsupportedURLException(String.format("URL type
[%s] are not yet supported!", type));
}
----------------
So basically for server.com/WebHome, what is happening is that type
above equals to "WebHome" and so the condition obviously fails and
throws the UnsupportedURLException.
Given the above code, I am either forgetting something in the xwiki.cfg
or it simply cannot work out of the box...
If i were to provide my own custom XWikiUrlFactory, would it solve
entirely the issue or some other parts of the system will nevertheless
fails because they have the same assumption regarding the presence of
the bin or the PathPrefix in the url ?
Thanks in advance for your help !
--
Chris
Hi devs,
So this is a proposal to have Workspaces as a Flavor and NOT integrated by
default.
IMO Workspace is a real nice use case and we should definitely promote it.
This is how I envision the main homepage (Home)
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/WorkspaceHomep…
and this is how the homepage of a workspace would look like
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/WorkspaceHomep…
For more mockups please check the full proposal:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WorkspaceHomepage
The problem is that Workspace Flavor is a use case on it's own and IMO in
this particular use case you will not want to have isolated wikis, and plus
you will don't want to have lots of the features that are currently by
default, so it's really obvious that the Workspace flavor is a
specialization of XWiki and will not be anyone's cup of tee.
For example, the other Flavors proposed are:
- Public Website: you definitely don't need workspaces here
- Documentation: same, no need
- Application Development: this is intended for development, no need for
workspaces
See Flavors proposal
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Flavours
So Workspaces Flavors is exactly the Groupware Flavor (just I proposed it
with another name)
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/GroupwareFlavor
What I think we should do in 5.2 is indeed have by default the ability to
create multiple wikis (so XEM integration, bu without Workspaces).
So:
- Have 'Add - Wiki' only shown to admins (until we decide otherwise)
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/CreateWikiImpr…
- Have main wiki homepage defined as 'Home' (using the icon and with a
customizable title)
- Have a consistent create step for wikis, spaces and pages (in just one
step, since Members has sense only for Workspaces)
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/CreateWikiImpr…
- Integrate Wiki Manager inside Administration (since it's information
related to administrator and should not be public as it is now) We could
improve the UI by using a livetable
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/CreateWikiImpr…
All stated above is default functionality that doesn't break backwards
compatibility and that is shared between all Flavors.
Some base concepts related to Flavors:
- Let's consider that what we currently have is a 'Default Flavor' (XE)
- We could have a 'Base Flavor' in the future that will consist of 'Default
Flavor' minus all the extensions that are not share between all flavors. It
will contain just base features and the common denominator for all Flavors.
Every time you want to create a new Flavor you could start from this
Flavor.
- Extra: for test purposes we could also have a 'Full Flavor' containing
all the extensions supported by XWiki Development Team. This would be
helpful to run the integration tests on it and see if there are possible
problems when installing combinations of extensions. Also could serve as a
demo flavor of what is possible in XWiki.
- There will also be the 'Standard Flavors': Workspaces, Public Website,
etc. (proposed and supported by XWiki Development Team)
Having this is mind:
- Flavors should have the ability to "remove" or alter some pages from the
'Base Flavor' (currently our 'Default Flavor'). For example the Workspace
Flavor needs its custom main homepage that list the existing workspace
(this doesn't make any sense to any other Flavor). Another example is
removing 'Wiki Manager' from 'Default Flavor' and replace it with
'Workspaces Index' that is visible for all users.
- Flavors could have their own skin (might need some changed .vm) +
preferences (different layout, etc.). In the Workspace Flavor we will want
to promote the creation of Workspaces and not Wikis (that is found in the
Base Flavor).
- Flavors need to integrate other Flavors. For example: 'Workspace Flavor'
= 'Base Flavor' + extensions. Also we could have a 'Product Management
Flavor' = 'Workspace Flavor' + custom applications installed like:
Projects, Deliverables, Meetings, etc.
So what we could also do in 5.2 (or 5.3) is:
* Flavor definition (from a technical perspective), extensions collections,
ability to integrate also pages in the list, etc.
* Work separately on the 'Workspace Flavor' which could be our first
proposed Flavor (besides the current 'Default Flavor' which is a version of
Knowledge Base). This means improving the current 'Workspace Application'
with the above proposed Homepages improvements.
Let me know what you think,
Caty
Since we are integrating Workspaces to XE, I propose to add a new parameter
to set who has the right to create a new subwiki.
--------------
Proposal A:
--------------
We had a new item in the administration menu. This item is used to know
what level of right is needed to create a new wiki.
Examples:
* any user who have the 'edit' rights on the main wiki also has the right
to create new wikis
* any user who have the 'admin' rights on the main wiki also has the right
to create new wikis
--------------
Proposal B:
--------------
We create a new right (since we can thanks to Denis) called "SubWiki
creation right", and this right is needed to create a new subwiki. Then we
can add it to XWikiAllGroup or XWikiAdminGroup.
--------------
Proposal C:
--------------
We create a new group called 'XWikiAllowSubWikiCreationGroup', and
everybody who is on this group can create new wikis.
----
WDYT?
Thanks,
Louis-Marie
Hello,
Firstly I couldn't read everything because there is a lot of off topics so
forgive me if some of the following should not be here. If you have no time
go the last line directly.
I've been struggling with client with all those terms wich look like the
same (e.g. Main wiki, sub-wiki and then Workspace, Space) and the fact that
Workspace have "Work" into it and so is not really friendly to the client's
users. My first proposal would have been "Portal > Wiki > Space > Page" in
order to keep the basics and to find an easy way to describe the main wiki.
Then I read multiple threads and have a look to the competitors and
find-out that Home as a first term would be great and less technical than
Portal. Moreover Portal is full of connotations and do not show the
possibility to customize it.
"There is no place like Home" don't you think?
Proposal : Home > Wiki > Space > Page
Then I looked at the proposal made by Cathy on
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImprovem…
I would have picked B but I strongly dislike the fact that the product can
be two things at a time and so*
=> I vote for* *D*.
Regards,
--
Jean Coury
Hello devs,
I'd like to start working on improving the Task Manager Application found
at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati…
This application is very old and broken, and it does not work on recent
XWiki versions.
What I want to do is to commit the old code in a separate branch, and redo
the application using AWM technologies.
Also, I'd need a JIRA component for it with the first version being 2.0.
Version 1.0 is the old code.
Regards,
Sorin B.
Hi,
I'd like to add:
public interface ModelConfiguration
{
…
Syntax getDefaultSyntax();
}
And the configuration key would be:
model.defaultSyntax=xwiki/2.1
This also means deprecating CoreConfiguration.getDefaultDocumentSyntax() in oldcore
The goal is to have a clean way for getting the default syntax for documents for example without having to use oldcore.
I need this to fix http://jira.xwiki.org/browse/XWIKI-9074 for example.
WDYT?
Thanks
-Vincent
Hi devs,
I sent a VOTE email not long ago entitled "[VOTE] Integrate Workspaces by default in XWiki's default XAR".
So far I didn't get much responses (Vincent +1, Denis +1, Sergiu -0) and the thread was hijacked by Caty, transforming it as a proposal of various implementations while the goal of the mail was just to get an agreement about integration of the workspaces feature in XE in 5.2.
Edy commented in https://github.com/xwiki/xwiki-enterprise/pull/38 that he wasn't sure that everyone understood that the idea was to integrate all the subwiki usecases in 5.2 (i.e. myxwiki.org and xwiki.org uses cases, aka farm mode and workspaces mode).
Thus with this email I'd like to ensure that we agree to integrate both use cases.
IMO integrating only one is just asking for trouble and we need to take into account both use cases to make sure we have something consistent.
Is anyone disagreeing?
We need an answer on this for Guillaume to progress on https://github.com/xwiki/xwiki-enterprise/pull/38
Thanks
-Vincent