Version 10 av Polopoly har nu fått sitt fjärde fix pack och sammantaget har de två senaste innehållit 22 fixar. Hela listan ser du nedan.

Change List for 10.0.0-fp4

• 12856: The help popup window in the Admin GUI should now have scrollbars when the content is too large to be displayed.

• 12863: Interactive Preview should now work when there are iframes with external (other domains) content.

Change List for 10.0.0-fp3

• 9963: OSelect now escapes option values

• 12768: A bug causing the tab navigation in the work frame of the editorial gui to sometimes be cut off visually has been fixed. The problem could be seen for example when creating new Site Aliases.

• 12769: It is now possible to paste content into size-limited full content lists where another element had just been removed.

• 12771: ThinClientSocketServletExample now manages to fallback to a PEAR configuration.

• 12773: It is now possible to navigate to a specific version – even symbolic, for example .LATEST – via both System Department and Search.

• 12778: In the Editorial Gui it was possible to drag anything into the catagory select content list, which could caused browser hangs. This is not possible anymore, and also sorting of the selected categories (which ment nothing) is not possible.

• 12784: Circular references in navigation structures should no longer cause p.SecurityParentSelect to spin forever.

• 12809: A thread synchronization problem in the web service has been fixed

• 12810: Greenfield Times: Links to content pasted in CK editor now displays correctly in the search result list on site.

• 12818: It is now possible to hide the Users and Groups button on all home departments except the Root Department. Set the component group polopoly.Client and name usersAndGroupsOnlyInRoot to value true on the system config content (ie externalid p.SystemConfig).

• 12821: A race condition in SiteAliasFilter initialization, potentially causing a NPE, has been removed.

• 12824: Usage of the retired property StatisticsPageViews.updateInterval has been removed from both product and Greenfield Times configuration.

• 12826: The maximum length of attribute group names are now read from the size of the actual SQL column used instead of being a static value.

• 12831: OWidgetBase will now automatically release any ajax event listeners registered using the widget compound id when disposed. Ajax event listeners registered using the registerAjaxEventListener(String, AjaxEventListenerInterface) method will however still need to be explicitly released (in releaseSelf()) by the widget that registered them.

• 12833: SolrQueryStringBuilder should no longer create invalid queries when no pages are supplied

• 12838: The field documentation has been updated to reflect the fact that p.Duplicator and p.MultiTypeDuplicator now longer have the ‘hasMoveButtons’ paramter.

• 12839: The Solr indexer no longer spins when solr.war repeatedly fails to index a batch of documents. Logging has been improved and retry frequency has decreased.

• 12841: CK editors should now no longer lose their content when dragged and dropped within duplicators.

• 12846: The initial number of search hits when using the Solr based editorial search is now configurable. See the developers guide, Solr Search section, for more information.

• 12850: p.Duplicator and p.MultiTypeDuplicator now has a parameter to use the legacy move (up / down) buttons.

Delade images i Amazons moln

Du har säkert suttit och tänkt att du skulle vilja installera den senaste versionen av Polopoly med tillhörande Greenfield Times, men som vanligt inte haft tid, på sin höjd hinner du läsa igenom versionens change list. Då har vi glädjande besked! Atex Polopoly kör i dag sina nattliga byggen i Amazons cloud, och vi har lyckats få dem att dela ut dessa till oss så vi kan installera deras images och därmed alltid ha det senaste funktionerna tillgängliga för utvärdering

Detta byte kommer troligen också innebära att den inbäddade HSQLDB byts ut mot annan databas. Atex Polopoly har också nu bestämt hur deras nya releasehantering ska se ut och det blev lite annorlunda än vad vi skrev om i  maj. Ojämna versionsnummer kommer inte att släppas som produktionrelease utan bara finnas för att ladda ner som Developer release från supportwebben. En developer release är tänkt att vara till för utvärdering och testning av ny funktionalitet som ska komma i nästa produktionsrelease.

Produktionsreleaserna som kommer få jämna nummer (9.16, 9.18 etc.) kommer att släppas med ca 8 månaders mellanrum, vilket är väsentligt längre än i dag. Developer release:en borde bli ett bra komplement till Amazon, eftersom du där inte kan testa utveckling, skriptning o.s.v. Ändringen till 8 månader mellan produktionsreleaser borde innebära att många av buggarna i Poloploly hittas innan produkten skeppas.

Värt att tillägga är att enbart produktionsreleaserna kommer att buggfixas, hittar man en bugg i en developer release får man vänta på nästa produktionsrelease för att få den fixad från Atex Polopoly.

Vad tycker ni om den nya releasehanteringen? Diskutera det i forumet under Vad tycker du om Polopolys nya releasehantering?

I dag fick jag något som jag väntat på sedan Atex Polopoly hade releasefest för 9.9 på Piperska muren för länge, länge sedan.  Ett mail från supporten som säger att de precis börjat lägga över sina kunder i deras nya ärendehanteringssystem baserat på Confluence och Jira.

Jag som många andra har säkert irriterat sig på att supportfrågor kan försvinna in i en svart låda där man i bästa fall får ett ärrendenummer på sin fråga , eller ibland bara får ett svar ”Vi tittar på det och återkommer”, allt för att sedan bara flyttas längre ner i din mailhög. Tillslut vet du inte hur många frågor du har ställt och vilka du fått svar på. Kanske kan vi få bättring på det nu!

Så här skriver Atex Polopoly i ett mail om nya ärendehanteringssystemet:

- Öka insynen i supportprocessen
- Minska hanteringstiden för rapporterade ärenden
- Göra en mer detaljerad prioritering av ärenden för att snabbare lösa kritiska ärenden
- Göra det enklare för flera människor att engagera och kommunicera kring ärenden
- Möjliggöra återanvändning av kunskap genom att bygga en FAQ och Knowledge Base-artiklar (kommer att förvaltas genom Confluence)

Personligen hoppas jag kunna söka bland andra kunders frågor och slippa gå på de minor som andra redan hittat lösningar på. En utförlig Knowledge Base skulle kunna bli ett bra komplement till forumets Kända buggar avdelning, där vi i dag saknar många av de frågor som vi betalar Atex Polopoly dyra pengar för att lösa.

Något som jag också hoppas är att ärenden som blivit klassade som buggar, nu alltid kommer att dyka upp i release notes, något som inte alltid varit fallet.

Har ditt företag redan blivit portat till det nya ärendehanteringssystemet? I så fall, hur har det fungerat?

Polopoly släppte idag version 9.13.2 och bland nyheterna så hittar vi bl.a en lösning för den inrapporterade buggen om att listningen av användare uteblir när man närmar sig 1000 st och kör Oracle som databas. Andra nyheter är bl.a. ändrade standardinställningar för minnet på index-, xml-, statistics- och pollservern, förbättrad dokumentation och att man tagit bort knappen för att manuellt bygga om sina index.

Kommande diskussion

Vi vill passa på att pusha för att vi senare kommer återkomma med en diskussion om hur vi (d.v.s. alla läsare på polopolyforum.se) skulle vilja att Polopoly hanterar sin information gällande nya releaser. Där vi hoppas på era förslag och synpunkter på hur man kan förbättra handhavandet för nya versionsreleaser, men mer om det i kommande inlägg.

Här kommer hela listan som den presenteras på Poloploys supportsida: