I'd like to know if this behavior is correct/desired.
1. Users without PR can register skins.
2. Skins can override global velocity macros.
3. Macros are evaluated in the security context of the caller.
If the answer to these questions is yes, then a document which
invokes a global macro such as #livetable does not know that the
macro may be overridden by the skin and it may be doing something in
their name which is a security gotcha and should be loudly documented.
If this behavior is not desired then maybe the best solution is to
prevent skin macros from overriding global macros unless the skin
author has PR.
WDYT?
Caleb
Hi devs,
I want to add a control to choose the page size of livetables. I have made a
proposal, and Guillaume Lerouge has suggested to show it by the default when
using the #livetable macro. This addition is not intrusive, takes no
additional place in the UI and does not require additional support on the
server side.
My updated proposal is resumed here:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/LivetablePageSizer
I would like to apply this patch for XE2.4M1.
Here is my +1
Denis
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
In http://www.mail-archive.com/devs@xwiki.org/msg14717.html
Ludovic said "We need to be as compatible as possible with how the
current invitation manager stores it's configuration and state
(current invitation and requests)"
I think this concept is worthy of it's own discussion thread.
When I approached this project, I hadn't considered a need for an
upgrade path from the Invitation Manager (I assume that's what this
is for.) The application as it stands is quite dependent on a
different configuration/storage model and changing will take a long
time.
Do we really want to use the same configuration/storage as the
Invitation Manager?
* The Invitation Manager plug-in uses configuration parameters
defined in the now deprecated xwiki.cfg file while Invitation
Application uses a custom configuration class through the
XWiki.ConfigurableClass system.
* Invitation Manager and Invitation Application both store message
status as a number, Invitation Application uses additional codes for
"sending failed", "reported as spam", and "reported and investigated".
* Invitation Manager has an additional field "space" which will make
no sense without Space Manager plug-in in the invitation application
setup and will have to be replaced by "groups".
* To copy Invitation Manager setup will block further feature
addition such as invitations which expire after a given amount of
time (for mailing lists).
* Invitation Manager templates are coded in a format similar to
XWiki/1.0 syntax (but not exactly the same) Invitation Application
templates are (currently) to be coded in XWiki/2.0 syntax.
Options:
We could continue the Invitation Application as is and if an upgrade
path is needed, add a script for upgrading legacy data later on.
Drop the current work and get the Invitation Manager plugin to build
(It would be a shame to dump so much work over one requirement.)
Rewrite the current work to be compatible with the old Invitation
Manager, accept using depricated configuration and sacrifice
features (this will take the most time.)
What are your thoughts?
Caleb
Marius wrote:
* Inherit the WYSIWYG GWT module in your own GWT module descriptor
** Use the same entry point as the WYSIWYG GWT module, which publishes
a JavaScript API you can use to instantiate the editor, or
** Use your own entry point and instantiate the editor in GWT code
How would I instantiate the editor in GWT code? I've been trying to
achieve this, but I get an editor that will not accept typing. That
is, typing characters into the editor has no effect; the characters
don't display, and there is no change to the state of the editor in
the DOM. I figure it must be something to do with the way I'm creating
it.
Hello all,
The partially completed invitation application is up and running on the incubator.
http://incubator.myxwiki.org/xwiki/bin/view/InvitationMail/
Right now the actual sending of the email is disabled until we can decide who's allowed to send.
Anyone who's a member of myxwiki.org ( http://www.myxwiki.org/bin/register/XWiki/Register ) can test out the
functionality, acting as a user or as an administrator.
Even though the email isn't sent, you can still try accepting, rejecting, or reporting your messages as spam.
If you report your message as spam (and click confirm) you will not be able to send any more mail unless you
use the "view as an administrator" page.
The main page (above) has open commenting so you can voice your opinion there or in response to this message
and help expand and clarify the "todo" list. I'm anxious to hear good ideas and criticism.
Caleb
Dear community,
XWiki SAS is participating and leading a research project called Wiki3.0
together with the SCORE Team of the "Institut National de Recherche en
Informatique et Automatique (INRIA)" (http://score.loria.fr/) and the
well known Linux distribution editor Mandriva (http://www.mandriva.com).
The Wiki3.0 project aims at developing a next generation collaboration
platform that integrates real-time editing and interactions,
social-networking features, and that will take advantage of cloud
infrastructures.
The final outcome of the Wiki 3.0 project is to deliver a solution that
will greatly ehnance the productivity in terms of knowledge exchange and
creation. This solution will consist of an enhanced version of the XWiki
platform that will include real-time collaboration and
social-network-oriented features.
I am writing this mail for requesting the Wiki3.0 project to be hosted
as a contributed project of the XWiki.org platform.
The project will use the xwiki.org SVN repository, XWiki developer's
mailing list and the JIRA platform to track and document its evolution.
Many of the participants of this project are already committers for the
XWiki platform. In addition we will need to give committer rights to the
SCORE Team members and, in particular, to Bogdan Flueras which will be
the main developer at the SCORE Team.
I, Fabio Mancinelli, will be the coordinator of the whole project.
The current website of the project is https://wiki30.xwikisas.com/
Thank you,
- Fabio