Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org
et your feedback on this! > > > The other big difference, to me, is in documentation. XWiki has > >>> changed a lot over the years, particularly in the API, > >> > >> This is not fully correct. A lot of new APIs have been introduced, > showing the > >> dynamism of the XWiki community indeed. However, we take very seriously > >> backward-compatibility (so seriously that breaking it fails our build > >> automatically ;)). So all that worked are still supposed to work. Do > you have > >> an example that you’ve noticed where it’s not true (it can happen from > time > >> to time when we conscientiously decide to break a recent API that we > think > >> nobody uses) . > > > > Again, I may be out of date here. I've really struggled to get the API > documentation for 7.1. I see that things have been cleaned up a lot at > http://platform.xwiki.org/xwiki/bin/view/DevGuide/API but the APIs still > seem to be missing for versions between 5.0 and 7.4.3. Obviously the > solution for me now would be to upgrade. > > Yes, we only maintain documentation for the latest version of XWiki on > xwiki.org (not enough manpower to have decent doc for several versions > ATM). > However, for version 6.2.5 and later, you have a way to mitigate this limitation. You can install the Scripting Documentation Application on your own wiki (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting+Documentation+Application). This application is dynamic, it searches and inspects bindings available to scripts in your running wiki, and provides direct access to the documentation of the corresponding Java class behind those bindings. Even scripting services added through custom extensions could be found and if these has been released on xwiki.org maven, their JavaDoc get linked as well. > > and a lot of the material discoverable on the web is out of date. > >> > >> Any example? That would help to fix them. > > > > Again this may be historical rather than present day. I'll certainly > yell if I encounter examples in the future. When I first set about writing > a component I googled around for examples and much of that was for the > older plugin architecture, and I was too new to things to appreciate the > difference. I think the API was also in a state of transition at the time, > so properties available through the wiki context required awkward bridging > classes that didn't make sense to noobs such as me. > > > > Incidentally, I think it could still be easier to write extensions for > XWiki. Writing Groovy components within XWiki pages is neat, but (at least > in 7.1) they don't work until someone manually visits the page a first > time. This means some components stop working when the system is restarted. > It also lacks access to a decent IDE interface to aide writing code - > sometimes I end up copying and pasting between the wiki editor and > Notepad++ so that I can get code formatting and syntax highlighting. > > They do always work actually, even when restarting. The issue is that if > you write in Groovy for example, you need Programming Rights (PR) since the > language can access anything, including the file system and more. You give > PR to a page when a user with PR saves it. And you loose PR when a user > without PR saves the page. So the page will work till someone without PR > saves it. To circumvent this, pages requiring PR could be right-protected > so that only user with PR can edit them for example. > > EDIT: I think you actually meant writing a groovy script to register some > code as a component. Actually we have wiki components for that: > http://extensions.xwiki.org/xwiki/bin/view/Extension/WikiComponent+Module Unless you are using XWiki prior to 4.2 , using Wiki Component is definitely the recommended way to writes Groovy components. Registering components "by hand" from a groovy script has many drawbacks not only the restart one, and you should avoid doing that. The best is of course to write the components in Java, and install them as an extension. > > > > Much of this difference is just a natural outcome of the proprietary vs. > >> open source backgrounds of each system. > >> > >> Well our goal is to be open source and still be good on all fronts! :) > > > > That's an admirable goal, and a formidable undertaking. Good luck! > You've certainly got an impressive product. > > Keep the feedback coming! Even the bad one, we need to learn what we > should improve. > > Thanks! > -Vincent > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > Thanks, -- Denis Gervalle SOFTEC sa - CEO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [ANN] XWiki 6.4.6 released
The XWiki development team is proud to announce the availability of XWiki 6.4.6. This is mainly a stabilization release that fixes important bugs discovered in the 6.4.5 and earlier versions. 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/ReleaseNotesXWiki646 The following people have contributed code to this release: Clemens Robbenhaar Denis Gervalle Ecaterina Moraru (Valica) Eduard Moraru Guillaume Delhumeau Marius Dumitru Florea Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [VOTE] Enable default actions for the Flamingo top menu entries
+1, ideally with a hover feedback very similar to the one of a dropdown button. On Fri, Dec 5, 2014 at 6:59 PM, Pascal BASTIEN wrote: > May I? (you send mail at user list)... then +1 > On 6.3 I still use 6.2 menu (I modified the template on my xwiki) > > I'm agree with you the 2 side of button must be better separate (with > color on hoover or a black vertical bar?). > > IMO we must respect the same logic of actions button (an one-click default > action and drop down sub menu level at the right-side-click ) > With CSS it should be possible to:- use 2 side button on big screen- use > GoTo menu on small screen > (with @media min-width) > > Thxs > Pascal BASTIEN > De : Marius Dumitru Florea > À : XWiki Developers ; XWiki Users > Envoyé le : Vendredi 5 décembre 2014 17h20 > Objet : [xwiki-users] [VOTE] Enable default actions for the Flamingo top > menu entries > > Hi everyone, > > = Short Story = > > I propose to change the behaviour of the top level menu from Flamingo > for tablet and desktop screens (so NOT for phones) to match the > behaviour we had in 6.2 BUT improving the separation between the > navigation links and the drop down toggle. The idea is that the top > level menu entries should behave like a drop down button (e.g. the Add > button) but without looking like one. You can see some screen shots at > http://jira.xwiki.org/browse/XWIKI-11517. > > = Long Story = > > I've heard complains that the current behaviour of the top level menu > from Flamingo skin is not perfect. The issue is that you need to click > twice to navigate. Ok, with a mouse you can use the middle click > (wheel) to open the link in a new tab but still it's annoying for > simple uses and for those that use the touch pad or a tablet. > > An alternative I have investigated in > http://jira.xwiki.org/browse/XWIKI-11479 is to open the menu on hover > (on devices that support this of course). The result is quite nice and > effective but there is a problem: if you have a second horizontal menu > displayed under the top level menu then you'll have a hard time > hovering the second menu. So I decided to close XWIKI-11479 as Won't > Fix. For those that like the open-on-hover behaviour and which don't > plan to use a second menu I've published this extension > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Hover+and+Default+Action+for+Flamingo+Menu > . > > The other alternative to fix the problem is to go back to the > behaviour from 6.2. Precisely, each menu has two sides: > * on the left is the label which is a link used for navigation > * on the right there is a toggle (arrow) used to open the menu. > > The problem with this, and the reason we change it in 6.3, was that > the label and the toggle were not separated very well so the user > could easily think they were doing the same action (opening the menu). > At the same time this separation felt unnatural on extra small screens > (phones) because you couldn't tap easily on the toggle (arrow). > > The solution I propose is to: > * Keep the current behaviour for extra small screens (phones). That > means the use has to tap twice to navigate: one tap to open the menu > and another one on the "Go to this XYZ". > * On desktop and tablet enable the default action (navigation link) as > in 6.2 but improve the separation so that the menu behaves as much as > possible as a drop down button (e.g. the Add button) without looking > like one. This means: > ** You should understand there are two sides without hovering > ** Separate hover and active state (e.g. the link is not hovered when > the toggle is hovered) > > I've investigated *many* ways to achieve this and the result can be > seen on http://jira.xwiki.org/browse/XWIKI-11517. This is close to > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Enable+Default+Action+for+Flamingo+Menu > but not the same. > > NOTE: The way the menu behaves and looks on hover and click (text and > background color) is strictly determined by the color theme. Some > themes highlight the hovered menu items by changing their background > color, others the text color and some do both. My changes are > independent on this. We can of course improve the default color theme > to better highlight the menu items. This is a different topic though. > > I'd like to commit this changes in 6.4. Here's my +1. > > Thanks, > Marius > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > > > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] XWiki User/Dev meet up in France? Paris? (Follow up #2)
On Tue, Sep 16, 2014 at 4:30 PM, vinc...@massol.net wrote: > Ok I’ve created a wiki page at > http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiMeetup2014 > > Please make sure to add yourself if you’re interested in participating > since I believe we would need at least 10-15 persons before we can consider > doing it in a useful manner. > > Right now we’re only 6 listed… > > Guillaume, Fabio, Caleb, Anca, Ludovic, Jean Coury: since you live in > Paris, wouldn’t you be interested? Denis (I know it’s farther for you but > you could stay in Paris for some days maybe)? > Added myself, I have missed your first mail. > > Thanks > -Vincent > > > On 29 Aug 2014 at 14:30:52, vinc...@massol.net (vinc...@massol.net(mailto: > vinc...@massol.net)) wrote: > > > Ok so far we have the following persons interested: > > - Patrick Moens > > - Josef Haimerl > > - Clemens Klein-Robbenhaar > > - Pascal Bastien > > - myself (Vincent Massol) > > > > Anyone else? > > > > In term of format I’m thinking about one of: > > > > - 1/2 day Discussions/Presentations + 1.5 days of Hackathon > > - 1 day of Discussions/Presentations > > - 1 day of Hackathon > > - 2 days of Hackathon > > - 1/2 day of Discussions/Presentations > > > > Any other idea? > > > > Once we have all ideas listed, I’ll send a doodle to decide on the > format + decide on the date. > > > > Thanks > > -Vincent > > > > > > > > On 18 Jul 2014 at 21:38:14, vinc...@massol.net (vinc...@massol.net > (mailto:vinc...@massol.net)) wrote: > > > > > Hi XWiki users, > > > > > > I’m wondering if we’d be enough to start organizing an XWiki users/dev > meetup in France. > > > > > > Could you let me know in reply if you’d be interested in joining if I > was to organize such a meetup? > > > > > > If we’re enough we could imagine organizing it in September or October > for example. XWiki SAS has an office located in Paris ( > http://www.xwiki.com/lang/en/Company/Contact) and they could host us. > > > > > > Note for those who’d be coming from afar, I’m sure that it would be > possible to have you sleep at some XWiki SAS employee’s place in Paris or > even in the office (there’s a shower and kitchen). > > > > > > Interesting or not? > > > > > > If you’re interested what would you be interested in doing/seeing > during this time? We could imagine a 3-4 hours meetup or even a 1 day > meetup. We could also imagine having a hackathon during the time, in this > case probably 2 days would be nicer. > > > > > > WDYT? > > > > > > Thanks > > > -Vincent > > > > > > > ___ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Failed migration from 3.0 to 4.3.1
Hi Robert,
Great to see you sorted it out with my help. For others to get benefit of
your issue, I recap here our findings and the solution.
Before 4.x, document identifiers are java hashcode of either the document
fullname alone or the document fullname joined with the language for
translated documents (separated by a colon).
In Robert's database, we have found about 64 documents that were not
translated document but with identifier of translated one, and moreover,
later version of these same documents that were marked translated
(xwd_translation=1), but that use the identifier of original document.
During a migration both document get their correct id back, and therefore
these ids collide.
Seen from the wiki, only the later document were properly seen, and all
information related to the earlier id were not visible. The history of the
document is not complete.
Here is a sample of the kind of anomalies we have found:
XWD_ID, XWD_FULLNAME, XWD_DEFAULTLANGUAGE, XWD_LANGUAGE, XWD_TRANSLATIONS,
XWD_VERSION
1869454895, Test.TestPage1, en, , 0, 2.1
945241012, Test.TestPage1, en, , 1, 3.1
where 1869454895 is hashCode("Test.TestPage1:en") and 945241012 is
hashCode("Test.TestPage1"),
the correct record that needs to be kept is
945241012, Test.TestPage1, en, , 0, 3.1
Record 1869454895 and all records in relation to 1869454895 should be
dropped from table xwikidoc, xwikilinks, xwikircs, xwikiattachment and
xwikiattrecyclebin. The simplest is to use the following requests:
delete from xwikidoc where xwd_id=1869454895;
delete from xwikilinks where xwl_doc_id=1869454895;
delete from xwikircs where xwr_docid=1869454895;
delete from xwikiattachment where xwa_doc_id=1869454895;
delete from xwikiattrecyclebin where xda_docid=1869454895;
If history is of utmost importance, however untested, an update of xwikircs
in place of a delete may work:
update xwikircs set xwr_docid= 945241012 where xwr_docid=1869454895;
Also note that after this cleanup, further cleanup may be needed and could
be found based on the sanitycheck.sql script you may download from
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Database+Administration.
This script is now updated to also display (in its last request) the
document names and language that are concerned by the above issue.
The following query may list the documents themselves and may help you
solve these conflicts:
select d.xwd_id, d.xwd_fullname, d.xwd_default_language, d.xwd_language,
xwd_date, xwd_version from xwikidoc as d inner join (select xwd_fullname,
xwd_default_language, xwd_language, count(*) from xwikidoc group by
xwd_fullname, xwd_default_language, xwd_language having count(*) > 1) as dd
on d.xwd_fullname=dd.xwd_fullname and
d.xwd_default_language=dd.xwd_default_language and
d.xwd_language=dd.xwd_language;
(you may need to create a view for the sub-query if your DB engine does
support the above syntax)
Hope the above will helps other sorting out an similar issue.
On Wed, Jan 23, 2013 at 8:55 AM, rschmid89 wrote:
> Hi Denis,
>
> I don't know whether the message with the infos about localization have
> reached you, so here they are again.
>
> Multilingual yes
> Languages de, en, it
> Defaultlanguage de
>
> Regards,
>
>
> rschmid89 wrote
> > Hi Denis,
> >
> > both queries didn't produce any rows.
> >
> > If you have time we could talk via IRC (http://webchat.quakenet.org/
> > channelname is #xwiki)
> >
> > Regards,
> > Robert
> > Denis Gervalle-2 wrote
> >> Robert,
> >>
> >> Could you run the following queries on the original DB:
> >>
> >> SELECT COUNT(*) AS cnt FROM xwikilinks GROUP BY XWL_DOC_ID, XWL_LINK
> >> HAVING
> >> cnt > 1;
> >>
> >> SELECT XWL_DOC_ID FROM xwikilinks LEFT JOIN xwikidoc ON XWL_DOC_ID =
> >> XWD_ID
> >> WHERE XWD_ID IS NULL;
> >>
> >> Does on of them produce any resulting rows ? it should not obviously.
> >> Regards,
> >>
> >>
> >> On Thu, Jan 17, 2013 at 11:50 AM, rschmid89 <
>
> >> r.schmidpeter@
>
> >> >wrote:
> >>
> >>> To 1) I'm using MS SQL
> >>> To 2) I have basic knowledge
> >>> To 3) At the moment I can only talk over e-mail
> >>>
> >>> Regards,
> >>>
> >>>
> >>> Denis Gervalle-2 wrote
> >>> > Robert,
> >>> >
> >>> > Statistic cleaning is useless since you have never used XWIki Stats
> on
> >>> > that
> >>> > DB.
> >>> > Look at the logs, what happens is somewhat impossible ! So I will
> have
> >>> to
> >>> > be creative to understand why the impossible became possible. But
&
Re: [xwiki-users] Data migration R40000XWIKI6990 fails with duplicate key error
Àlex, This is definitely an unexpected issue, but not an issue from the migration. It is however difficult to know which version has introduce it, and if the issue is still in the latest one. I would bet it isn't. Maybe, the best way to get around that issue, would be to rename the first document, so you will get access to the second one, and be able to rename it as well. Later you may rename the first one back. If you start hacking the database, you risk to introduce some inconsistencies, so I do not recommend that. For example, your proposed delete statements does not take care of objects, if any are attached with the document. Regards, On Thu, Jan 17, 2013 at 5:10 PM, Àlex Magaz Graça wrote: > Al 17/01/13 10:19, En/na Denis Gervalle ha escrit: > >> Hi Àlex, >> >> Sorry for this late reply. >> I need a larger extract of your logs to be able to help and probably more >> later. You may send it to me privately if you prefer. >> Regards, >> >> >> On Tue, Jan 8, 2013 at 12:19 PM, Àlex Magaz Graça >> **wrote: >> >> Hi, >>> >>> I'm trying to upgrade from XWiki 3.1 to 4.4, but I'm having problems with >>> the data migration process. >>> >>> It all goes well up until R4XWIKI6990, which fails due to a duplicate >>> key (see below, full Tomcat log also attached). It also fails with >>> safemode >>> enabled. >>> >>> ERROR o.h.u.JDBCExceptionReporter- ERROR: duplicate key value >>> violates >>> unique constraint "xwikidoc_pkey" >>> >>> I've tried running SQL commands from XWIKI-8129 [1] jira issue too, but >>> it doesn't apply any modification in my case. So it doesn't make any >>> difference. >>> >>> Older version of XWiki in-between also fail. >>> >>> The system set up is: >>> >>> Fedora 14 (x86_64) >>> Java 1.6.0_20 -- OpenJDK Runtime Environment (IcedTea6 1.9.10) >>> Tomcat 6 >>> PostgreSQL 8.4.9 >>> XWiki 3.1 (upgraded from 2.2.1 and with no configuration options changes) >>> >>> Any idea of how to solve this problem? >>> >>> Thanks, >>> Àlex >>> >>> [1] >>> http://jira.xwiki.org/browse/XWIKI-8129<http://jira.xwiki.org/browse/**XWIKI-8129> >>> <http://jira.xwiki.**org/browse/XWIKI-8129<http://jira.xwiki.org/browse/XWIKI-8129> >>> > >>> >>> >>> > Hi Denis, > > I finally got it solved yesterday. I was able to find the database record > that made the migration process fail by rising the log level to debug. I'll > explain in case someone else finds a similar problem. > > The problem was a wiki page that somehow got duplicated or created twice, > but with a slightly different name. Moreover, although the two database > records had different document ids, the id migration process assigned the > same final id for both of them. The records look like this in the database: > > xwd_id | xwd_fullname | xwd_name | > xwd_title | > --+---**---+--** > +-**---+ > 292584123 | Main.Cursos per a professorat 2011.2012 | 2012 | Cursos > per a professorat 2011/2012 | > 971984561 | Main\.Cursos per a professorat 2011.2012 | 2012 | Cursos > per a professorat 2011/2012 | > > > xwd_date | xwd_content_update_date | xwd_creation_date | > xwd_author | xwd_content_author > -+**-+** > -+---+**+ > 2011-10-25 20:30:10 | 2011-10-25 20:30:10 | 2011-08-26 13:30:42 | > XWiki.user1 | XWiki.user1 > 2012-11-12 11:25:30 | 2012-11-12 11:25:30 | 2011-12-13 15:41:49 | > XWiki.user2 | XWiki.user2 > > > xwd_creator | xwd_web | xwd_version | > xwd_parent > +-**---+--** > ---+- > XWiki.user2| Main.Cursos per a professorat 2011 | 146.1 | > Main.BETSEA > XWiki.user1| Main.Cursos per a professorat 2011 | 22.1| > Main.BETSEA > > > The rest of the fields either have the same values or are empty. As can be > seen in xwd_fullname, it looks like the dot on the page name might have > confused XWiki. In fact, if get to the page from the web interface, the > name of the page is "2012". It is as if XWiki had split the name at the > "." and had taken the previous string as the space name. The URL looks like > this: > > http://i
Re: [xwiki-users] Failed migration from 3.0 to 4.3.1
Robert, Could you run the following queries on the original DB: SELECT COUNT(*) AS cnt FROM xwikilinks GROUP BY XWL_DOC_ID, XWL_LINK HAVING cnt > 1; SELECT XWL_DOC_ID FROM xwikilinks LEFT JOIN xwikidoc ON XWL_DOC_ID = XWD_ID WHERE XWD_ID IS NULL; Does on of them produce any resulting rows ? it should not obviously. Regards, On Thu, Jan 17, 2013 at 11:50 AM, rschmid89 wrote: > To 1) I'm using MS SQL > To 2) I have basic knowledge > To 3) At the moment I can only talk over e-mail > > Regards, > > > Denis Gervalle-2 wrote > > Robert, > > > > Statistic cleaning is useless since you have never used XWIki Stats on > > that > > DB. > > Look at the logs, what happens is somewhat impossible ! So I will have to > > be creative to understand why the impossible became possible. But before, > > I > > need some more information. > > > > 1) Have you migrated that wiki (at some point in time) from a MyISAM to > > innoDB MySQL engine ? > > 2) What are your skill in databases ? > > 3) Are you available to talk over irc or any other IM network (MSN, > gTalk, > > ...) ?, it may be faster for me to help you interactively. > > > > Regards, > > > > > > On Thu, Jan 17, 2013 at 10:38 AM, rschmid89 < > > > r.schmidpeter@ > > > >wrote: > > > >> Hi Denis, > >> > >> I did the statistic cleaning every time after the rewriting of the > backup > >> on > >> the db. And I delete the to changelog tables everytime before starting > >> xwiki. > >> > >> So here is the stdout (http://pastebin.com/eSXE88Q5), it would be great > >> if > >> you could help me through this. > >> > >> Regards > >> > >> > >> Denis Gervalle-2 wrote > >> > Hi Robert, > >> > > >> > The migration had failed in some way, and the log you provided is just > >> the > >> > consequences of that. To understand what may have happened, you need > to > >> > look at logs (the standard output of the server), and looks carefully > >> > where > >> > the migration failed. If you are migrating a wiki that have existed > >> before > >> > 3.x, and you have some statistics in your database, you may also want > >> to > >> > clean them up as explained in the release notes. > >> > > >> > If you may provide the log of the migration, I will try to help you > >> > understand the issue. > >> > Regards, > >> > > >> > > >> > On Thu, Jan 17, 2013 at 9:08 AM, rschmid89 < > >> > >> > r.schmidpeter@ > >> > >> > >wrote: > >> > > >> >> Sorry I forgot to say that I'm running xwiki on Tomcat 7 with MS SQL > >> as > >> >> database. > >> >> > >> >> In my xwiki.cfg the xwiki.store.migration=1, so it's set. I also > tried > >> >> setting xwiki.store.migration.R4XWIKI6990.safemode=1, but there > >> were > >> >> no > >> >> changes, so I've tried xwiki.store.migration.force=R40001XWIKI7540. > >> But > >> >> the > >> >> only changes were, that I entered an empty xwiki and there the import > >> of > >> >> the > >> >> enterprise-ui. xar made problems. > >> >> > >> >> http://pastebin.com/xdM0QZia (xwiki.cfg) > >> >> > >> >> > >> >> > >> >> Thomas Mortagne wrote > >> >> >> com.xpn.xwiki.store.migration.MigrationRequiredException: Database > >> >> xwiki > >> >> >> needs migration(s), it could not be safely used! > >> >> > > >> >> > As far as I know this means you disabled migration and XWiki is > >> >> > telling you that there is no wait it can continue without migrating > >> >> > the database so you will need to enable it in xwiki.cfg > >> >> > (xwiki.store.migration property). > >> >> > > >> >> > On Wed, Jan 16, 2013 at 2:43 PM, rschmid89 < > >> >> > >> >> > r.schmidpeter@ > >> >> > >> >> > > wrote: > >> >> >> Hello, > >> >> >> > >> >> >> could someone please help me with the following error: > >> >> >> > >> >> >> 16.01.2013 12:36:11 org.apach
Re: [xwiki-users] Failed migration from 3.0 to 4.3.1
Robert, Statistic cleaning is useless since you have never used XWIki Stats on that DB. Look at the logs, what happens is somewhat impossible ! So I will have to be creative to understand why the impossible became possible. But before, I need some more information. 1) Have you migrated that wiki (at some point in time) from a MyISAM to innoDB MySQL engine ? 2) What are your skill in databases ? 3) Are you available to talk over irc or any other IM network (MSN, gTalk, ...) ?, it may be faster for me to help you interactively. Regards, On Thu, Jan 17, 2013 at 10:38 AM, rschmid89 wrote: > Hi Denis, > > I did the statistic cleaning every time after the rewriting of the backup > on > the db. And I delete the to changelog tables everytime before starting > xwiki. > > So here is the stdout (http://pastebin.com/eSXE88Q5), it would be great if > you could help me through this. > > Regards > > > Denis Gervalle-2 wrote > > Hi Robert, > > > > The migration had failed in some way, and the log you provided is just > the > > consequences of that. To understand what may have happened, you need to > > look at logs (the standard output of the server), and looks carefully > > where > > the migration failed. If you are migrating a wiki that have existed > before > > 3.x, and you have some statistics in your database, you may also want to > > clean them up as explained in the release notes. > > > > If you may provide the log of the migration, I will try to help you > > understand the issue. > > Regards, > > > > > > On Thu, Jan 17, 2013 at 9:08 AM, rschmid89 < > > > r.schmidpeter@ > > > >wrote: > > > >> Sorry I forgot to say that I'm running xwiki on Tomcat 7 with MS SQL as > >> database. > >> > >> In my xwiki.cfg the xwiki.store.migration=1, so it's set. I also tried > >> setting xwiki.store.migration.R4XWIKI6990.safemode=1, but there were > >> no > >> changes, so I've tried xwiki.store.migration.force=R40001XWIKI7540. But > >> the > >> only changes were, that I entered an empty xwiki and there the import of > >> the > >> enterprise-ui. xar made problems. > >> > >> http://pastebin.com/xdM0QZia (xwiki.cfg) > >> > >> > >> > >> Thomas Mortagne wrote > >> >> com.xpn.xwiki.store.migration.MigrationRequiredException: Database > >> xwiki > >> >> needs migration(s), it could not be safely used! > >> > > >> > As far as I know this means you disabled migration and XWiki is > >> > telling you that there is no wait it can continue without migrating > >> > the database so you will need to enable it in xwiki.cfg > >> > (xwiki.store.migration property). > >> > > >> > On Wed, Jan 16, 2013 at 2:43 PM, rschmid89 < > >> > >> > r.schmidpeter@ > >> > >> > > wrote: > >> >> Hello, > >> >> > >> >> could someone please help me with the following error: > >> >> > >> >> 16.01.2013 12:36:11 org.apache.catalina.core.StandardWrapperValve > >> invoke > >> >> SCHWERWIEGEND: Servlet.service() for servlet [action] in context with > >> >> path > >> >> [/xwiki] threw exception [com.xpn.xwiki.XWikiException: Error number > 3 > >> in > >> >> 0: > >> >> Could not initialize main XWiki context > >> >> Wrapped Exception: Error number 3202 in 3: Exception while reading > >> >> document > >> >> [xwiki:XWiki.TagClass] > >> >> Wrapped Exception: Error number 3301 in 3: Exception while switching > >> to > >> >> database xwiki > >> >> Wrapped Exception: Database xwiki needs migration(s), it could not be > >> >> safely > >> >> used!] with root cause > >> >> com.xpn.xwiki.store.migration.MigrationRequiredException: Database > >> xwiki > >> >> needs migration(s), it could not be safely used! > >> >> at > >> >> > >> > com.xpn.xwiki.store.migration.AbstractDataMigrationManager.checkDatabase(AbstractDataMigrationManager.java:442) > >> >> at > >> >> > >> > com.xpn.xwiki.store.XWikiHibernateBaseStore.setDatabase(XWikiHibernateBaseStore.java:678) > >> >> at > >> >> > >> > com.xpn.xwiki.store.XWikiHibernateBaseStore.beginTransaction(XWikiHibernateBaseStore.java:853) > >>
Re: [xwiki-users] Exceptions when initializing an empty db
xwiki.store.XWikiHibernateStore.loadXWikiDoc(XWikiHibernateStore.jav > a:750) > > > com.xpn.xwiki.store.XWikiCacheStore.loadXWikiDoc(XWikiCacheStore.java:290) > > com.xpn.xwiki.XWiki.getDocument(XWiki.java:1404) > > com.xpn.xwiki.XWiki.getDocument(XWiki.java:1447) > > > com.xpn.xwiki.XWiki.initializeMandatoryClasses(XWiki.java:824) > > com.xpn.xwiki.XWiki.initXWiki(XWiki.java:794) > > com.xpn.xwiki.XWiki.(XWiki.java:735) > > com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:394) > > com.xpn.xwiki.XWiki.getXWiki(XWiki.java:483) > > com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136) > > com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:116) > > > > org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces > sor.java:431) > > > > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) > > > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) > > > org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > > > com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:120) > > > > org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.j > ava:144) > > > com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:66) > > > > org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFi > lter(SavedRequestRestorerFilter.java:208) > > > > org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFi > lter(SetCharacterEncodingFilter.java:111) > > > > > > > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Data migration R40000XWIKI6990 fails with duplicate key error
Hi Àlex, Sorry for this late reply. I need a larger extract of your logs to be able to help and probably more later. You may send it to me privately if you prefer. Regards, On Tue, Jan 8, 2013 at 12:19 PM, Àlex Magaz Graça wrote: > Hi, > > I'm trying to upgrade from XWiki 3.1 to 4.4, but I'm having problems with > the data migration process. > > It all goes well up until R4XWIKI6990, which fails due to a duplicate > key (see below, full Tomcat log also attached). It also fails with safemode > enabled. > > ERROR o.h.u.JDBCExceptionReporter- ERROR: duplicate key value violates > unique constraint "xwikidoc_pkey" > > I've tried running SQL commands from XWIKI-8129 [1] jira issue too, but > it doesn't apply any modification in my case. So it doesn't make any > difference. > > Older version of XWiki in-between also fail. > > The system set up is: > > Fedora 14 (x86_64) > Java 1.6.0_20 -- OpenJDK Runtime Environment (IcedTea6 1.9.10) > Tomcat 6 > PostgreSQL 8.4.9 > XWiki 3.1 (upgraded from 2.2.1 and with no configuration options changes) > > Any idea of how to solve this problem? > > Thanks, > Àlex > > [1] > http://jira.xwiki.org/browse/**XWIKI-8129<http://jira.xwiki.org/browse/XWIKI-8129> > > > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Failed migration from 3.0 to 4.3.1
lDoFilter(ApplicationFilterChain.java:306) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > >> at > com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:120) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:244) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > >> at > >> > org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:144) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:244) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > >> at > >> > com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:66) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:244) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > >> at > >> > org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:208) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:244) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > >> at > >> > org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:111) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:244) > >> at > >> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > >> at > >> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) > >> at > >> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > >> at > >> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) > >> at > >> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) > >> at > >> > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) > >> at > >> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > >> at > >> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:383) > >> at > >> > org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:284) > >> at > >> > org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:322) > >> at > >> > org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1684) > >> at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > >> Source) > >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > >> Source) > >> at java.lang.Thread.run(Unknown Source) > >> > >> I've tried everything I found so far, but nothing changed the outcome. > >> > >> With best regards > >> > >> Robert > >> > >> > >> > >> -- > >> View this message in context: > >> > http://xwiki.475771.n2.nabble.com/Failed-migration-from-3-0-to-4-3-1-tp7583304.html > >> Sent from the XWiki- Users mailing list archive at Nabble.com. > >> ___ > >> users mailing list > >> > > > users@ > > >> http://lists.xwiki.org/mailman/listinfo/users > > > > > > > > -- > > Thomas Mortagne > > ___ > > users mailing list > > > users@ > > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Failed-migration-from-3-0-to-4-3-1-tp7583304p7583327.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] References Section update proposal
Hi Benjamin, On Tue, Dec 18, 2012 at 4:49 PM, Benjamin Lanciaux < benjamin.lanci...@xwiki.com> wrote: > Hello all, > > I would like to propose an update of the xwiki.org references section : > http://www.xwiki.org/xwiki/bin/view/References/WebHome > > At the moment, there is no field mentioning who developed the XWiki > website/project/reference. > Some of us are using the "Organization" field to specify what the company > benefiting from the website is. The others are using it to mention the > company which developed and implemented the project. > I had exactly the same discussion with Vincent when I fill in my own project. > > That is why I propose to add a new field : "developed by". > Thanks to this, it will be easier to understand who did what and who > benefits from what. > This sounds good to me, it would be nice to try to have the current entries updated. > > I also suggest to add another criteria : "external/internal" which would > help users understand if a project is public or private. > Not sure this is needed, most project published there will be public, and there is the URL anyway, that may stay empty. Using tags is also an option, but not sure it will be trivial while filling the form. Does it really provide a really useful info ? > > Looking forward to your feedback. > > -- > Benjamin Lanciaux > Marketing Project Manager @XWiki SAS > Skype : benjaminxwiki > Tel : 01.45.42.40.90 > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.3 Milestone 2 released.
On Thu, Nov 15, 2012 at 12:48 PM, Jeremie BOUSQUET <
jeremie.bousq...@gmail.com> wrote:
> Hi,
>
> Thanks guys for this release :)
>
> Just deployed it and second experience of "distribution wizard" is becoming
> really nice.
>
> I have some minor comments though:
>
> - on first screen, it detected I had to move to UI 4.3.M2, but by mistake I
> chose "Continue" without installing it. Maybe it's me, or maybe the
> proposal to install it was not "flashy" enough. Usually when you have a
> dialog with buttons as "skip" or "continue", you don't expect having
> something to do inside the dialog itself. But again, maybe it's only me
> missing some sleep ;-)
>
See also http://markmail.org/thread/fyk47aq4y3pew7mn for a previous
discussion on the same subject.
>
> - anyway it was proposed on next screen ("Extensions") so it was nice. But
> maybe this screen is missing a "Back" button. Maybe then also, the need to
> have 2 distinct steps in the wizard is not so evident (for now ?).
>
> - on second screen, when upgrading extensions, nice progress bar is
> displayed, and the install logs automatically scroll to the bottom (last
> logs). But when computing install plan (just before), there's also a nice
> progress bar, but logs stick to the top. When manually scrolling back,
> display is moved back to the top as soon as some log is added
>
> - once distribution wizard is closed, maybe it could be interesting to
> provide possibility to check what happened during last execution of
> distribution wizard ? (logs, actions performed ...). Maybe it would be nice
> to even get the history (and not just last execution) from an admin UI. Or
> to re-launch the wizard without having to restart the wiki (maybe it's
> feasible, I didn't really check).
>
> I must say that I didn't check in JIRA if some of these comments are
> already tracked ... :/
>
> But I must say, comparing to previous upgrades, that importing the new
> default UI Xar was really simple and it was really nice, so thanks for that
> guys :)
>
> Best regards,
> Jeremie
>
>
>
> 2012/11/13 Eduard Moraru
>
> > The XWiki development team is proud to announce the availability of XWiki
> > Enterprise 4.3 Milestone 2.
> >
> > This release brings:
> > - a new and experimental Solr Search engine
> > - new default date, user and group pickers
> > - a new localization module allowing applications to register
> translations
> > - REST API additions
> > - various other improvements.
> >
> > 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/ReleaseNotesXWiki43M2
> >
> > Thanks
> > -The XWiki dev team
> > ___
> > devs mailing list
> > d...@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> ___
> devs mailing list
> d...@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Migration from 2.4 to the latest debian package (4.1.4): Duplicate entry error on R40000XWIKI6990
gacy-oldcore-4.1.4.jar:na] > > > at > com.xpn.xwiki.store.migration.hibernate.AbstractHibernateDataMigration.migrate(AbstractHibernateDataMigration.java:109) > ~[xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > ... 61 common frames omitted > > > Caused by: com.xpn.xwiki.XWikiException: Error number 0 in 3: > Exception while hibernate execute > > > Wrapped Exception: could not execute native bulk manipulation query > > > at > com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseStore.java:1214) > [xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > at > com.xpn.xwiki.store.XWikiHibernateBaseStore.executeWrite(XWikiHibernateBaseStore.java:1322) > [xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > at > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration.hibernateMigrate(R4XWIKI6990DataMigration.java:1286) > ~[xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > ... 62 common frames omitted > > > Caused by: org.hibernate.exception.ConstraintViolationException: could > not execute native bulk manipulation query > > > at > org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96) > ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] > > > at > org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) > ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] > > > at > org.hibernate.engine.query.NativeSQLQueryPlan.performExecuteUpdate(NativeSQLQueryPlan.java:219) > ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] > > > at > org.hibernate.impl.SessionImpl.executeNativeUpdate(SessionImpl.java:1310) > ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] > > > at > org.hibernate.impl.SQLQueryImpl.executeUpdate(SQLQueryImpl.java:396) > ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] > > > at > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration$AbstractBulkIdConversionHibernateCallback.executeSqlIdUpdate(R4XWIKI6990DataMigration.java:531) > ~[xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > at > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration$7.doBulkIdUpdate(R4XWIKI6990DataMigration.java:1294) > ~[xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > at > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration$AbstractBulkIdConversionHibernateCallback.doUpdate(R4XWIKI6990DataMigration.java:356) > ~[xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > at > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration$AbstractUpdateHibernateCallback.doInHibernate(R4XWIKI6990DataMigration.java:218) > ~[xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > at > com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseStore.java:1208) > [xwiki-platform-legacy-oldcore-4.1.4.jar:na] > > > ... 64 common frames omitted > > > Caused by: > com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: > Duplicate entry '5441591690732251370' for key 'PRIMARY' > > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > ~[na:1.6.0_34] > > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > ~[na:1.6.0_34] > > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > ~[na:1.6.0_34] > > > at > java.lang.reflect.Constructor.newInstance(Constructor.java:513) > ~[na:1.6.0_34] > > > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > ~[mysql-connector-java-5.1.16.jar:na] > > > at com.mysql.jdbc.Util.getInstance(Util.java:386) > ~[mysql-connector-java-5.1.16.jar:na] > > > at > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040) > ~[mysql-connector-java-5.1.16.jar:na] > > > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) > ~[mysql-connector-java-5.1.16.jar:na] > > > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) > ~[mysql-connector-java-5.1.16.jar:na] > > > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) > ~[mysql-connector-java-5.1.16.jar:na] > > > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) > ~[mysql-connector-java-5.1.16.jar:na] > > > at > com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) > ~[mysql-connector-java-5.1.16.jar:na] > > > at > com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) > ~[mysql-connector-java-5.1.16.jar:na] > > > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) > ~[mysql-connector-java-5.1.16.jar:na] > > > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) > ~[mysql-connector-java-5.1.16.jar:na] > > > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) > ~[mysql-connector-java-5.1.16.jar:na] > > > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) > ~[commons-dbcp-1.3.jar:1.3] > > > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) > ~[commons-dbcp-1.3.jar:1.3] > > > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) > ~[commons-dbcp-1.3.jar:1.3] > > > at > org.hibernate.engine.query.NativeSQLQueryPlan.performExecuteUpdate(NativeSQLQueryPlan.java:210) > ~[hibernate-core-3.6.9.Final.jar:3.6.9.Final] > > > ... 71 common frames omitted > > > > > > How can I proceed with the migration ? > > > > > > Should I try to migrate from 2.4 to another version first ? > > > > > > Philippe > > > ___ > > > users mailing list > > > users@xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > > > -- > > Thomas Mortagne > > ___ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.1.4 released.
The XWiki development team is proud to announce the availability of XWiki Enterprise 4.1.4. This is probably the last bugfix release for the 4.1 series. It provides 30 bug fixes, mainly in the Extension Manager, including important fixes for extensions that provide components or script services (see XCOMMONS-231 andXCOMMONS-232). It also improves the large data migration introduced in 4.0, in particular to support MS-SQL, and fixes an important issue that cause the migration of annotations to be unintentionally skipped. 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/ReleaseNotesXWikiEnterprise414 Thanks -The XWiki dev team ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] xwiki talks with the LDAP server for every page access
Le mercredi 5 septembre 2012, Adrian Fita a écrit :
> Thanks for the suggestion, but it doesn't seem to help. The users in
> my LDAP contain indeed a dot in the uid.
>
> So, I put xwiki.authentication.convertemail=2 in xwiki.conf and
> the authentication failed. I monitored the LDAP communication with the
> "LDAP debugging" settings in
> classes/logback.xml and noticed that the uid that is sent to LDAP
> contains "_" instead of "." (dot).
>
> So using this conf setting, would mean transforming the
> uids in LDAP to a format with underscores ("_") instead of dots ("."),
> which is not possible.
This precisely the purpose of it. And this is what I mean by having some
flexibility with your LDAP.
The issue we have is that the username logged in by the LDAP authentication
differ from the username entered at the prompt. My suggested workaround
until a fix is available is therefore to avoid that discrepancy by
authenticating John_Doe when the user enter John.Doe .
You may use a different field in your LDAP to contain these modified names,
and configure XWiki to use that field to find the User DN. The
authentication may still be done against the same DN. But you need some
tuning and modification in your LDAP anyway.
Hope this helps,
> --
> Fita Adrian
>
>
> On Wed, Sep 5, 2012 at 7:54 PM, Denis Gervalle wrote:
> > Hi,
> >
> > You are probably experiencing the issue describe in XWIKI-3469 (
> > http://jira.xwiki.org/browse/XWIKI-3469).
> > If you have usernames with dots and some flexibility on your LDAP, a
> > partial workaround could to add in xwiki.cfg:
> >
> > xwiki.authentication.convertemail=2
> >
> > This will convert usernames containing dots (and @), into usernames with
> > underscores (John.Doe => John_Doe).
> > Since this cleanup is done earlier, it may improve this issue if user
> > respect their name properly and your ldap is adapted.
> > Regards,
> >
> > On Tue, Sep 4, 2012 at 2:50 PM, Adrian Fita
> wrote:
> >
> >> Hi. I have an Xwiki Enterprise 3.4 installation and I'm studying the
> >> integration with LDAP.
> >>
> >> I managed to configure the authentication, I created the users and
> >> mapped the groups with the LDAP server.
> >>
> >> But I noticed that the performance dropped dramatically when using
> >> LDAP auth, in comparison with local users, specifically it takes
> >> around 10 seconds to access a page (down from <3sec).
> >>
> >> So, I started monitoring the traffic between the xwiki machine and the
> >> LDAP machine with tshark and I noticed that every time I click a link
> >> in xwiki, there is a lot of traffic with LDAP. Is there some way to
> >> improve this behaviour (I really don't understand why xwiki needs to
> >> talk with the LDAP server on every page request...)? I see that this
> >> is not a new issue [1], [2]. I also tried setting
> >> xwiki.authentication.always=0 in xwiki.cfg but I didn't notice any
> >> change (it being set to 0 by default already...). Would upgrading to
> >> the latest stable version improve the situation?
> >>
> >> 1. http://lists.xwiki.org/pipermail/users/2011-April/019745.html
> >> 2. http://jira.xwiki.org/browse/XWIKI-2516
> >>
> >> Thanks for your time.
> >> --
> >> Fita Adrian
> >> ___
> >> users mailing list
> >> users@xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/users
> >>
> >
> >
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > eGuilde sarl - CTO
> > ___
> > users mailing list
> > users@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] xwiki talks with the LDAP server for every page access
Hi, You are probably experiencing the issue describe in XWIKI-3469 ( http://jira.xwiki.org/browse/XWIKI-3469). If you have usernames with dots and some flexibility on your LDAP, a partial workaround could to add in xwiki.cfg: xwiki.authentication.convertemail=2 This will convert usernames containing dots (and @), into usernames with underscores (John.Doe => John_Doe). Since this cleanup is done earlier, it may improve this issue if user respect their name properly and your ldap is adapted. Regards, On Tue, Sep 4, 2012 at 2:50 PM, Adrian Fita wrote: > Hi. I have an Xwiki Enterprise 3.4 installation and I'm studying the > integration with LDAP. > > I managed to configure the authentication, I created the users and > mapped the groups with the LDAP server. > > But I noticed that the performance dropped dramatically when using > LDAP auth, in comparison with local users, specifically it takes > around 10 seconds to access a page (down from <3sec). > > So, I started monitoring the traffic between the xwiki machine and the > LDAP machine with tshark and I noticed that every time I click a link > in xwiki, there is a lot of traffic with LDAP. Is there some way to > improve this behaviour (I really don't understand why xwiki needs to > talk with the LDAP server on every page request...)? I see that this > is not a new issue [1], [2]. I also tried setting > xwiki.authentication.always=0 in xwiki.cfg but I didn't notice any > change (it being set to 0 by default already...). Would upgrading to > the latest stable version improve the situation? > > 1. http://lists.xwiki.org/pipermail/users/2011-April/019745.html > 2. http://jira.xwiki.org/browse/XWIKI-2516 > > Thanks for your time. > -- > Fita Adrian > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Another migration problem (3.5 to 4.1.3)
Just a followup on this one, so anyone falling here knows the outcome.
The related JIRA issues are:
XWIKI-8126: Better error reporting when proper hibernate mapping is not
found during R4XWIKI6990.
XWIKI-8130: copyDocument should not copy the custom mapping of the
document xClass
The NPE exception will be replace by an DataMigrationException with a
message similar to the following in our next releases (4.1.4 and 4.2M3):
Could not migrate IDs for class [XWiki.CopyOfXWikiPreferences] : no
> hibernate mapping found. For example, this error commonly happens if you
> have copied a document defining an internally mapped class (like
> XWiki.XWikiPreferences) and never used the newly created class OR if
> you have forgotten to customize the hibernate mapping while using your own
> internally custom mapped class. In the first and most common case, to fix
> this issue and migrate your wiki, you should delete the offending and
> useless class definition or the whole document defining that class from
> your original wiki before the migration.
The problem encountered by Jeremie is that he have made a copy of
XWiki.XWikiPreferences into a new document XWiki.CopyOfXWikiPreferences.
That new document will contains the preferences in an object of class
XWiki.XWikiPreferences, but it will also define a new class named
XWiki.CopyOfXWikiPreferences which is the copy of the class
XWiki.XWikiPreference. That new class received the same internal mapping
than its original source. However, the hibernate mapping needed is not
available in the hibernate mapping configuration, and that new class is
unusable and cannot be migrated properly. So to fix the issue, you need to
delete that new class definition or remove the document containing that
definition.
In the next release, the copyDocument operation will also not copy the
custom mapping, so that any copied class will not be custom mapped anymore.
Thanks Jeremie for your help.
On Thu, Aug 9, 2012 at 10:11 PM, Denis Gervalle wrote:
> Dear Jeremie,
>
> I am currently looking at your issue. From my current hypothesis, your
> issue is related to dynamically custom mapped classes, a feature that is
> not much know or used. I would be happy to help you more on this issue, but
> I will need more information, that you may not which to provide in public.
> So I invite you to contact me in private, and it would be great to have a
> more interactive communication mean than email.
>
> Regards,
>
>
> On Thu, Aug 9, 2012 at 1:47 PM, jerem wrote:
>
>> Hello,
>>
>> Really no idea about this ? :)
>>
>> Br,
>> Jeremie
>>
>>
>> jerem wrote
>> >
>> > Having found this :
>> >
>> https://github.com/xwiki/xwiki-platform/commit/662163a5bd7f5d21085e41aa9b530df86f87870e
>> ,
>> > ... I tried as indicated to use "safe mode" for this particular
>> migration,
>> > so I added the following to my xwiki.cfg and restarted:
>> > xwiki.store.migration.R4XWIKI6990.safemode=1
>> >
>> > It still fails, though exception stacktrace is slightly different
>> (breaks
>> > on line 1127 instead of 777) :
>> >
>> > Caused by: java.lang.NullPointerException: null
>> > at
>> >
>> com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration.hibernateMigrate(R4XWIKI6990DataMigration.java:1127)
>> > ~[xwiki-platform-legacy-oldcore-4.1.3.jar:na]
>> > at
>> >
>> com.xpn.xwiki.store.migration.hibernate.AbstractHibernateDataMigration.migrate(AbstractHibernateDataMigration.java:109)
>> > ~[xwiki-platform-legacy-oldcore-4.1.3.jar:na]
>> > ... 57 common frames omitted
>> >
>> > (I omitted the rest of the logs that are almost identical)
>> >
>> > In fact it breaks on an identical line but in alternate condition (for
>> > safe mode):
>> >
>> >// Skip classes that will be updated by cascaded updates
>> >if (!this.fkTables.contains(klass.getTable())) {
>> > ...
>> >
>> > Thanks,
>> > Jeremie
>> >
>> >
>> > jerem wrote
>> >>
>> >> Hi guys,
>> >>
>> >> Tried migrating from 3.5 to 4.1.3 on my test instance, and it seems
>> >> I'm stuck ...
>> >> My test wiki is setup as a multi-wiki environment (for workspaces),
>> >> the main db "xwiki" fails to be migrated, though other ones succeed.
>> >>
>> >> I checked other posts about migration issues, and it seems there
>> >> usually are some indicative logs about what sql fails, in my case I
>> >> only get a not nice NPE ...
Re: [xwiki-users] Problem Migrating Database from XWiki Ent 3.5.1 to 4.1.3 for MSSQL
I am adding this follow up, so anyone with an Microsoft SQL server database will get the final outcome of this issue. XWiki devs team does not officially support MS-SQL, however, with the great help provided by Rob, I have been able to add basic support of MS-SQL into the migration R4XWIKI6990. See http://jira.xwiki.org/browse/XWIKI-8125for details. This fix will be released in version 4.1.4 and 4.2M3. This does not change our policy about supported databases, but it will surely help those that have been successful running XWiki on MS-SQL up to now. Many thanks to Rob for its very useful inputs and tests. On Fri, Aug 3, 2012 at 4:19 PM, Denis Gervalle wrote: > Hi, > > At least, you have progressed, you achieved the configuration so that the > migration was tried, but has failed. > > Your diagnosis about what happened seems to me quite right. We drop only > FK constraints, and we do not care about any PK constraints, since our > supported databases are not affected by this. > > Hopelessly, I cannot provide you with the liquibase changelogs, since > these are generated on the fly for R4XWIKI6990, depending on the source > databases. Basically, it does for all FK found > in the hibernate mapping table concerned by the ID changes, then > to BIGINT for those IDs which have to be enlarged, and > finally it back with an onUpdate="CASCADE" > (except for Oracle where it use initiallyDeferred=true). > > The above is probably not helping much. Since MSSQL is unsupported, you > are on a little bit on your own with this, and I could only suggest some > tricky ideas that may absolutely not work. Here is what you may try: > 1) from a fresh DB, launch the migration, it will fail but will have > dropped the FK and it should not try again. This is your current state. You > may check it does not try again by restarting the wiki again, and ensure > that it fails at the same point. > 2) manually drop the PK constraints for all table having such definition > for an IDs that has his datatype changed. Enlarged IDs are all those that > are related to objects, and statistics. > 3) Restart the wiki, it should hopefully go further, and may probably fail > when we try to put FK constraints back. > 4) manually recreate the PK constraints for all drop you have made. > 5) Restart the wiki again, and cross fingers ! If you are lucky, it will > terminate liquibase updates, and start the data migration. > > Once again, these are only suggestions, and your chances for success > are honestly quite low. Anyway, please let me know the outcome. If it does > not work and you are willing to collaborate and could provide needed inputs > and testing supports, I will try to find some time to work with you on > improving our migration procedure. Contact me in private regarding this > last point. > > Regards, > > On Fri, Aug 3, 2012 at 3:31 PM, rheim651 wrote: > >> Okay, here is an Update: Using the xwiki.cfg file I posted to pastebin, I >> modified >> xwiki.store.migration=1 >> >> After restarting the server I am still getting the exact same error >> message >> in the browser. >> >> Looking at the DATABASECHANGELOG from inside the target database, the >> Liquibase executions get as far as removing the Foreign Keys. It seems >> to >> fail when attempting to change the datatype on the Primary Key for >> xwikiobjects. >> >> In the stdout file I am now seeing the following liquibase error when >> attempting to change the datatype on the Primary Key for xwikiobjects to >> BIGINT. >> >> 2012-08-03 08:21:00,691 [http://10.43.30.38:9080/xwiki/bin/view/Main/] >> ERROR >> c.x.x.s.m.liquibase- Change Set >> liquibase.xml::R4-009::dgervalle failed. Error: Error executing SQL >> ALTER TABLE [dbo].[xwikiobjects] ALTER COLUMN [XWO_ID] BIGINT: The object >> 'PK__xwikiobj__6F7E67F86383C8BA' is dependent on column 'XWO_ID'. >> >> I believe the reason for this error is that on SQL Server the Primary Key >> constraint should to be dropped first before you can change the datatype. >> (At least that's what I found in my script testing). >> >> Would it be possible to see the liquibase changelogs for this migration? >> I'm not sure where in the package this information is stored. >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://xwiki.475771.n2.nabble.com/Problem-Migrating-Database-from-XWiki-Ent-3-5-1-to-4-1-3-for-MSSQL-tp7580579p7580704.html >> Sent from the XWiki- Users mailing list archive at Nabble.com. >> ___ >> users mailing list >> users@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Another migration problem (3.5 to 4.1.3)
at com.xpn.xwiki.XWiki.getXWikiPreference(XWiki.java:2215) > >> [xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at com.xpn.xwiki.XWiki.getXWikiPreference(XWiki.java:2247) > >> [xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at > >> > com.xpn.xwiki.render.XWikiMacrosMappingRenderer.loadPreferences(XWikiMacrosMappingRenderer.java:107) > >> [xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at > >> > com.xpn.xwiki.render.XWikiMacrosMappingRenderer.(XWikiMacrosMappingRenderer.java:83) > >> [xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at > >> > com.xpn.xwiki.render.DefaultXWikiRenderingEngine.(DefaultXWikiRenderingEngine.java:72) > >> [xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at com.xpn.xwiki.XWiki.resetRenderingEngine(XWiki.java:1114) > >> [xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:790) > >> [xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> [ ... some lines excluded ... ] > >> Caused by: java.lang.NullPointerException: null > >> at > >> > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration.getAllTableToProcess(R4XWIKI6990DataMigration.java:777) > >> ~[xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at > >> > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration.getAllTableToProcess(R4XWIKI6990DataMigration.java:761) > >> ~[xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at > >> > com.xpn.xwiki.store.migration.hibernate.R4XWIKI6990DataMigration.hibernateMigrate(R4XWIKI6990DataMigration.java:1066) > >> ~[xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> at > >> > com.xpn.xwiki.store.migration.hibernate.AbstractHibernateDataMigration.migrate(AbstractHibernateDataMigration.java:109) > >> ~[xwiki-platform-legacy-oldcore-4.1.3.jar:na] > >> ... 57 common frames omitted > >> > >> > >> Thanks for help ! > >> > >> Jeremie > >> ___ > >> users mailing list > >> users@ > >> http://lists.xwiki.org/mailman/listinfo/users > >> > > > > > > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Another-migration-problem-3-5-to-4-1-3-tp7580726p7580809.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Problem Migrating Database from XWiki Ent 3.5.1 to 4.1.3 for MSSQL
Hi, At least, you have progressed, you achieved the configuration so that the migration was tried, but has failed. Your diagnosis about what happened seems to me quite right. We drop only FK constraints, and we do not care about any PK constraints, since our supported databases are not affected by this. Hopelessly, I cannot provide you with the liquibase changelogs, since these are generated on the fly for R4XWIKI6990, depending on the source databases. Basically, it does for all FK found in the hibernate mapping table concerned by the ID changes, then to BIGINT for those IDs which have to be enlarged, and finally it back with an onUpdate="CASCADE" (except for Oracle where it use initiallyDeferred=true). The above is probably not helping much. Since MSSQL is unsupported, you are on a little bit on your own with this, and I could only suggest some tricky ideas that may absolutely not work. Here is what you may try: 1) from a fresh DB, launch the migration, it will fail but will have dropped the FK and it should not try again. This is your current state. You may check it does not try again by restarting the wiki again, and ensure that it fails at the same point. 2) manually drop the PK constraints for all table having such definition for an IDs that has his datatype changed. Enlarged IDs are all those that are related to objects, and statistics. 3) Restart the wiki, it should hopefully go further, and may probably fail when we try to put FK constraints back. 4) manually recreate the PK constraints for all drop you have made. 5) Restart the wiki again, and cross fingers ! If you are lucky, it will terminate liquibase updates, and start the data migration. Once again, these are only suggestions, and your chances for success are honestly quite low. Anyway, please let me know the outcome. If it does not work and you are willing to collaborate and could provide needed inputs and testing supports, I will try to find some time to work with you on improving our migration procedure. Contact me in private regarding this last point. Regards, On Fri, Aug 3, 2012 at 3:31 PM, rheim651 wrote: > Okay, here is an Update: Using the xwiki.cfg file I posted to pastebin, I > modified > xwiki.store.migration=1 > > After restarting the server I am still getting the exact same error message > in the browser. > > Looking at the DATABASECHANGELOG from inside the target database, the > Liquibase executions get as far as removing the Foreign Keys. It seems to > fail when attempting to change the datatype on the Primary Key for > xwikiobjects. > > In the stdout file I am now seeing the following liquibase error when > attempting to change the datatype on the Primary Key for xwikiobjects to > BIGINT. > > 2012-08-03 08:21:00,691 [http://10.43.30.38:9080/xwiki/bin/view/Main/] > ERROR > c.x.x.s.m.liquibase- Change Set > liquibase.xml::R4-009::dgervalle failed. Error: Error executing SQL > ALTER TABLE [dbo].[xwikiobjects] ALTER COLUMN [XWO_ID] BIGINT: The object > 'PK__xwikiobj__6F7E67F86383C8BA' is dependent on column 'XWO_ID'. > > I believe the reason for this error is that on SQL Server the Primary Key > constraint should to be dropped first before you can change the datatype. > (At least that's what I found in my script testing). > > Would it be possible to see the liquibase changelogs for this migration? > I'm not sure where in the package this information is stored. > > > > > > > > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Problem-Migrating-Database-from-XWiki-Ent-3-5-1-to-4-1-3-for-MSSQL-tp7580579p7580704.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Problem Migrating Database from XWiki Ent 3.5.1 to 4.1.3 for MSSQL
Hi, You do not need to enable additional logging if you are using our default configuration. If currently you do not get an info logging saying "Running storage schema updates and migrations" at some point, and your database is declared "Database XXX needs migration(s), it could not be safely used!", it simply means that you have not enable migration. Migration are disabled by default, and, in our distributions, we active them initially by having the following line uncommented in xwiki.cfg: xwiki.store.migration=1 Reading the xwiki.cfg you have pasted, I do not see that one, so you have to add it back. Apart from that, you just need that the store and migration components are properly setup, which is the default, and the subject of my previous message. Regarding schema changes, you are right, all changes concern the size of IDs in many tables (the changes depends on the source DB), to afford a 64bits number for all documents and objects IDs. If you compare the hibernate mapping, this is what you will see. But, on an existing database, you need a migration procedure that will alter the existing ID columns to change their type. To do so, most DB engines will also require that no contraints are exists on these columns, so we potentially need to remove them first and recreate them later. And the last but not the least, we also migrate all IDs to use the new size and scheme, which will ensure better unique identification, our goal in this operation. On Thu, Aug 2, 2012 at 10:17 PM, rheim651 wrote: > Denis, > > I have reviewed my xwiki.cfg file and revised it according to what you > requested ( http://pastebin.com/ACFyDT87 Xwiki Cfg ) > > Unfortunately, I still get the same error. > > Is there a way to enable additional logging to try and determine where it > is > failiing on the migration? If I need to manually adjust some things on the > database side I'm fine with that. > > As it stands, right now I'm also attempting to reverse-engineer the > database > schema changes between 3.5 and 4.1.3. Initially it looks like it's > converting Primary Keys on 20 tables to use NUMERIC(19,0) instead of INT. > Are there any other schema changes besides that I should also be aware of? > > > Denis Gervalle-2 wrote > > > > Hi, > > > > I have written most of the migration manager stuffs and the major > > migration > > of 4.x, and from what I see, your configuration currently prevent any > > migrations to be executed. You should carefully investigate your > xwiki.cfg > > file for migration configuration. > > From what you copy paste, I see twice the > > "xwiki.store.migration.databases" > > parameters, I suggest you remove both, the default being "all" now. Also > > check there is no "xwiki.store.hibernate.updateschema", the default is > > good. Also check that you do not have any "xwiki.store.migration=0". > > Finally, "xwiki.store.main.hint" should not be defined or be "hibernate", > > and the same is true for "xwiki.store.versioning.hint", > > "xwiki.store.recyclebin.hint" and "xwiki.store.migration.manager.hint". > If > > you do not find the issue, please send me your xwiki.cfg, and I will have > > a > > look at it. > > > > Finally, I should bring your attention to the fact that MSSQL is not > > officially supported and that the migration has never been tested on that > > DBMS. However, we have done our best so it is as database agnostic as > > possible. It may simply work or not. Do not hesitate to share your > > experience, I will do my best to help, but I cannot promise success. > > > > Regards, > > > > > > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Problem-Migrating-Database-from-XWiki-Ent-3-5-1-to-4-1-3-for-MSSQL-tp7580579p7580699.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Possible upgrade 3.5.1 to 4.0 issue
age? > You cannot and you need not. This usually happen on MySQL database that have been migrated from MyISAM engine to InnoDB engine. It only means that dropping a constraint has failed, but if the constraint were not present, this was not really an issue. These were blocking you in your initial thread, and have been transformed in warning the latest release. Unless you get other errors during migration due to the constraint being there and not being properly dropped, this is not an issue in itself. So you should really not care and be confident here. I have check your logs, and it shows that the migration has been properly applied. Moreover, the missing constraints had been added back and therefore the state of your database has been improved. > > > > 4. And finally there's a bunch of deprecated methods used in the end: > > method [com.xpn.xwiki.api.Util.parseInt] in unknown namespace@68,26 > > getter [com.xpn.xwiki.api.Util.getArrayList] in unknown namespace@788,35 > > method [com.xpn.xwiki.api.Util.parseInt] in unknown namespace@68,26 > > getter [com.xpn.xwiki.api.Util.getArrayList] in unknown namespace@788,35 > > Can they be fixed? > > > > 5. Also one more question: after this serious migration, is there a way > > to > > find out that my database and application has a valid state? (I mean some > > other way than just start using and find an error after 2-3 weeks of > adding > > pages, to find out that it wont be able to either downgrade or fix the > > issue) > You may use the sanity check script available at http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Database+Administrationor the Admin Tools Application in version 3.0 or later at http://extensions.xwiki.org/xwiki/bin/view/Extension/Admin+Tools+Application . Both will execute the same sanity checks. Please note that inconsistencies being there before the migration will still be there after the migration. So it is good to check the database before migration and after migration, and it should not reveal an increase of the inconsistencies. This is really a good check that ensure the database consistency has not been affected. Regards, > > > > > > [1] Full upgrade logs attached: > > http://xwiki.475771.n2.nabble.com/file/n7580357/db-migration.log > > db-migration.log< > http://xwiki.475771.n2.nabble.com/file/n7580357/db-migration.log%0Adb-migration.log > > > > > > -- > > View this message in context: > > > http://xwiki.475771.n2.nabble.com/Possible-upgrade-3-5-1-to-4-0-issue-tp7528896p7580357.html > > Sent from the XWiki- Users mailing list archive at Nabble.com. > > ___ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Problem Migrating Database from XWiki Ent 3.5.1 to 4.1.3 for MSSQL
Hi, I have written most of the migration manager stuffs and the major migration of 4.x, and from what I see, your configuration currently prevent any migrations to be executed. You should carefully investigate your xwiki.cfg file for migration configuration. >From what you copy paste, I see twice the "xwiki.store.migration.databases" parameters, I suggest you remove both, the default being "all" now. Also check there is no "xwiki.store.hibernate.updateschema", the default is good. Also check that you do not have any "xwiki.store.migration=0". Finally, "xwiki.store.main.hint" should not be defined or be "hibernate", and the same is true for "xwiki.store.versioning.hint", "xwiki.store.recyclebin.hint" and "xwiki.store.migration.manager.hint". If you do not find the issue, please send me your xwiki.cfg, and I will have a look at it. Finally, I should bring your attention to the fact that MSSQL is not officially supported and that the migration has never been tested on that DBMS. However, we have done our best so it is as database agnostic as possible. It may simply work or not. Do not hesitate to share your experience, I will do my best to help, but I cannot promise success. Regards, On Thu, Aug 2, 2012 at 5:21 PM, rheim651 wrote: > Here are URLs for some (hopefully) relevant: > > http://pastebin.com/GiVs68L9 stdout Log > http://pastebin.com/dXJqZyhh Catalina Output > http://pastebin.com/U4VaVTQw Browser Stack Trace > > For some additional background, I tried creating an empty database and that > appears to work fine with this exact same configuration. > > I believe I may know what at least part of the problem is. In order to get > to Compatibility Mode 100, I had to remove some deprecated datatypes. This > was basically replacing TEXT datatypes with VARCHAR(MAX). The full list of > the changes can be found here. > > http://pastebin.com/3C33nxYq SQL Server - Deprecated Datatype Changes > > > > > > > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Problem-Migrating-Database-from-XWiki-Ent-3-5-1-to-4-1-3-for-MSSQL-tp7580579p7580695.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Failed to migrate database from release 3.4 to 4.1.2
Hi Nicolas, We have detected some issues regarding the migration of statistics tables in all 4.x version. We are working hard on fixing these for 4.1.3 which we expect to release quickly. If you do not care about statistics, you may empty stats tables, and the migration should run fine. Else, you need to wait for 4.1.3. Sorry for the inconvenience. On Wed, Jun 27, 2012 at 3:31 PM, CHENEAU-GREHALLE Nicolas < nicolas.cheneau-greha...@sesam-vitale.fr> wrote: > Hi, > > > > I try to install the release 4.1.2 on 3.4. > > During the database migration, there is this error message : > > > > 2012/06/27 13:26:54 [http://172.24.1.135:8080/xem/bin/view/Main/] INFO > c.x.x.s.m.h.R4XWIKI6990DataMigration - [R4XWIKI6990] - > Converting 12568 document statistics IDs in 1 tables and 0 collection > tables... > > 2012/06/27 13:26:58 [http://172.24.1.135:8080/xem/bin/view/Main/] WARN > o.h.util.JDBCExceptionReporter - SQL Error: 1062, SQLState: 23000 > > 2012/06/27 13:26:58 [http://172.24.1.135:8080/xem/bin/view/Main/] ERROR > o.h.util.JDBCExceptionReporter - Duplicate entry '-5487128615380216001' > for key 1 > > 2012/06/27 13:26:58 [http://172.24.1.135:8080/xem/bin/view/Main/] INFO > c.x.x.s.m.h.HibernateDataMigrationManager - Failed to migrate database > [xwiki]... > > com.xpn.xwiki.store.migration.DataMigrationException: Data migration > R4XWIKI6990 failed > > > > Somebody could help me about this message ? > > Even in debug mode, I don't have any information about this duplicate > entry (which table ? which column ?) > > > > Thank you for any help. > > > > Nicolas > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 3.3 Milestone 2 Released
Hi Eugen, The file you are looking for is http://download.forge.objectweb.org/xwiki/xwiki-enterprise-ui-all-3.3-milestone-2.xar There is an issue on our download page, Sergiu could you have a look at this, the naming as changed and the page is automated. Denis On Fri, Nov 25, 2011 at 19:01, Eugen Colesnicov wrote: > Broken link for xar-file. > > http://download.forge.objectweb.org/xwiki/xwiki-enterprise-wiki-3.3-milestone-2.xar > - give: "Not Found. > The requested URL /xwiki/xwiki-enterprise-wiki-3.3-milestone-2.xar was not > found on this server." > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Announcement-XWiki-Enterprise-and-XWiki-Enterprise-Manager-3-3-Milestone-2-Released-tp7027420p7031981.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Selective Export UI
For my comments, I use your convention, to avoid speaking about screen or part of screen (A) is the Search/Browse/Select pages functionality (B) is the See/Manage selected/saved pages functionality (C) is the Adjust Export Options functionality On Thu, Jun 24, 2010 at 23:33, Ecaterina Valica wrote: > On Tue, Jun 22, 2010 at 14:32, Denis Gervalle wrote: > > > Hi Caty, > > > > I really apologize in advance for looking at this so late and also for my > > upcoming comments do not feel hurt please, but I do not feel that > this > > interface will provide the nice export functionality we expect. > > > > First, here is a resume of my main remarks: > > > > - You need a big, large screen to see it properly, and at the same time, > > everything is small and concentrate. > > - There are too many choices at the same time, and this cause a real > > excess > > of complexity > > - Navigation in the list of document, and filtering, are absolutely > > different to what the user is accustomed to with LiveTable > > - Scalability issue increase the complexity in the document list, > > and choice of export format will not scale easily > > - Some export options (in the format box) change the list of document > that > > will be exported after your initial choice > > > > Let me now review this in more details. > > > > 1) Screen size and complexity > > > > Putting together the 3 parts of this interface (full list, selected list > > and > > export options) make it complex and cluttered. > > IMO, there isn't several way to solve this. Each part should be in a > > separate screen. This will both decrease complexity, and allow more > > flexibility for composing each screen. > > These screens could than be linked > > together in a wizard like interface (Back/Next), and a direct access > could > > also be provided using tabs or similar control. These tabs should also > show > > the normal path of actions. > > > > I don't agree having separate screens. The pattern for this case is > Collected Selection: when you want to collect items in one place from > multiple pages / sources / searches. You should be able to change your mind > (delete, reselect) about a selected page, without the need to go back and > forth across wizard pages. Do you means that the way most eCommerce site works using a cart is so bad ? Moreover, from my understanding, deselection is available with (A). The main difference is that (A) is a filtered view over the whole wiki and (B) is a potentially filtered view over the upcoming package with some ordering features. For me (A) and (B) provide 2 really distinct functionality, this is why I have not merged them in a single table, but if (A) and (B) were only a selection feature, a single table would have been sufficient. > Also you can't see all the already selected pages > in the "Select documents for export" (search), because you can always > change > that view state (make another search, go into tree view, etc). So separate > screens would be disturbing my flow, relying on my memory in order to know > what I've selected Even if I can agree to some point for small package, you will always have to rely a little on your mind, since displaying the whole package content will not be always possible. Note that screen are not pages, and switching is fast. Apart from the complexity aspects, you should really consider that not every one has a 26" screen, and that all skins will not always allow such large display. During (A), you have also information displayed (B), so I do not really feel the need to have both together. > So "Select documents for export" and "Selected Pages / Package Content" > need > to stay together, in order for the actions (select/remove) to be natural > and > the user to feel in control about his selection. > The user can have more paths of completion: > 1) (A) Search/Browse/Select pages -> (B) See/Manage selected/saved pages -> > (C) Adjust Export Options -> (D) Export > 2) (B) See/Manage saved > pages -> (C) Adjust Export Options -> (D) Export > 3) (B) See/Manage saved > pages ->-> (D) Export > (rely on defaults) > > Export Options should be placed somewhere near the "Selected Pages", > because > they are part of the export process, but it's not mandatory to be on the > same level. > I agree on that point, since (B) may have some ordering feature depending on the format, this implies knowing the fo
Re: [xwiki-users] [xwiki-devs] [VOTE] [wysiwyg] Displaying the macro id and searching for it in the wysiwyg insert macro wizard
+1 for (1), it could not really hurt and +1 for (2) in tooltips but close to (-1) for (2) displayed in small since I agree with Marius Denis On Wed, Jun 23, 2010 at 14:44, Anca Luca wrote: > Hi all, > > I wanted to insert a macro in a page using the wysiwyg and I noticed > that the macros filter (search box on top right) is not searching in the > macro ids. > > For example, if I try to write "toc" I get no results. If I write > "table" I get the "Table of contents" macro as result, since its name > matches. I found this a bit annoying in my case, since i know the > macroid (if I were to write it in the wiki syntax) and I cannot find the > macro (still, I'm using the wysiwyg because I can never remember macro > params). Also, I use the search function because it's far easier to > filter it out then scroll for it in the list. > > WDYT about searching in the macro ids as well? (1) > > Also, the macro id is not displayed. This is good for simple users for > which it has no meaning, but there can be a situation when 2 macros have > the same name and same description (e.g. void description) and users > would want to be able to differentiate one from the other in the macros > list, even the simple users, I would say (for example because they > always want to use one macro of the 2 and they can never tell one from > the other only by name). > > WDYT about displaying the macro is as well? (2) of course pretty small > and greyed out, like some advanced metadata. > > Marius said it's no big deal to implement neither, as long as we agree. > > My +1 for both (1) and (2). > > Thanks, > Anca > > > > ___ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Selective Export UI
describe above, we may have several expanding box (a "small" lightbox), that shows: - the list of direct children of the page/space - the list of all children of the page taken recursively - the list of linked page from the page - the list of all linked page from the page taken recursively These boxes will display a similar list to the current one (without further expanding boxes), allowing review/selection of additional pages Well, there is probably many adjustment that could be needed on the way to this interface, and I hope my remarks will be the source of inspiration for an even better solution. Thanks to those who have read me, this is a little bit long... I know. Denis On Mon, Jun 21, 2010 at 21:55, Ecaterina Valica wrote: > Hi, > > I've made Selective Export Proposal 2 (HTML + CSS) > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExport2Proposal > > This proposal follows more closely existing features from MultiPageExport > application, like: > + Search by title/name/space/tags > + Ordering in the export list (important for HTML and PDF) > > *Improvements* from Proposal 1 ( > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal > ): > > - separation of "Saved Packages" in another top tab > - Added: "▾more ( 18 / 56 results )" when more pages/spaces are displayed > - Added: "reset to defaults" to export options values > - Combined "Package Content" and "Export Options" under "Export documents > as > package" > - Changed "Export" button position to top > - Added deletion for saved packages + saving date > > Also, this proposal has 3 modes for pages relationship visualization: > Space/Page Tree, Parent/Child Tree, List View > > Currently MultiPageExport application and XWiki WYSIWYG Search feature uses > "List View" (page title + location) mode to display information. This > should > be the default mode to display information: less cryptic, with search you > could find information that you don't know the location. Also the ordering > (moveUp/moveDown) is more natural for HTML/PDF/RTF export, because entries > are independent. > > http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/3.png > > IMO, for export applications (XAR) "List View" is less usable and the the > perfect candidate is "Space/Page Tree" view. > > http://localhost:8080/xwiki/bin/download/Improvements/MultiExport2Proposal/8.png > > Advanced users that will need "Space/Page Tree" or "Parent/Child Tree" will > have to manually changed the display view and/or the export options, the > others will relay on defaults. > > WDYT? > > Caty > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Documentation Standard Document & Call to Vote
On Fri, Jun 11, 2010 at 12:25, Vincent Massol wrote: > > On Jun 11, 2010, at 12:21 PM, Thomas Mortagne wrote: > > > On Fri, Jun 11, 2010 at 12:16, Vincent Massol > wrote: > >> > >> On Jun 11, 2010, at 12:00 PM, Thomas Mortagne wrote: > >> > >>> On Fri, Jun 11, 2010 at 11:39, Vincent Massol > wrote: > >>>> > >>>> On Jun 11, 2010, at 11:25 AM, Thomas Mortagne wrote: > >>>> > >>>>> On Fri, Jun 11, 2010 at 11:10, Vincent Massol > wrote: > >>>>>> > >>>>>> On Jun 10, 2010, at 9:21 AM, Denis Gervalle wrote: > >>>>>> > >>>>>>> On Mon, Jun 7, 2010 at 11:55, Sorin Burjan > wrote: > >>>>>>> > >>>>>>>> Hello. > >>>>>>>> > >>>>>>>> Silvia and me have created a DRAFT for XWiki.org Documentation > Standard > >>>>>>>> found at : > >>>>>>>> > http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiOrgDocumentationStandard > >>>>>>> > >>>>>>> > >>>>>>> Even if I found your procedures smart and very conscientious, I am > a little > >>>>>>> bit afraid by them, and just wonder if these will not finally slow > down the > >>>>>>> documentation, since only very minor change can be done quickly. As > everyone > >>>>>>> knows, documentation is never what we d'like to do, and if you > increase the > >>>>>>> burden, it will probably not encourage improvements. > >>>>>> > >>>>>> I haven't read the proposal yet, just answering to this part. > >>>>>> > >>>>>> Yes but we want a good quality for the documentation same as we want > a good quality for the code. What we did for the code is prevent anyone > modifying it by adding a notion of committer and people can still contribute > patches which are then reviewed by committers. Committers agree with the > rules for ensuring quality. > >>>>>> > >>>>>> The best solution IMO for having quality docs is to: > >>>>>> - close xwiki.org so that it's editable only to committers and > people voted as wiki editors (we need a process to get casual readers into > wiki editors) > >>>>>> - leave annotations/comments for people wanting to contribute small > stuff > >>>>> > >>>>> What would be great would be some kind of patch annotation a > xwiki.org > >>>>> editor would just need to apply it by clicking on a button. > >>>>> > >>>>>> - allow anyone to access the Draft space > >>>>>> - make it very visible and easy how to contribute to xwiki.org (ie > being selected to be in the wiki editors group) > >>>>> > >>>>> We could also have the notion of "validated version", anyone can > >>>>> modify the document but a xwiki.org editor can validate a version. > By > >>>>> default you view the last validated version but you can also see the > >>>>> last version if some modification has been made. > >>>> > >>>> Sure but you're already talking about the next step which requires > tooling and is more complex to set up. I'd prefer to see step 1 done quickly > and then someone could work to do step2 as you mention. I've had this idea > about "validate version" since 2006 but it's still not there since someone > needs the time to implement it ;) > >>> > >>> Step1 seems very anti wiki to me. Having to close that much our public > >>> wiki is not making it a good wiki example where we are saying to all > >>> clients that "wiki is great it makes everyone participate"... > >> > >> Our code is also very anti wiki and it's code for a wiki... :) > >> Also a wiki doesn't mean it's open to everyone. It means it easy to > collaborate together *for people who have access to the wiki* of course ;) > >> > >> Now I agree with you it would be better to find a better solution such > as the one you proposed but between not doing anything and not improving our > documentation and improving our documentation practices I prefer to choose > the "improving our documentation practices" by far. > > > > I don't see why it's everything or noth
Re: [xwiki-users] [xwiki-devs] [Vote][Proposal] Rights Management
On Thu, Jun 10, 2010 at 18:15, Jerome Velociter wrote: > Hi Caty, all, > > It took me some time and thinking to figure out how the UI works and what > the yellow highlight means. I'm not sure we reduced complexity, which was > one of the objective of the UI redesign. If this is basic, I imagine the > advanced UI will be pretty scary :) > The advanced UI is there already, have you miss it ? This is what you could see when you click the advanced button on a row. The advanced button at the top is to expand all rows at once. I am a little bit disappointed by your experience. From all the previous proposal, this one as been chosen for their ease of use, and its similarity with the current interface, which will easy transition. Obviously, between this prototype and the final result, you should have a better feeling since all interaction will be in. Regarding the yellow background, I think that their should be two different colors: one for the row background on hover and one for the background of what has been changed without being saved. > Once you understand it, the UI makes sense. The visual clue that > specifiying a right to evalica forbid the same right for all group and guest > is very good. > > Note: I have not followed the thread about this UI redesign (my look at it > is "fresh", for what it worth). > Maybe you should have a look at previous proposal, but I fear you will found them even more complex. The main problem is that XWiki rights are complex by nature. We should rethink that for 3.0. Denis > > Jerome. > > > - "Ecaterina Valica" wrote: > > > Hi, > > > > For a while we've been discussing how the new Rights Management UI is > > gonna > > look like. After 5 prototype versions, we may have reached a > > conclusion. > > > > Please take a look at: > > *Prototype* > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > > *Explanations* > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RightsProposal > > > > Please cast your vote if this is gonna be the final Rights > > representation, > > so that we may start the implementation. > > my +1 > > Any feedback is welcomed and we can still added improvements to this > > version. > > > > The current version is a collaborative work done by me, Denis > > Gervalle, > > Raluca Stavro, Alex Busenius, Roman Muntyanu and many others > > (Guillaume, > > Sergiu, Vincent, Thomas). Thanks everyone for participating in the > > process. > > > > Thanks, > > Caty > > > > p.s: former discussion about mocking process can be seen at > > [Proposal] > > Rights Management UI http://markmail.org/thread/zgzufskvhe6xt6ey > > ___ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > ___ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [Vote][Proposal] Rights Management
On Thu, Jun 10, 2010 at 17:47, coldserenity wrote: > > +1 Looks very nice! Now it's really easy to see where each particular > permission/denial comes from (feature I was missing in the beginning of my > experience with XWiki) and manage it. > > I do have a question though. > As I understood from the proposal description, by default rights table > lists > all groups available in the system. > And if rights should be overridden for specific user, it's being added with > "add user" lookup. Correct? > No, adding user or group is the same process. The interface only display rights that applies currently. > > The question is: was there an aim to allow displaying ALL of the rights > that > are applied to ALL users/groups at current moment. And in particular what > if > user is not assigned to any group, where do the rights come from? is this > screen meant to display such information? > Yes it does, and I suppose that Unregistered Users (XWiki.XWikiGuest) and Registered Users (XWiki.XWikiAllGroup) should always be shown since it cover the whole list of user at all time. Denis > > Regards, > Roman > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/Vote-Proposal-Rights-Management-tp5163401p5163855.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Vote][Proposal] Rights Management
Obviously, you have my +1 ! Please note, that if this proposal is adopted, IMO more polishing will be needed during implementation to improve readability of icons and menus. Denis On Thu, Jun 10, 2010 at 16:09, Ecaterina Valica wrote: > Hi, > > For a while we've been discussing how the new Rights Management UI is gonna > look like. After 5 prototype versions, we may have reached a conclusion. > > Please take a look at: > *Prototype* > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > *Explanations* > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RightsProposal > > Please cast your vote if this is gonna be the final Rights representation, > so that we may start the implementation. > my +1 > Any feedback is welcomed and we can still added improvements to this > version. > > The current version is a collaborative work done by me, Denis Gervalle, > Raluca Stavro, Alex Busenius, Roman Muntyanu and many others (Guillaume, > Sergiu, Vincent, Thomas). Thanks everyone for participating in the process. > > Thanks, > Caty > > p.s: former discussion about mocking process can be seen at [Proposal] > Rights Management UI http://markmail.org/thread/zgzufskvhe6xt6ey > ___ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Documentation Standard Document & Call to Vote
On Mon, Jun 7, 2010 at 11:55, Sorin Burjan wrote: > Hello. > > Silvia and me have created a DRAFT for XWiki.org Documentation Standard > found at : > http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiOrgDocumentationStandard Even if I found your procedures smart and very conscientious, I am a little bit afraid by them, and just wonder if these will not finally slow down the documentation, since only very minor change can be done quickly. As everyone knows, documentation is never what we d'like to do, and if you increase the burden, it will probably not encourage improvements. My idea is that there should be an additional intermediate editing situation, where you improve or add a section in the current documentation directly without going to a draft and review cycle (almost like when you fix a issue without vote when you know what to do). You could also add precision when you read the documentation and have failed to catch it, to avoid the next one to also have the same trouble. I have the impression that we loose the wiki nature of the collaboration by using these procedures ... and this could be a larger reflexion on the feature of XWiki since such situation is not uncommon. I have already some idea about that, but I had never have time enough to write them in details. Briefly, IMO we should offer a feature that allows a document to have its current version not the latest one, until the author of the latest version confirm his desire to publish their changes. As you said, we never want to see unbacked bread, and this is why, in some situation, direct publication is not appropriate. I will not say more here since this is clearly another thread > > > In order to move towards the final version, we need your input on 2 issues. > - For which project version we create & maintain documentation > - Which skins we are going to support in the documentation (latest/all) > > Although, these issues were discussed in December 2009, no final result > came out of them. > > http://markmail.org/message/ou7hgdiiwgayghku#query:+page:1+mid:ou7hgdiiwgayghku+state:results > > > 1. the project version (XE version for ex) for which the documentation > is created/updated/maintained. >We have several choices: > a) We make the documentation only for the latest version. > b) We make the documentation only for the latest version, and we > export the pages at release time and make it available as a zipped HTML > export so that people using the older version can refer to them. > c) We make the doc work the last 2 releases. That would be 2.3 and > 2.4. > > Note: If option b) is chosen then we need to add a step to the > release process. (export for every release) > For me b) is not an option, documentation is not written / updated on release day, but before it, when the features are released in the Mx and RCx versions. Since we start Mx of next release before release of previous one, we cannot managed such versioning easily. For now, to stay reasonable, I think we should do as we do in source code, and mention the version were a feature is introduced or changed when confusion should be avoided. > 2. The skin used for documenting steps. This also includes the screenshots. >Again we have several choices: > a) Document only for the latest default skin. > b) Document for all supported skins. Right now that would be Toucan > + Colibri (not sure about Albatross, I don't think we've officially said > it wasn't supported). > > Note: If option b) is chosen, this would mean 2 screenshots for the > same feature (one for each skin) > I doubt we could do b), reaching a correct a) is already an issue when the default skin is upgraded. Denis > The vote content was mostly taken from the markmail link above. > > > If you have any other suggestions regarding this draft, please reply and > state your opinion. We need as much feedback as possible in order to > create a solid documentation standard. > > ___ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
This is better, but the tooltips stay while the menu is open. (I have check Safari not FF) On Wed, Jun 9, 2010 at 19:11, Ecaterina Valica wrote: > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > > Thanks Raluca. Tomorrow I will send the mail with the proposal, after I > make > some changes Sergiu suggested. > By the way, I think after reviewing Raluca improvements that the "Advanced:" title is not require, and just eat up some useful space. If you agree, I propose to have it removed. Denis > > Caty > ___ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Tue, Jun 8, 2010 at 15:41, Ecaterina Valica wrote: > On Tue, Jun 8, 2010 at 13:46, Denis Gervalle wrote: > > > On Tue, Jun 8, 2010 at 11:19, Ecaterina Valica > wrote: > > > > > On Tue, Jun 8, 2010 at 09:01, Denis Gervalle wrote: > > > > > > > On Mon, Jun 7, 2010 at 17:00, Ecaterina Valica > > > wrote: > > > > > > > > > > It will if it display the inheritance source in a column. For > right > > > set > > > > > at > > > > > > current level this column could even precise what inheritance has > > > been > > > > > > overwritten, both in terms of allowance and origin. > > > > > > > > > > > > Denis. > > > > > > > > > > > > > > > Hi Denis, > > > > > > > > > > "Something" like this: > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > > > > > > > > > > > > > > > Yes, "something" like that. I would have expected a "back to basic" > > > button > > > > in place of "advanced, and the removal of the basic interface to > avoid > > > > duplicating basic rights. Maybe the menu should be horizontal in the > > > > advanced interface, I do not know. Also add some hyperlinks to upper > > > level > > > > in the column explaining inheritance. And put the highlight of > changes > > > over > > > > the rest of the row (includes name and inheritance) > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > > > > > > About: > > > > > > > I would have expected a "back to basic" button > > > > in place of "advanced, and the removal of the basic interface to > avoid > > > > duplicating basic rights > > > > > > > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/rights52Space.png > > > > > > This removal of the basic interface will be set from the user profile's > > > variables (if it has advanced type)? > > > > > > No, just removed when the advanced interface is shown using the advanced > > button, like you have done. > > > > > > > I mean if the user is advanced, all the > > > rows will be presented in advances? > > > > > > > No, the only thing I proposed is that user that are not set "Advanced > user" > > in their profile, will not be presented the advanced interface link, and > > will never see extended rights. > > > > > > > I'm asking because I think the collapsed view is great to see changes > up > > in > > > the table, where you don't care the advanced status of those rights. > > > > > > > I completely agree. Advanced interface is for understanding and fixing > deep > > complex stuffs > > > > > > > > > > > > > > WDYT ? Is this interesting ? > > > > > > > > > > it's nice :P I would love to see some other opinions. > > > > > > > Yes, could it be possible for you to fix the interactive version to hide > > the > > basics and also to have hover and click work as expected. I think it will > > helps in receiving more feed back with causing confusion. > > > > > Raluca offered to help me fix the interaction. > > > > I found the result really well suited now. There is just some improvement > > in > > color contrast, icons aspect, and so on that should be applied if we get > > approval for this proposal. > > > > Once you have fixed the sample, I think that a summary page (resume of > our > > reflexion, and containing only the final proposal) and than a vote thread > > could be appropriate to receive feedback from other committers, since the > > size of this thread could be pushing back. > > > > Yes, a summary+vote is needed. > > I made a version with pagination and filters added. > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > > PNG for the filters: > collapsed: > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersCollapsed.png > expanded: > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/filtersExpanded.png > > What do you think? > Could this filters be helpf
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Tue, Jun 8, 2010 at 11:19, Ecaterina Valica wrote: > On Tue, Jun 8, 2010 at 09:01, Denis Gervalle wrote: > > > On Mon, Jun 7, 2010 at 17:00, Ecaterina Valica > wrote: > > > > > > It will if it display the inheritance source in a column. For right > set > > > at > > > > current level this column could even precise what inheritance has > been > > > > overwritten, both in terms of allowance and origin. > > > > > > > > Denis. > > > > > > > > > Hi Denis, > > > > > > "Something" like this: > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > > > > > > > Yes, "something" like that. I would have expected a "back to basic" > button > > in place of "advanced, and the removal of the basic interface to avoid > > duplicating basic rights. Maybe the menu should be horizontal in the > > advanced interface, I do not know. Also add some hyperlinks to upper > level > > in the column explaining inheritance. And put the highlight of changes > over > > the rest of the row (includes name and inheritance) > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space > > About: > > > I would have expected a "back to basic" button > > in place of "advanced, and the removal of the basic interface to avoid > > duplicating basic rights > > > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/rights52Space.png > > This removal of the basic interface will be set from the user profile's > variables (if it has advanced type)? No, just removed when the advanced interface is shown using the advanced button, like you have done. > I mean if the user is advanced, all the > rows will be presented in advances? > No, the only thing I proposed is that user that are not set "Advanced user" in their profile, will not be presented the advanced interface link, and will never see extended rights. > I'm asking because I think the collapsed view is great to see changes up in > the table, where you don't care the advanced status of those rights. > I completely agree. Advanced interface is for understanding and fixing deep complex stuffs > > > > WDYT ? Is this interesting ? > > > > it's nice :P I would love to see some other opinions. > Yes, could it be possible for you to fix the interactive version to hide the basics and also to have hover and click work as expected. I think it will helps in receiving more feed back with causing confusion. I found the result really well suited now. There is just some improvement in color contrast, icons aspect, and so on that should be applied if we get approval for this proposal. Once you have fixed the sample, I think that a summary page (resume of our reflexion, and containing only the final proposal) and than a vote thread could be appropriate to receive feedback from other committers, since the size of this thread could be pushing back. WDYT ? Denis > Thanks, > Caty > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Mon, Jun 7, 2010 at 10:50, Ecaterina Valica wrote: > On Sat, Jun 5, 2010 at 01:53, Denis Gervalle wrote: > > > Hi Caty, > > > > I am glad to see that others are looking at what we do, and it is good > time > > for them to comment now, since I will not have many more comments now :) > I > > have replied to some of your comment below... > > > > On Fri, Jun 4, 2010 at 18:54, Ecaterina Valica > wrote: > > > > > Hi, > > > > > > Take a look at Rights 5 > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights5Space > > > > > > Added: > > > * information regarding the advanced rights (inherits, overrides) > > > * icons built together as a whole > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/icons.png > > > * representation of "advanced rights" with the same abstract icon, but > > with > > > different color (no text; we can debate this) > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/color.png > > > * inheritance arrow married with +/- > > > > > > IMGs (in case of browser problem) > > > - collapsed: > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/rights5Space.png > > > - expanded: > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/rights5SpaceExpanded.png > > > > > > On Fri, Jun 4, 2010 at 10:42, Denis Gervalle wrote: > > > > > > > Hi Caty, > > > > > > > > On Thu, Jun 3, 2010 at 18:09, Ecaterina Valica > > > wrote: > > > > > > > > > Hi Denis, > > > > > > > > > > I want to thank you again for all the help you are giving :P > > > > > > > > > > > > > This is pleasure to participate especially because you provide really > > > good > > > > proposals. > > > > I would also like to see others participating, currently the > discussion > > > is > > > > becoming to much bilateral IMO. > > > > > > > > > > > > > > > > > > Please take a look at a proposal for "V3 and my 3)" version with > > > elements > > > > > from Rights2 :) > > > > > > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal > > > > > and in "action" > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Space > > > > > > > > > > > > Really nice job ! I really appreciate. > > > > > > > > > > > > > The prototype is not reflecting the "desired" interaction: both > > > inherited > > > > > info and rights change appear on hover (right icon and arrow), > > instead > > > of > > > > > hover | click. > > > > > > > > > > > > > I am not sure what are really your intend. I think that the big > > tooltips > > > > describing the rights should be the only tooltips, and should be show > > on > > > > hover only after a small timeout (like the yellow one currently). > > > Clicking > > > > any where on the +/- icon or v would then open the menu. > > > > Is it what you try ? > > > > > > > > > > > yes, on hover show the tooltip, on click show the menu. > > > > > > This is perfect, but you should include a little timeout for the > tooltips, > > or it will be too much invasive. > > From the reaction of Alex and Raluca, I really hope you will be able to > > implement the correct interaction in your samples, since this seems to > > cause > > a lot of confusion. If you can't, let me know, I will try to find some > time > > to have a look at it. > > > > > > > > > > > > > > > > > > > > > > That "v" needs to be an arrow like the one we use in the action > > menus. > > > > > > > > > > On Tue, Jun 1, 2010 at 19:06, Denis Gervalle > wrote: > > > > > > > > > > > Caty, > > > > > > > > > > > > Really nice and interesting post, I will try to reach that > level... > > >
Re: [xwiki-users] [Proposal] Rights Management UI
Hi Caty, I am glad to see that others are looking at what we do, and it is good time for them to comment now, since I will not have many more comments now :) I have replied to some of your comment below... On Fri, Jun 4, 2010 at 18:54, Ecaterina Valica wrote: > Hi, > > Take a look at Rights 5 > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights5Space > > Added: > * information regarding the advanced rights (inherits, overrides) > * icons built together as a whole > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/icons.png > * representation of "advanced rights" with the same abstract icon, but with > different color (no text; we can debate this) > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/color.png > * inheritance arrow married with +/- > > IMGs (in case of browser problem) > - collapsed: > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/rights5Space.png > - expanded: > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights5Space/rights5SpaceExpanded.png > > On Fri, Jun 4, 2010 at 10:42, Denis Gervalle wrote: > > > Hi Caty, > > > > On Thu, Jun 3, 2010 at 18:09, Ecaterina Valica > wrote: > > > > > Hi Denis, > > > > > > I want to thank you again for all the help you are giving :P > > > > > > > This is pleasure to participate especially because you provide really > good > > proposals. > > I would also like to see others participating, currently the discussion > is > > becoming to much bilateral IMO. > > > > > > > > > > Please take a look at a proposal for "V3 and my 3)" version with > elements > > > from Rights2 :) > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal > > > and in "action" > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Space > > > > > > Really nice job ! I really appreciate. > > > > > > > The prototype is not reflecting the "desired" interaction: both > inherited > > > info and rights change appear on hover (right icon and arrow), instead > of > > > hover | click. > > > > > > > I am not sure what are really your intend. I think that the big tooltips > > describing the rights should be the only tooltips, and should be show on > > hover only after a small timeout (like the yellow one currently). > Clicking > > any where on the +/- icon or v would then open the menu. > > Is it what you try ? > > > > > yes, on hover show the tooltip, on click show the menu. This is perfect, but you should include a little timeout for the tooltips, or it will be too much invasive. >From the reaction of Alex and Raluca, I really hope you will be able to implement the correct interaction in your samples, since this seems to cause a lot of confusion. If you can't, let me know, I will try to find some time to have a look at it. > > > > > > > > That "v" needs to be an arrow like the one we use in the action menus. > > > > > > On Tue, Jun 1, 2010 at 19:06, Denis Gervalle wrote: > > > > > > > Caty, > > > > > > > > Really nice and interesting post, I will try to reach that level... > but > > > > without visual :\ > > > > > > > > I really think that using the collapsed view for editing would helps > > > basic > > > > users to have a simplified and more easy interface to understand. We > > may > > > > even imagine that only "advanced user" (those marked so in their > > > profile), > > > > has access to the expanded view. > > > > > > > > I think that the collapsed view missed an additional icon that > > summarize > > > > the > > > > rights that are not shown. This one would only be shown if there is > any > > > > non-defaulted additional right in action. > > > > > > This is a signal that extended > > > > rights are in use (See it like the grey box of Windows when special > > > rights > > > > are setup, which is inviting to go into advanced view to know more). > > This > > > > one would be obviously not editable, and should probably work like > the > > > ... > > > > or replace it ? In place of the ... . Concerning the ..., I am not > > sure, > > > > but > > > > I would also prefer to see a textual link "advanced&
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
Hi Caty, On Thu, Jun 3, 2010 at 18:09, Ecaterina Valica wrote: > Hi Denis, > > I want to thank you again for all the help you are giving :P > This is pleasure to participate especially because you provide really good proposals. I would also like to see others participating, currently the discussion is becoming to much bilateral IMO. > > Please take a look at a proposal for "V3 and my 3)" version with elements > from Rights2 :) > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal > and in "action" > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Space Really nice job ! I really appreciate. > The prototype is not reflecting the "desired" interaction: both inherited > info and rights change appear on hover (right icon and arrow), instead of > hover | click. > I am not sure what are really your intend. I think that the big tooltips describing the rights should be the only tooltips, and should be show on hover only after a small timeout (like the yellow one currently). Clicking any where on the +/- icon or v would then open the menu. Is it what you try ? > > That "v" needs to be an arrow like the one we use in the action menus. > > On Tue, Jun 1, 2010 at 19:06, Denis Gervalle wrote: > > > Caty, > > > > Really nice and interesting post, I will try to reach that level... but > > without visual :\ > > > > I really think that using the collapsed view for editing would helps > basic > > users to have a simplified and more easy interface to understand. We may > > even imagine that only "advanced user" (those marked so in their > profile), > > has access to the expanded view. > > > > I think that the collapsed view missed an additional icon that summarize > > the > > rights that are not shown. This one would only be shown if there is any > > non-defaulted additional right in action. > > This is a signal that extended > > rights are in use (See it like the grey box of Windows when special > rights > > are setup, which is inviting to go into advanced view to know more). This > > one would be obviously not editable, and should probably work like the > ... > > or replace it ? In place of the ... . Concerning the ..., I am not sure, > > but > > I would also prefer to see a textual link "advanced" in small font, and > > only > > visible when row is hovered. > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal#HRowhover Sorry to insist, but the information regarding the advanced rights is still missing in collapsed mode. I really would like to have a indicator that some advanced rights has been set locally or not without having to go advanced mode. Else, you will have to expand all rows to check that information, which is not practical. > > > > Order of right are not significant, so I would prefer that in all view, > > these where in the same order, with the basic right first (V/C/E/D/A/P) > and > > the additional right in their order of registration (hope that it will > stay > > constant... or we will have to find a way to keep them ordered). > > The "right" part of each icon should be grayed if the right is inherited > > and > > not grayed if the right is set locally, this improve the information > > provided in V3. > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal#HAfterclick > > The problem with this icons (taken from Silk) is that there is little > difference for View, Comment, Admin icons between the two states > (inherited, > locally set) - but this is something we can easily improve (by changing the > icons and looking for some more contrast). > Example: This is how they look when all rights are set locally (full color) > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/fullColors.png > > > > > I also think that the +/- (which is never grayed) could be > > nearer to the right icon. Maybe you could use a green V and a read "stop" > > in > > place of +/- ? > > > > The other mockup versions (like > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space) > used > v/x for the allow/deny representation, and yes, I agree that they are more > suited than +/-. > > The problem is that we are using in XWiki, X to represent delete, so having > two xX was too much, that's why I introduced +/-. Maybe we can find another > solution. > I think we need some polishing on the icons used. Building them specifically would be nice, but I do not know if you or anyone want to have a
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
Caty, I probably have an issue with my browser (Chrome/Mac) but I cannot see the icons :( Anyway this seem to me nice, but I am not sure you should prevent changing rights in summary mode. I think that summary mode should allow simple right management, and for 'casual' or less knowledgeable users, this should be the only mode used. This is not only a summary, but also a simplified interface. WDYT ? Denis On Mon, May 31, 2010 at 16:54, Ecaterina Valica wrote: > On Mon, May 31, 2010 at 17:53, Ecaterina Valica wrote: > > > Hi, > > > > Summary Icons for standard rights: > > > > *Space Level:* > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Space > > *Wiki Level*: > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal > > > > Sorry: link for Wiki is > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Wiki > > > > > > Bug: > > - when clicking on "more" next to the summary, all columns should expand, > > not just one column at a time. > > > > Missing: > > - expand/collapse all + pagination, etc > > > > Remarks: > > - Summary view is good for quick scanning of the rights. Rights > management > > (changing) and inheritance explanations are available in expanded view. > > - Icons presented just for: view, comment, edit, delete, admin, register, > > programming. Extended rights|Expand mode are represented by "..." (more) > > > > Thanks, > > Caty > > > > > > On Thu, May 27, 2010 at 11:26, Denis Gervalle wrote: > > > >> On Thu, May 27, 2010 at 09:57, Ecaterina Valica > >> wrote: > >> > >> > Hi, > >> > > >> > I want to talk a bit about: > >> > > >> > > The inheritance is a little bit particular, since allowing a given > >> right > >> > at > >> > > lower level, will deny that same right for anybody else even if this > >> > right > >> > > is allowed at a higher level. > >> > > > >> > > >> > I want to know how hard this would be to be changed. > >> > > >> > >> Changing this is not hard, but it will increase complexity since we will > >> need a backward compatibility mode for existing wikis. > >> > >> > >> > Another question is why this has been done in the first place? Can > >> someone > >> > give a valid use case when this is more productive than other ways. > >> > > >> > >> I really do not know, and I am curious as well. > >> > >> > >> > It is very confusing and users need to do additional steps in order to > >> give > >> > the rights they want. > >> > > >> > >> I completely agree, this is poor. > >> > >> I think is a problem of how the Groups are perceived. Only as a rights > >> > mechanism or as a semantically grouping. > >> > > >> > >> We should not decide this, since groups maybe synchronized from external > >> system (ie LDAP), imposing groups for rights is not correct. By the way, > >> groups may contains groups, but I am almost sure that this will work > >> properly in practice. > >> > >> > >> > If we use groups just to give rights than the current implementation > is > >> > usable. But if you have groups, like Tech team, Design team, > Marketing, > >> > Happy team ... etc in order to classify our users in other ways beside > >> > rights management, giving permission to a user is breaking all the > >> > inheritance from upper levels. > >> > > >> > Example: > >> > Group A(Managers) has View (default allowed) at wiki level - this > means > >> > that > >> > they should be allowed to view all the pages in the wiki. > >> > Group B(Tech Team) has View (explicitly denied) at spaceX level - this > >> > means > >> > they shouldn't be allowed to view this space. > >> > > >> > But I have a person (the managerX) in Group B that is supposed to see > >> the > >> > info in spaceX level. So the first logical move would be to give him > >> allow > >> > at space level (having in mind that space rights are stronger that > wiki > >> > rights and the view right has been overriden). But, if I give managerX > >> view > >> > right, all the other groups (incluing Managers) will be denied for
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Thu, May 27, 2010 at 09:57, Ecaterina Valica wrote: > Hi, > > I want to talk a bit about: > > > The inheritance is a little bit particular, since allowing a given right > at > > lower level, will deny that same right for anybody else even if this > right > > is allowed at a higher level. > > > > I want to know how hard this would be to be changed. > Changing this is not hard, but it will increase complexity since we will need a backward compatibility mode for existing wikis. > Another question is why this has been done in the first place? Can someone > give a valid use case when this is more productive than other ways. > I really do not know, and I am curious as well. > It is very confusing and users need to do additional steps in order to give > the rights they want. > I completely agree, this is poor. I think is a problem of how the Groups are perceived. Only as a rights > mechanism or as a semantically grouping. > We should not decide this, since groups maybe synchronized from external system (ie LDAP), imposing groups for rights is not correct. By the way, groups may contains groups, but I am almost sure that this will work properly in practice. > If we use groups just to give rights than the current implementation is > usable. But if you have groups, like Tech team, Design team, Marketing, > Happy team ... etc in order to classify our users in other ways beside > rights management, giving permission to a user is breaking all the > inheritance from upper levels. > > Example: > Group A(Managers) has View (default allowed) at wiki level - this means > that > they should be allowed to view all the pages in the wiki. > Group B(Tech Team) has View (explicitly denied) at spaceX level - this > means > they shouldn't be allowed to view this space. > > But I have a person (the managerX) in Group B that is supposed to see the > info in spaceX level. So the first logical move would be to give him allow > at space level (having in mind that space rights are stronger that wiki > rights and the view right has been overriden). But, if I give managerX view > right, all the other groups (incluing Managers) will be denied for spaceX > level. This means I need to know that and "repair" again all the rights I > ALREADY set at the higher level. > > This behavior is not logical for me. > It is not logical for me and I imagine many others ! > > A solution would be to take out managerX form Group B and leave it just in > Managers group. Yes, this way my problem is solved, but this means Groups > are only used for Rights purposes. Group B (Tech Team) is no longer > semantically compact and I can't further give this group compact tasks, > etc. > > Please tell if is a way to change this behavior and please have in mind > XWiki 3.0, where Groups are going beyond rights management and they should > be seen as collaboration mechanisms (which need to be semantical). > IMO, XWiki 3.0 should have a complete rework of the right service implementation, and breaks with the past. Since this will cause many migration issue, I am not in favor of progressive changes, and I would prefer to see a big single change that fix this, and also the current discussion on script rights. Denis Rights should be inherited from upper level and should affect only the > user/group where a change is made, not make some complicated implications > at > other levels and groups. > > Thanks, > Caty > > On Wed, May 26, 2010 at 16:48, Ecaterina Valica wrote: > > > Hi, > > > > Did: > > - source of inheritance is per rights; > > - local source of inheritance: if the a right is allowed to anyone else > at > > the same level, it is implicitly disallowed for any others; > > - inheritance from upper levels / groups. > > > > Please see if I put the rights correctly: > > Wiki Level: > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki > > Space Level: > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space > > > > Obs. Summary view + icons not done yet. > > > > Thanks, > > Caty > > > > > > On Sat, May 22, 2010 at 11:31, Denis Gervalle wrote: > > > >> Hi Caty, > >> > >> This one is simpler and more easy to understand than proposal 2 (which I > >> liked but were complex). It is your best try IMO. I agree with Caty that > >> using icons too reduce the place taken will not allow easy extensions. > But > >> Alex proposal would help to have a summary view, which is nice to have > >> too. > >> > >> Maybe we could do both in fact. Propose a summary view (by default), &
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
ights Proposal 4: > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal > > > Wiki Prototype: > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki > > > Space Prototype: > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space > > > > > > This proposal is done by using feedback provided by Roman Muntyanu and > > > Raluca Morosan. > > > Thanks, > > > Caty > > > ___ > > > users mailing list > > > users@xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/users > > > > > ___ > > devs mailing list > > d...@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Wed, May 19, 2010 at 12:39, Ecaterina Valica wrote: > On Tue, May 18, 2010 at 18:29, Denis Gervalle wrote: > > > On Tue, May 18, 2010 at 17:08, Guillaume Lerouge > >wrote: > > > > > Hi, > > > > > > On Tue, May 18, 2010 at 11:03, Ecaterina Valica > > wrote: > > > > > > > Hi, > > > > > > > > I've reviewed some of your feedback and added them to Rights > Management > > > UI > > > > Proposal *VERSION 3*: > > > > > > > > *Partial Prototype* > > > > > > > > - Wiki Level: > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Wiki > > > > - Space Level: > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Space > > > > - Page Level: > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Page > > > > > > > > *Desired Interaction* > > > > > > > > - > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal > > > > > > > > Thanks, > > > > Caty > > > > > > > > > > I like the separation between rights definition and rights affectation. > > > Only > > > > > > > Nice indeed, but I do not understand how it could fits with current > > implementation. > > > > > > > downside -> inherited rights are displayed less clearly than what they > > were > > > in version 2. > > > > > > > and I do not see any inherited information anymore. > > > > For example, in Space Level > http://localhost:8084/xwiki/bin/view/Improvements/Rights3Space > the text in yellow represents the inherited users and inherited roles from > upper level. > > The text in black (evalica with Reviewer and the Reviewer definition) is > specified only for this level. > > After the save the added "Reviewer" right is gonna look like this: > > http://localhost:8084/xwiki/bin/download/Improvements/Rights3Proposal/addU6.png Thanks for these precision, I have better understand your idea. (Personally I have some difficulties with colors (partially color blind), so information based on colors is not always easy for me.) > > > > So, proposal 3 seems less interesting than proposal 2. I do not see what > it > > solves based on previous comments either. > > Caty, could you explain further your goals with this proposal ? > > > > I tried in proposal 3 to make it more easy to use. People told me that they > didn't understood the "Containing Spaces/Pages" so I've removed it. > This proposal gives the users the possibility to create Roles that can have > semantically value to them and thus making the rights more easy to use. > > This proposal accommodates the case: "Not sure it's scalable. In the future > applications/components will be able to register new rights". > Having the rights displayed vertically and only on Add, makes the UI more > scalable, and in the code we could add as many rights as we would want. > Also > the spaces is now more economical having just "Allow"/"Deny" columns. > I completely agree that proposal 3 is clearer. The problem is that your samples and the structure of this proposal are really far from current implementation. Proposal 2 were fitting better but the samples where also not realistic and remarks from Thomas about global wiki users should also be integrated. So, I am puzzle by your goals here. Aren't we going too fast ? Since there is very poor documentation about the way XWiki rights works (I would be happy to improve that, but it will require some time), I have the impression that there is a important misunderstanding of how inheritance is effectively applied. So the design of a proper UI is not easy. I have also read the draft of Sergiu that aims to improve the documentation, but either I have not understand it or it does not describe current behavior. So the question is for me, are we designing this UI to think about future possibilities or to replace the current UI ? Denis > Thanks, > Caty > > > > > Denis > > > > > > > > > > Also, a drop-down might be better than an autosuggest when selecting > > which > > > right should be added to a role. > > > > > > Guillaume > > > > > > > > > > ___ > > > > devs mailing list > > > > d...@xwiki.org > > > > http://lists.xwiki.org/mailman/li
Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Tue, May 18, 2010 at 17:08, Guillaume Lerouge wrote: > Hi, > > On Tue, May 18, 2010 at 11:03, Ecaterina Valica wrote: > > > Hi, > > > > I've reviewed some of your feedback and added them to Rights Management > UI > > Proposal *VERSION 3*: > > > > *Partial Prototype* > > > > - Wiki Level: > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Wiki > > - Space Level: > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Space > > - Page Level: > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Page > > > > *Desired Interaction* > > > > - > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal > > > > Thanks, > > Caty > > > > I like the separation between rights definition and rights affectation. > Only > Nice indeed, but I do not understand how it could fits with current implementation. > downside -> inherited rights are displayed less clearly than what they were > in version 2. > and I do not see any inherited information anymore. So, proposal 3 seems less interesting than proposal 2. I do not see what it solves based on previous comments either. Caty, could you explain further your goals with this proposal ? Denis > > Also, a drop-down might be better than an autosuggest when selecting which > right should be added to a role. > > Guillaume > > > > ___ > > devs mailing list > > d...@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Lerouge > Product Manager - XWiki SAS > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > ___ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.2.6 Released
The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.2.6. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is a bug fix release for the 2.2 branches. Fixes since 2.2.5: * [XWIKI-4378] - Should never deny resources access through skin URL * [XWIKI-5004] - Inactive user should be able to access the same UI than XWikiGuest * [XWIKI-5005] - Form displayed to inactive user after login for account activation does not submit to correct URL * [XWIKI-5064] - Issue escaping " [ " when located in front of an URL * [XWIKI-5113] - Id block inside header is badly rendered * [XWIKI-5114] - Allow controlling the depth of headers to look for when generating titles from document's content (configuration in xwiki.cfg) * [XWIKI-5126] - Link to force editing a locked user is wrong in new UI * [XWIKI-5127] - #googlecalcustom macro mixup front and background colors, and also use a "Test" title * [XWIKI-5128] - XWiki doesn't check groups permissions correctly in multiwiki environment * [XWIKI-5131] - PropUpdateAction use wrong XWiki#flushCache method * [XAADMINISTRATION-134] - Users->add new user not using XWiki.Registration with field validation. * [XAADMINISTRATION-131] - Hide color theme setting from space administration (currently unsupported at the level) For more information see the Releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise226 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM226 Thanks -The XWiki dev team ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [xwiki-devs] XWiki Logo Challenge, Round 2
> > IMO it's a bit too late to give -1 for a logo that passed the first > round. Is it less readable now? > > 16 was voted by 11 community members (including myself) in the first > round. Do we count less than "people from outside the project"? If we > want a community-chosen logo then we should let the community choose. If > we want a logo that is good for marketing then we should find a branding > company to do it for us. > > Thanks, > Marius I completely agree with Marius, I would also add that since this is a Community project, it should have a Community logo ! Since 16 has receive many votes now, and that I also agree with Vincent, Ludovic and others, it is not readable enough, I have made an alternative design: W-angle. My feeling was that the W is difficult to read, so my proposal try to keep the style and reworked it. There is also small changes in spacing, and a different powered by button. Here is almost all that was requested in a proposal with this variable: http://dev.xwiki.org/xwiki/bin/download/Community/LogoChallengeRound2/16%2Dwangle%2Ddefault.png I really hope that if the logo 16 is chosen, my proposal could help in mitigating the disappointment of those that really find it unacceptable. WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] XWiki Logo Challenge, Round 2
Since the original 15 were my preferred but the review has nothing to do with the original one and is now closer to existing logos, since my second choice 19 has not been review and integrated and that 12E is definitively nice but too close to the original logo, the match is between 4A and 16B for me. Both have been improved well, especially 4A, and both could do, except that I do not found the small icon and the "powered by" one really nice or readable. Since I had to choose only one, I have finally preferred the technicality of 16B slanted and its different versions for each products, over the color pencils of 4A, that evoke for me, drawings, children and games, ideas being not the initial purpose of XWiki :-) +1 for 16B Great jobs guys for these proposals, many thanks, Denis On Fri, Apr 9, 2010 at 19:33, Trevor Russ wrote: > Ah, it could just be due to the "printscreen of a quick SVG". The "powered > by" buttons were unreadable to the point where if I didn't know what their > intent was, I wouldn't know what they were other than coloured blobs with > some white writing. I presume the final versions would be large enough to > be legible. > > "Zooming in" on the screenshots show them up better, and while I like the > full "XWiki" logo, I find the Icon and Button "X" part to be a little > thin/weak and maybe spread out. I don't know how else to describe it. > > What I really like about 16B is the different logos for .org, Enterprise, > and Office. > > Trevor > > On Fri, 09 Apr 2010 16:31:34 +0200 Sergiu Dumitriu wrote: > > On 04/09/2010 04:03 PM, Trevor Russ wrote: > > > +1 16B. > > > > > > Although I found the "powered by" buttons for most submissions > (including 16) to be almost unreadable. > > > > Any hints on how to improve it? What exactly is wrong? > > > > Note that the buttons are not completely polished yet, this is just a > > printscreen of a quick SVG. > > > > > Trevor > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] XWiki Logo Challenge
My favorite is 15. * nice work done for 15 but i find the logo too similar to Atlassian > logo (any basic human based logo would look too Atlassiannish to me i > think) I strongly disagree that just because it represent a people, it is Atlassian like, they do not hold the exclusivity of people logos. Atlasian logo is like a weight-lifter that lift the world, very straight on its foot. Nothing to do with a happy jumping man, using really curved shape at all ! XWiki is about peoples sharing information and compare to most other logo, 15 is one that have the most interesting evocation. Without dash, in red or another color, avoiding blue (even if I like it) and probably using a more curved font to improve, if needed, the clear difference it have with the Atlassian logo. I would be curious to see what Vishal could propose with some more work. 19 would be my second choice, since it is curved, and even nice straight logo like 7, 8 or 16 evoke to me some inflexibility or technicality, which is frightening. 12 could be interesting as a continuation on the initial theme, but it would be less distinctive with XWiki.com, probably a nice evolution for them not for the open-source one. 1, 2 and 13 are not scaling. 17 is nice, but not scaling and evocation is inappropriate. Appart for not being easy to scale, I feel 4 is not readable for newcomers, using only 2 pencils, could probably helps there. Many thanks to all designers anyway for their proposal and please do not feel hurt by my remarks that I really hope to be constructive. Denis ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Bug: create/delete wiki rights from account not named "Admin"
Hi Trevor, I just want to complete what Guillaume had said. For any documents it exists 2 authors: - the last _author_ of the document, the one that have saved any information into the document - the last _content author_ of the document, the one that have saved the _content_ of the document The first one is show in the about div at the bottom of each document, the second one is very hidden and could only be checked in an XAR export, a raw XML view of the document or using code. For some operations, like accessing the internal privileged API from velocity or running groovy scripts, the _content author_ of the document containing the (velocity) code (or the one your are looking at for groovy) should have programming rights. Currently, with the new rendering engine, the document on which the content author is checked is always the document your are looking at, not necessarily the one that directly contains the code. This should be improved later, when the new 2.0 macros received more context information. Therefore, the rights to do an operation has usually nothing to do with the programming rights of the currently connected user. AFAIK, there is almost no case where the currently connected user is check against programming rights in a standard XWiki. So most of the page of a basic XWiki does not require such rights, some does. And due to the way new wikis are setup, generally by an import procedure, there may be additional issues, regarding programming rights: - most pages has XWiki.Admin as content author at initial stage - in a farm, those having XWiki.Admin as content author in another wiki than the main one, does not have programming rights (XWIKI-4066) - importing non-backup pack does not help in fixing content authors (XWIKI-3725) So this is currently a bad idea to remove XWiki.Admin, and I generally change its password to some random one for securing that somewhat internal account. As Guillaume said, there is room for improvement: - ensure proper context for 2.0 macros (in progress I think) - ensure better support of content authors during import (XWIKI-3725, XWIKI-4066, XWIKI-4073) - allow importing backup pack (like the XWiki provided ones) as non- backup one, this would allow importing non-backup pack with another admin as content author - it could also be useful for admin to see who is the content author more easily, since there is no interface showing them Hope that this will help you understanding potential programming issues. Regards, Denis On 24 août 09, at 17:37, Guillaume Lerouge wrote: > Hi Trevor, > > On Mon, Aug 24, 2009 at 5:06 PM, Trevor wrote: > >> In setting up our XWiki farm, I came across a couple of bugs. >> In general, should we always bring up bugs on the mailing list >> first before >> entry into jira? >> >> I deleted the account named "Admin" after setting up other >> individuals as >> administrators. A user with "admin" rights (or even "delete" >> rights) could >> no longer create or delete wikis from the "wikis" page of the XEM. >> However, >> if I recreated an account named "Admin", then a user with "admin" >> rights >> *could* create/delete wikis from that page, even though they're not >> logged >> in as user "Admin". >> >> The rights checking on that page must be hardcoded to check if user >> "Admin" >> has the rights, instead of checking the user who's actually logged >> in and >> making the page request. >> >> XEM 1.9.3 > > > That's most probably due to a programming rights issue. In XWiki, > certain > pieces of code (namely Groovy code) can be executed only if the last > user to > have saved the document where such code is stored has programming > rights. > This is to prevent arbitrary code execution and privilege escalation > in the > wiki. > > If I'm correct, all you need to do after deleting the "Admin" > account is to > save the page where the Groovy code is stored with one of your other > admins, > after making sure that admin has the programming right set as true > at the > global level of your farm. > > We're aware that the way this mechanism works is not ideal in cases > such as > yours and we'll fix its logic at one point, but for the time being > that's > how things work. > > So it's not quite a bug but I agree there's room for improvement. > > As for discussing issues on the mailing lists before posting on > JIRA, well, > the discussion will take place in JIRA comments if it has to > anyway ;-) > > Thanks for your feedback, > > Guillaume > > >> >> >> Trevor >> ___ >> users mailing list >> users@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> > > > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailm
Re: [xwiki-users] DNS mapping
Hi Trevor, I maintain XWiki farm for while using such a scheme for our internal access. For the DNS settings, you should consider that www, wiki, client1, and client2 are hostnames. You do not really need to define all of them separately, you just need a wildcard record in you zone: * IN A ip.add.res.s Ability to use a wildcard as hostname may depend on your ISP, but this is correct DNS usage and this ensure that anything.yoursite.com will be directed to your XWiki. Please note that you may precede this wildcard with normal A record, and these will take precedence (ie: This is usefull if your mail server is in the same zone). The wildcard record should be the last one in the zone. Regarding the farm configuration, there are several things you must know that may ease your maintenance. First, you should be aware that it exist a fallback selection of the xwiki database, that trigger when no XWikiServerXxxx page matches the hostname. This fallback consist in taking the hostname up to the first dot as the wiki name. So that client1.yoursite.com, will first check for any XWikiServerXxxx containing a hostname like this, but if none are found, client1 will be tried as the wiki name. Second, if you have a xwiki.virtual.autowww configuation parameter that is NOT equal to 0, your XEM manager will be reachable from www.yoursite.com , localhost or the IP address of your xwiki host. For all other aliasing, you should use a proper alias in a XWikiServerXxxx configuration as you had probably done actually. Regards, Denis On 21 août 09, at 15:25, Trevor wrote: > In setting up our wiki farm, we'd like to do this: > > http://www.oursite.com/xwiki = the XEM manager > http://wiki.oursite.com/xwiki = internal wiki > http://client1.oursite.com/xwiki = Client 1's wiki > http://client2.oursite.com/xwiki = Client 2's wiki > > How do we go about doing this? I've got the wikis themselves set up > and responding properly using my HOSTS file (mapping each of those > to the same IP), but how is it done in a "production" environment > (for both internal and external clients)? > > We don't have our own DNS server, we rely on the ISP. Are these > subdomains? Or different hosts of the "oursite.com" domain? > > Yes, I've searched for answers and have read about DNS and > subdomains, etc. but it's just not sinking in. Anyone have a good > link for reference? > > Any help would be appreciated! > > Thanks, > Trevor > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] groovy.lang.MissingMethodException - No signatureof method
; > > > > NOTICE > > This message and any files transmitted with it is intended for the > addressee only and may contain information that is confidential or > privileged. Unauthorised use is strictly prohibited. If you are not > the > addressee, you should not read, copy, disclose or otherwise use this > message, except for the purpose of delivery to the addressee. > > Any views or opinions expressed within this e-mail are those of the > author and do not necessarily represent those of Coventry University. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users -- Denis Gervalle SOFTEC sa http://www.softec.st ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Hidden input after select, radio or checkbox, why ?
Sergiu,
Do you means that this trick is used because the save action of XWiki
is unaware of the list of field shown to the user by the preceding
inline action, and you do not know if a field should be updated or
left unchanged when it is not sent back ?
Denis
On 23 sept. 08, at 18:54, Sergiu Dumitriu wrote:
> Denis Gervalle wrote:
>> Hi all,
>>
>> Does anyone here knows why displayEdit of ListClass fields with a
>> display type of checkbox, radiobutton or select is always followed
>> with a hidden input tag, having the same name than the visible
>> control ?
>>
>> Here is an excerpt of the source code that cause this :
>> if (!getDisplayType().equals("input")) {
>> org.apache.ecs.xhtml.input hidden = new
>> input(input.hidden, prefix + name, "");
>> buffer.append(hidden);
>> }
>>
>> I really wonder what is the need for that, and if I can remove it,
>> since this seems to break some screen readers, that makes confusion
>> between listbox and combobox due to this hidden field.
>> Thanks in advance for any advices.
>>
>
> It is needed because of the way HTML forms work. Without the empty
> field, you would not be able to unselect all options, because the
> browser does not send back the field name if it doesn't have any value
> to associate with it. The empty hidden field is used by the wiki
> engine
> to detect if it is a field with no values selected, or no field at
> all.
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Hidden input after select, radio or checkbox, why ?
Hi all,
Does anyone here knows why displayEdit of ListClass fields with a
display type of checkbox, radiobutton or select is always followed
with a hidden input tag, having the same name than the visible control ?
Here is an excerpt of the source code that cause this :
if (!getDisplayType().equals("input")) {
org.apache.ecs.xhtml.input hidden = new
input(input.hidden, prefix + name, "");
buffer.append(hidden);
}
I really wonder what is the need for that, and if I can remove it,
since this seems to break some screen readers, that makes confusion
between listbox and combobox due to this hidden field.
Thanks in advance for any advices.
Denis
--
Denis Gervalle
SOFTEC sa
http://www.softec.st
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [ANN] XWiki Enterprise 1.5 Released
Great news ! I have just finished to cope with your previous 1.4 release :) Now I wonder what I should do ? I need to put in production my XEM server very soon, now. Will it be long to have XEM 1.3 ? I wonder if I should stay on 1.4 platform or go ahead ? Is an upgrade of XEM 1.2 with the platform of the XE 1.5 a good idea or not ? Thanks in advance for your thought about that. Denis On 23 juil. 08, at 19:09, Jean-Vincent Drean wrote: > The XWiki development team is pleased to announce the release of XWiki > Enterprise 1.5 final. > > Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download > > This release spanned a bit more than 2 months starting on the 16th of > May 2008 and ending on the 23th of July 2008. During that period we > implemented 166 issues, fixing 91 bugs and adding new features such > as: > > * Brand new Administration Application (see http://tinyurl.com/4qym7w) > * The copy page feature is now available from the top menu (Actions > > Copy) > * An administrator can modify a user profile or password when > visiting a user profile page > * A message advising to install xwiki-enterprise-wiki is displayed in > the importer when the wiki is empty > * Universal Edit button support (see http://universaleditbutton.org/) > * Lot of improvements in the LDAP authenticator > * New Croatian translation > * New Czech translation > * Updated French translation > * Updated Spanish translation > * Updated German translation > > For more information see the Release notes at: > http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise15 > > Thanks > -The XWiki dev team > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users -- Denis Gervalle SOFTEC sa http://www.softec.st ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
