Hi devs,
We run into a complicated issue related to XWiki cache and permissions. In
order to fix the issue, we would like to know some underlying logics for
XWiki security and group cache:
1. Why XWiki cache purge happens every 4 hours?
2. From our dashboards, we notice that every 4 hours, the security
authorization cache purge will wipe out most entries(from 50K to 5K). Why
this happens rather than selectively expiring 4-hour-old entries over time
gradually?
3. From our dashboards, we notice the user group cache dumps on an irregular
cadence. The number of entries will drop to nearly 0 on 12:00 and bounce
back at around 16:00 nearly every weekday. Do you know some reasons behind
that?
4. What's the underlying logic of XWiki purges SecurityCache entries? We
assume it will happen in one or both of the following cases:
1. when a given page's permissions are changed
2. when a given user is removed from a (XWiki-internal) group
Is that correct?
5. We have a custom code called LDAP service. When our wiki user calls that
service, we wish to keep the cache for only a few minutes and then
invalidate the cache. So if our user calls again after a few minutes, it
will try to get reply from the service instead of the cache. For our case,
what method do you suggest to use when we invalidate SecurityCache entries?
Is there any side effect if we do that?
Thanks a lot for your help!
--
Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html
Hi,
As some of you know, in January we had another session of usability tests
performed. As a result of those tests, I have prioritized [1] some issues
that we might want to improve in our next 10.x+ Roadmaps.
One of the entries from that list is: "Create a dedicated Logo section in
Administration".
Although we made some improvements in this area, users still struggle to
find the Logo changing area (takes more than 3 minutes). Plus there is a
lot of confusion between the Skin and ColorThemes overriding.
This is a proposal to explicitly have a Logo section inside the Themes
section of Administration
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaChangeLogo#HSolution1-1
Let me know what you think,
Caty
[1]
http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/Tasks5/Prioritiza…
Hi devs,
The purpose of this mail is to decide on some rules for where admin related
applications should be located. This mail resulted after a discussion with
Vincent and it was initially started by the proposal to move Menu
application inside Administration [1].
Some mentions:
- Admins should have a central place where they could find all the
applications they can use and are intended for them. Having a central
location helps discoverability. Administration would be that place.
- Applications have configurations and actions. All configurations should
be in Administration. If the actions are targeted only to Administrators,
they should be listed also in Administration. We will use TABS, one for
configuration, one for the actions UI (ex Invitation app). If the actions
are targeted also to Users, than this application should be publicly
available (ex User Directory).
- These mixed target applications, might have admin dedicated actions
displayed in place (ex. livetable edit, delete entry. ex. Repository app
import). This is fine since it preserves the context, not all admin actions
should be present exclusively in Administration.
- Application Index should contain only applications that are targeted
towards normal users. Admins will have Administration as entry point.
- If the application needs to add special permissions to a group of users,
these can be added with rights, or provide manual links towards the
application in a custom menu/panel (ex Stats app providing access to a
particular user).
This means several changes for the following applications:
Bundled apps listed in AppIndex:
1. Invitation App - Move the actions (Invitation.WebHome) to
Administration. Use ConfigurableClass and create a new Tab containing the
actions. Remove the AppBar entry (UIExtensionClass).
2. Panels - move to Administration, remove the AppBar entry.
3. Menus - move to Administration, remove the AppBar entry.
4. Scheduler - move to Administration, remove the AppBar entry.
5. Tour - move to Administration since it contains tour definitions.
6. User Index - leave it public, but remove the AppBar entry since there is
a dedicated Drawer entry.
Recommended apps:
7. Antispam tool app - move to Administration, remove the AppBar entry.
8. Nested pages Migrator - move to Administration, remove the AppBar entry.
9. Filter Streams Converter Application - move to Administration, remove
the AppBar entry.
10. Flash Messages Application - move to Administration, remove the AppBar
entry.
Note:
- In case we might have a lot of applications listed in Administration, we
might need in the future to reorder them and prioritize some. We might need
to introduce the concept of Simple / Advanced administration, where in
Simple we could have just the applications that are mandatory for the
initial configuration flow. This should be discussed later.
Let me know what you think,
Caty
[1] http://xwiki.markmail.org/thread/romxz7iylujslg36
Hi devs,
I’m following up from the http://markmail.org/message/zegx62ogtq5evbsy thread and creating a new one since this is a side topic.
The idea is that right now when the user needs to create side content (ie Panels), it’s confusing since they can use either the Panels app or Menu app.
I have the following proposal: Separate the apps
* Keep the 2 concepts of Panels and Menus and make them separate: Use the Menu app for creating menus and the Panel app for creating panels
* Remove the ability to create panels from the Menu app
* Improve the Panel app to make it simpler to create panels
** Introduce a new xproperty for the panel title (and supporting scripting, could be a text area).
** If the panel xproperty content is empty then don’t display the title. This is to no loose the ability to have panels displayed only if some conditions are met.
** Display panel content textarea in WYSIWYG to make it simple for new admins to create panels.
* Note that this solves issue https://jira.xwiki.org/browse/XWIKI-10112 since we already have a Panel Wizard!
* If we want, we can also easily introduce the concept of visibility for panels.
WDYT?
Do you see any use case that wouldn’t be covered?
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
10.1-RC-1.
Starting with this release the Watchlist Application has been disabled and
fully replaced by the Notifications Application. We continue to add new
improvements to Notifications (filters, preferences, etc.) so make sure to
check them out.
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/Data/XWiki/10.1RC1/
Thanks for your support
-The XWiki dev team
Hi there,
I am new to this platform and it would be very kind of you if you provide
me with some insights into this project(TOUR-63) as to how should I proceed
to fix this error.
https://jira.xwiki.org/browse/TOUR-63
This is the link to the particular issue I am talking about which is about
the tour application(TOUR-63) which states about the issue “Tour button
ends up under the footer on big screens”.
Will be very kind of you if you can assist me with details as to how to
proceed with this project.
Regards,
Sidhanshu Binani.
Hi devs,
I’d like to work on a LaTeX Renderer + on an Export action for it. Thus I’m asking for a “latex” repo on contrib.
What I’m planning to do:
Step 1:
* Remove the "tex/1.0” syntax from xwiki-rendering. I don’t think it’s necessary to move it to xwiki-attic since it’s always been more of a quick POC than something usable
* Add a new “latex/1.0” syntax inside a new “latex” contrib repo: “latex/latex-syntax-10/“
Step 2:
* Idea: Implement a FilterStream app export filter for “latex”
Step 3:
* Provide an export URL for LaTeX that would use the FilterStream filter. Not sure yet about the implementation. Several ideas:
** Introduce a component role for the Exports we have (PDF, HTML, XAR, etc) to make them pluggable so that it’s possible to add new “export” actions. Or more generally, time permitting, refactor the “export” action as a EntityResourceAction component plugged in EntityResourceReferenceHandler
** Don’t use the “export” action and instead introduce a new type with a ResourceReferenceHandler (see https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Architecture/UR…).
** Don’t provide an “export” URL
Step 4:
* Integrate the export in the UI, using the “Export” menu UI. Would need a UIXP/XClass to make that extensible if that doesn’t already exist. Needs: be able to select page order, toc, list of tables, list of figures, page numbering, etc
* Other possibility (less nice): Don’t provide an “export” URL and instead tell users to use the generic FilterStream app when needing to export and if need be, in the future, provide a UI for it. However not sure how to ask the user for the list of pages to export, and the various questions (toc, list of tables, list of figures, page numbering, etc).
Thanks
-Vincent