Som vi på polopolyforum skrev i september, så har Atex Polopoly ett projekt där de ska lansera en ny supportwebb för oss kunder efter nyår. Vi satte oss ner med Mattias Köhlmark som berättade om vad de tänker och hur systemet ser ut nu när ett par kunder har fått testa och säga sitt.

Polopolysupportens nya startsida (bild 1)

Så vad är det nya?

Lösningen som Atex tänker sig ta i drift för alla kunder efter nyår består av ärendehanteringsverktyget Jira kopplat till WIKI:en Confluence. Atex har använt Jira internt ett tag som ersättare till Bugzilla och känner sig nöjda med det. ”Många av våra kunder använder Jira, och det bidrog till valet, man känner igen sig” Säger Magnus Kölhmark.

Screenshot från Jira i nya Polopolysupporten (bild 2)

Grundläggande i en kunds konto i nya supportwebben är att man som kund har en grupp där alla ens användare är knutna till så att alla inom en organisation kan se alla ärenden som rapporteras från organisationen, oberoende vem som gjorde det.

Jira implementationen är ganska standard så som den ser ut i skrivande stund, med det man är van med så som personliga Dashboards och möjligheten att följa vad som händer via mail och RSS . Värt att notera är två viktiga val kan man göra när man lämnar sin buggrapport, och det är priority, vilket är en prioritet på ärendet från 1 till 3 där, 3 är högst, prioriteten är vårat sätt som kund att säga om vi tycker att en fråga är viktig relativt andra frågor som vi själva har skickat in till supporten. Med andra ord är det dumt att alltid sätta den till högsta prio.

Den andra viktiga inställningen på en rapport är Security Level, som beroende på kund kan sättas til publik eller privat fråga. Väljer man att rapportera med säkerhetsnivå publik, innebär det att andra kunder kan se och följa frågan.

Atex har också tänkt sig lite andra delar i nya supportwebbben, så som den utvecklare till utvecklare (Dev-2-dev) del där man kan ställa frågor till andra utvecklare, liknande polopolyforums forumdel.

Supporten ska också fylla sajten med sina omkringliggande kunskaper som inte direkt berör själva produkten. Magnus tar som exempel hur man bäst använder HTTP-cachning i sin driftmiljö. Informationen förmedlas under rubriken Tips and Tricks i form av Knowledge Base artiklar

Jira/Confluence lösningen ger också en snygg lösning på sökning som kommer ske i alla redaktionella  källor samtidigt, det vill säga DevGuide, JavaDoc och supportsidor (KB-sidor).

På frågan om vi som kunder kommer att kunna följa Polopolys behovslista (eng: Backlog) så var svaret från Atex svävande, men om jag får gissa så är svaret att det inte kommer att ske, inte heller på en högre, abstraktare nivå. Däremot verkar det som om kunder kommer kunna följa alla de buggar som fixas innan de hamnar i en releasead versions change list.

polopolyforums tanker och synpunkter

Ska man hårddra det så kommer Atex nya supportwebb att vara en konkurrent till polopolyforum.se, men jag skulle vilja börja med att säga att vi tycker att det är ett jättebra steg som man tar i och med Jira och Confluence. För om det är något som det finns för lite av så är det bra källor till Polopolykunskap på nätet, så ju mer snurr det blir på Atex supporten dessto mer kommer hända även här på polopolyforum. Det kommer dessutom vara en stor skillnad i att supporten alltid kommer att finnas bakom inloggning och inte lika lätttillgänglig.

Så vad gav vi för återkoppling till Magnus Kölhmark på mötet?

• Vi ser det som nödvändigt att man kan kommentera KB-artiklar och DevGuiden, inte bara för att rätta fel i själva texten, utan även för att kunna ge mer information om t ex konfigurationer som inte står i DevGuiden.
• Vi vill också att Atex importerar alla ärenden som i dag ligger i det gamla supportsystemet så de finns tillgängliga för oss kunder direkt när vi börjar använda systemet.
• För att förenkla borde startsidan inte vara bara text utan lyfta fram de saker som supporten gör, publika buggar som rapporterats in, och framförallt lista kundens alla öppna ärenden.
• Vi önskar också att man för in en möjlighet att lämna ”feature requests” vilket inte är möjligt i dag då det bara finns två val, bugg eller support ärende. Många gånger är det inte en bugg utan en ändring eller tillägg man vill göra på en funktion.
• Någon typ av meta-data driven ”Se även” listning på ärenden vore också bra, datamängden i Jira växer snabbt och man kan ha många ärenden liggande. Så en funktion för att se om andra har rapporterat liknande fel eller synpunkter vore bra. Det är svårt att hitta bara genom sökning. Kanske ett tagg moln?

Till sist …

Atex jobbar fortfarande med att utforma systemet, vad man ska få göra/inte göra, vad som ska finnas/inte finnas och det är nu som du ska göra din röst hörd om du har synpunkter!

Precis som Mats påpekade via vår feedback-funktion så har det saknats kategorier i forumet för att ställa allmänna frågor och dela med sig av tips. Forumet har tidigare varit lite för smalt vilket vi nu delvis hoppas råda bot på. Nu finns det två nya kategorier, ”Frågor om Polopoly” och ”Tips & Tricks” som vi tror ska fånga upp fler tankar och funderingar som alla kan ta del av.

Kom ihåg:

• Inga frågor är för dumma!
• Inget tips är för litet!

Var med och bidra i sveriges enda oberoende polopolycommunity och kom gärna med fler förslag via ”Tyck till”-knappen till höger.

Du har säkert tanken ”Varför gör de inte så?”, ”Borde de inte lägga till…”. Vi vill veta vad du avskyr, diggar eller saknar på polopolyforum. För att vi tillsammans ska kunna hjälpa varandra och förbättra denna community har vi lagt till en feed back-funktion där vi vill få in dina tankar och åsikter.  Den är extremt enkel, klicka på fliken ”Tyck till” som ligger till höger och skriv vad du tycker.

Bra saker som kommer fram samlar vi upp i vår publika behovslista.

Knappen finns längst till höger (kräver javascript)

Nu när sommaren börjar lida mot sitt slut och hösten knackar på så tar vi nya tag här på Polopolyforum.se.
Genom ett inledande möte med Anders Weinitz (produktansvarig på Atex Polopoly) i fredags så  fick vi se en demo av nyheterna i version 9.13 och vi passade samtidigt på att fråga om en del oklarheter som har dykt upp inför en eventuell uppgradering. 

Version 9.13, steg 1 i att skapa en robust metadatasökning

Version 9.13 är det första steget i att skapa en stabil metadatasökning och på plats finns nu:

• Taggmotorn Solr som hanterar indexeringen.
• Nya dimensioner i kategoriseringen (person, företag, taggar, plats)
• Atex Textmining som används för att generera förslag till de nya kategoriseringsdimensionerna baserat på inmatad titel och text i artikeln (Atex Textmining kommer dock ha en separat prislapp)
• Ny publiceringskö som baseras på valda kategorier från den nya kategoriseringswidgeten.

Man har även ändrat de taggar/kategorier som följer med som default och dessa taggar har de baserat på IPTC (International Press Telecommunications Council) i förhoppningen att de ska vara mer användbara än de som tidigare som följde med produkten.

Frågor och svar

När 9.13 släpptes och arbetet med uppgradering/migrering startade så kom en del frågor upp som behövde besvaras , här är några av de frågor som vi fick svar på

Fråga: Kommer vi behöva ha både Solr och indexservern nu eller kommer indexservern  att tas bort framöver?
Svar: Vårt mål är att få bort indexservern under hösten, den kan dock komma att finnas kvar som en fasad för vissa speciella ändamål.

Fråga: Kan man bygga egna dimensioner liknande de inbyggda?
Svar: Ja, men de kan inte kommunicera med Solr i nuläget.

Fråga: Kan man uppgradera till 9.13 utan att använda sig av Solr?
Svar: Ja, det kan man stänga av.

Fråga: Polopolys förslag på topologi som man hittar i dokumentationen ser ut att vara väldigt komplex och dyr om man jämför med många befintliga system, är det något som man måste följa för att detta ska fungera eller går den att simplifiera med lokala Solr slavar på befintliga fronmaskiner o.s.v.?

Svar: Ja, det går att simplifiera. Detta var bara en rekommendation och vi ska se över om vi ska uppdatera dokumentationen eller om vi kan länka in bra information till Solr:s egen dokumentation.

Vad kan vi se fram emot i verion 9.14?

Det är fortfarande ganska tidigt för att prata om detaljer i version 9.14 men i stora drag så kommer det handla om två saker. Det ena är att skapa stöd för att kunna hantera plugins på källkodsnivå, detta så att man enklare ska kunna dela fälttyper mellan projekt. Det andra man kommer lägga krut på är att förbättra prestandan och skalbarheten på frontarmaskinerna.

Mer om detta i kommande inlägg senare i höst.

Sommaren står för dörren och jag och Patric vill passa på att önska alla medlemmar och läsare en riktigt skön sommar. Forumet kommer givetvis fortsätta i vanlig ordning men bloggen kommer ha ett lugnare tempo då vi vill ta igen oss lite och ladda inför en spännande höst.

Ha en trevlig sommar!

Med vänliga hälsningar // Niklas och Patric

Vi har fått en fråga från ett företag som undrade om vi kunde göra ett Polopolyprojekt åt dem. Jag och Niklas tackade nej men tänkte att det kanske kunde vara något för någon annan, så vi skapade helt sonika en tråd i forumet, Polopolykompetens sökes, där ni som behöver få tag i folk och företag med Polopolykompetes kan lägga upp en förfrågan.

Jag antar att det är okej med er på forumet? Men om ni inte tycker att det hör hemma här, lämna gärna en kommentar och säg vad ni tycker. Man kanske ska kunna lägga ut en fråga om någon har ett uppdrag om man inte har beläggning också, eller?

Jag vill också påpeka att vi inte tar betalt för detta, och att ni som väljer att använda tråden inte kommer kunna få någon speciell service. Jag litar också på att ni agerar professionellt när ni söker folk.

Bara för att förtydliga användandet av denna tråd så är den inte till för att göra reklam för konsultverksamhet m.m. utan enbart för dem som söker polopolykompetens.

Polopoly släppte idag version 9.12.2 av sitt CMS där bland annat ”drag and drop” buggen i IE8 är fixad, samt att funktionalitet för bildhantering på frontarna nu har lagts till, vilket gör att man kan skapa derivat av orginalbilder (t ex tumnaglar, bilder för mobiler) dynamiskt på frontarna och slippa ha dessa lagrade i databasen. Se hela change-listan som den ser ut på Polopolys supportwebb nedan.

Change list

10153: It is no longer needed to restart the indexserver (nor to restart the client) after a rebuild of index.

10201: Content is now removed from PublicIndex in Greenfield Times when removed.

10342: It is now possible to edit the community bad words list in the editorial GUI again.

10723: Front servers now have the ability to generate image derivatives dynamically. This can be configured in the system content ”Image generation.” Turning on dynamic generation stops the CM from generating derivatives when importing and uploading images. In 9.12.x, this feature is disabled by default, while in 9.13.0 and later it is default enabled.

10731: More examples of how to write unit tests for policies added to the documentation.

10743: The ContentFileServlet now supports dynamic image generation of derived images.

10750: Fixed potential ejb deadlock that could occur in rare cases.

10752: The drag and drop feature in the editorial GUI is now compatible with IE 8 web browser.

10773: Greenfield Times now uses versioned content ids when building file links.

10776: There is now a cut button as a complement to copy in the Admin GUI by default.

10783: The contentfile servlet and the dispatcher now respond with 404 rather than a 500 response and a ServletException when the request URI can not be resolved to valid ContentIds.

10800: Now using another cache implementation for path segment to content id translations in com.polopoly.cm.path.TocBasedPathTranslator.

Tillsammans fick vi en lösning!

Den mest diskuterade frågan på forumet är den om frontmaskiner som inte uppdaterar sitt innehåll som de ska. Felet har lett till att besökare fått upp felaktigt innehåll eller 404-page not found, när de besökt sidor på webbplatsen. Att tömma frontmaskinernas ”cachar” och starta om webbapparna, har varit den enda tillfälliga lösningen på problemet. Fram tills nu! På skärtorsdagskvällen fick jag ett mail från Polopoly-supporten som säger sig ha hittat felet . En patch ska komma under nästa vecka och vi får hoppas att den håller vad den lovar (där av det lilla frågetecknet i rubriken)!

Jag skulle vilja tacka: simon.larsson, melker, Henrik, andersb & marcus.demnert för att vi tillsammans fick Polopoly att förstå att detta var ett stort och kritiskt problem för många av deras kunder.

Hela Polopolys svar finns att läsa i forumet.

En länge efterlängtad funktion från informationsavdelningen och systemdriften som underhåller installationen på KTH har varit att man ska kunna lägga upp ett systemmeddelande i Polopolys redaktörsgränssnitt som alla som loggar in eller redan är inloggade ska kunna se tydligt. Detta för att man snabbt och enkelt ska kunna informera alla inloggade redaktörer om man till exempel ska göra ändringar eller ska ta ner back end-servern för en uppgradering, så att de i god tid kan spara sitt pågående arbete och logga ut.

Funktionen bygger på följande komponenter:

• Polopolys indatamall p.UserSessionTemplate överlagras och får fältet:

  <field="systemMessage" input-template="it.field.systemMessage" label="" />

• Mallen it.field.systemMessage definierar enbart policyn och en widget för editor och viewer.
• Policyn är en extendad SingeValuePolicy som för tillfället inte innehåller någon extra funktionalitet.
• Widgeten rendrerar en stylad div och hämtar systemmeddelandet (första gången) om det finns något. Till denna policywidget finns också en jQuerybaserad javascriptfil som till uppgift har att hämta systemmeddelandet via ett ajaxanrop var 3:e minut från en specificerd url, detta så att det ständigt uppdateras även om redaktören inte refreshar sidan.
• I den mall (valfri) som sytemmeddelandet ska matas in läggs ett fält av typen p.TextArea in som senare innehåller själva meddelandet.
• På den ovannämnda specificerade url:en ligger en servlet som hämtar systemmeddelandet och skriver ut det i en divtagg med ett id som ajaxanropet känner till. I responset så var vi tvugna att sätt headen så att den aldrig cachar sidan. response.setHeader(”Cache-Control”, ”no-cache”); Annars fanns det risk att IE inte fick ett uppdaterat meddelande.

Om det är någon som vill veta mer om denna mall, ta en titt på tråden i forumet med namnet ”Systemmeddelande” under kategorin ”Mallutveckling”. Den innehåller bl.a. delar av källkoden.

Jag tänkte berätta hur man kan gå tillväga för att underlätta hanteringen av robots.txt-regler, och på samma gång få möjligheten att delegera underhållet av dem till personer som arbetar närmare källan av innehållet. Vi hade länge denna funktion i vår ”back log” och när tiden var inne tog vi in den i utvecklingsetappen och resultatet blev lyckat.

Fördelarna med denna lösning är följande

• Driftspersonal behöver inte längre blandas in när ändringar skall göras. Detta gör att driftspersonalen får mer tid till annat.
• Ledtiderna vid ändringar av reglerna minimeras eftersom redaktören själv kan ändra dessa.
• Lösningen ger möjlighet till att koppla ihop olika robots.txt-regler med olika site alias på en och samma site, så att man kan välja olika regler för olika alias. Detta är bra om man har url:er som man inte vill kommunicera ut men som är bra att ha för de som utvecklar och driftar polopolyinstallationen.
• Reglerna ligger i egna innehållsobjekt vilket gör att de kan återanvändas av flera olika siter.

Lösningens olika komponenter

• Robots.txt-reglerna.
• Mappningen mellan site alias och reglerna.
• Servlet som hämtar robots.txt-reglerna beroende på efterfrågad url.
• Filterhantering som mappar allt som går mot /robots.txt till ovannämnda servlet.

Lite mer ingående för den intresserade

Reglerna för sökmotorerna
Robots.txt-reglerna är uppbyggda av en enkel indatamall med en titel av typen p.ContentName och ett textfält av typen p.TextArea där reglerna kan matas in.  Policyn har metoder för att hämta ut titeln och reglerna.

Mappning av sitealias och robots.txt-regler
Mappningarna görs via en annan indatamall som innehåller följande komponenter:

• En innehållsväljare av typen p.ContentSingleSelect som används för att peka ut den robots.txt-resurs som ska användas för samtliga alias för aktuell site som inte har en specifik mappning mot en annan robots.txt-resurs.
• Ett fält av typen p.Duplicator som i sig innehåller två typer av fält. Ett fält av typen p.Text som tar ett sitealias (d.v.s. en url) och ett fält av typen p.ContentSingleSelect där man väljer vilken robots.txt-resurs som ska mappas mot det aktuella sitealiaset.

Policyn innehåller en publik metod som hämtar upp robots.txt-reglerna beroende på givet site alias. Hittas inte reglerna för detta site alias returneras defaultreglerna istället.

Servlet och servletmappning
Servleten använder sig av polopolys RequestPreparator för att hämta upp den aktuella sitepolicyn. Sitepolicyn används sedan i sin tur för att hämta rotinnehållspolicyn för siten där mappningarna mellan sitealias och regler finns. Från den innehållspolicyn hämtas reglerna upp och skrivs ut i servletresponsen.

Servletmappningen sker i web.xml och ser till att alla anrop till /robots.txt mappas till servleten som i sin tur genererar rätt regler till rätt url.

En tråd har skapats i forumet under ”Mallutveckling” för de som vill diskutera och få mer detaljer om denna funktionalitet