Själva idén med programmatiskt arbete med fördefinierade element, enligt min mening, är mycket korrekt. Det finns helt enkelt nyanser som måste beaktas när man arbetar.
Först måste du själv klart förstå att det finns fördefinierade element i konfigurationen och det finns fördefinierade element i informationsbasen (IS). Tekniskt sett är fördefinierade informationssäkerhetselement de vanligaste elementen i kataloger, där attributet "Name of Predefined Data" indikerar vilket fördefinierat konfigurationselement de motsvarar. De skiljer sig inte från vanliga element. Följaktligen kan vilket vanligt informationssäkerhetselement som helst göras fördefinierat, vilket som helst fördefinierat element kan göras ordinärt. För att göra detta, skriv bara in önskat värde i attributet "Fördefinierat datanamn".
Från tid till annan innehåller den här egenskapen ett värde som inte är det som utvecklaren avsett. Som ett resultat uppstår fel i driften av 1C. Från kritiskt, där arbete i princip är omöjligt, till icke-kritiskt, där logiken i algoritmerna störs.
Villkorligt kan vi skilja tre typer av fel:
1. "Det fördefinierade elementet finns inte i data";
3. Felaktig specifikation av ett fördefinierat element;
1. "Det fördefinierade elementet finns inte i data" - o frånvaro av ett fördefinierat element som beskrivs i konfigurationen i informationssäkerhetsdata.
Detta är den enklaste typen av fel att felsöka och korrigera. Dess enkelhet är att plattformen helt korrekt rapporterar denna situation "Det fördefinierade elementet saknas i data" och det är ganska tydligt hur man fixar det.
När du kommer åt ett saknat element i koden "Kataloger. Typer av kontaktinformation. Kontaktpersonens e-post" visas ett meddelande
När du kommer åt ett element i begäran "VÄRDE(Katalog.Typer av kontaktinformation.E-post för kontaktpersonen)" visas följande meddelande:
Detta fel uppstår om ett element beskrivs i konfigurationen, men elementet inte är associerat med det i databasen.
Till att börja med, låt oss klargöra att denna situation inte alltid är fel. Det är fullt möjligt att använda fördefinierade data i någon form av programlogik, som för de flesta användare kanske inte används. I det här fallet är det logiskt att definiera fördefinierade element i konfigurationen, för att inte röra upp katalogen för alla användare av konfigurationen, men inte skapa dem i alla informationssäkerhetssystem, utan endast för de informationssäkerhetssystem där den nödvändiga konfigurationslogiken används. I det här fallet kan programmeraren specificera egenskapen "Uppdatera inte fördefinierade data" för katalogen och skapa element programmatiskt när du kommer åt modulfunktionaliteten. Eller tillåt användaren att oberoende binda fördefinierade modulelement till befintliga vanliga element.
Dessutom används inte automatiskt skapande av fördefinierade element när du arbetar i RIB-läge. Eftersom nya element måste överföras från den centrala databasen, och inte skapas i noder med olika UID.
De där. Ibland är felet referensen till ett omatchat element, inte närvaron av ett sådant element i sig.
Det är nödvändigt att analysera varför elementet inte skapades. Det kanske borde skapas när något programläge körs. Till exempel efter att ha genomfört ett utbyte i RIB. Eller så har den bara raderats av misstag.
Om logiken ger möjlighet att fylla fördefinierade element inte automatiskt, utan i ett separat läge, innan du använder åtkomst efter namn " Kataloger.Typer av kontaktinformation.E-post för kontaktpersonen"För att förhindra en exceptionell situation är det lämpligt att kontrollera att elementet redan finns i databasen. Om elementet saknas, informera användaren om detta och förklara vilket läge han behöver utföra för att fylla elementet. För en sådan kontroll , kan du köra en datafråga.
Request = Ny begäran; Request.Text = "VÄLJ | Typer av kontaktinformation. Länk | FRÅN | Katalog. Typer av kontaktinformation HUR Typer av kontaktinformation | VAR | Typer av kontaktinformation. Namn på fördefinierade data = "" EmailContactPerson"""; Item Is MissingInData = Query.Execute().Empty();
Om detta fortfarande är ett fel i databasdata är det nödvändigt att binda till ett fördefinierat element i informationssäkerhetselementet. De där. det är nödvändigt att förklara för systemet vilket informationssäkerhetselement programkoden ska komma åt med detta namn. Tekniskt sett är en bindning helt enkelt att specificera namnet på ett fördefinierat element i egenskapen "Fördefinierat DataName" för IS-elementet. För att installera det, kör bara koden:
2. "Det fördefinierade elementet är inte unikt" - h dubbla fördefinierade element:
Denna situation är att flera informationssäkerhetselement är kopplade till ett fördefinierat element. I det här fallet, när du kommer åt ett fördefinierat namn, kommer elementet att väljas slumpmässigt. Denna situation är alltid fel. Dess svårighet är att plattformen inte rapporterar det på något sätt. Algoritmerna börjar bara fungera fel.
Plattformen kommer att rapportera felet "Det fördefinierade elementet är inte unikt" endast när du försöker redigera ett duplicerat element.
Så länge ingen behöver redigera elementet kommer ingen att veta om felet.
Sådana dubbletter kan skapas till exempel om RIB används för katalogen och läget "Uppdatera automatiskt" anges i egenskaperna för fördefinierade data. I det här fallet, när ett utbyte utförs, kommer en instans av fördefinierade data att skapas när konfigurationen uppdateras. En andra instans av fördefinierade element med samma namn kommer att överföras från den centrala databasen under utbytet.
Dessa dubbletter kommer också att uppstå vid användning av utbytesbehandling mellan konfigurationer om olika informationssäkerhetselement motsvarar fördefinierade element i olika databaser. I det här fallet finns redan en kopia av fördefinierade data i databasen, den andra kommer när data laddas med ett annat UID. Om du utför dataöverföringar måste du bestämma vilka databaselement som anses vara primära och använda dem i den underordnade databasen. I den underordnade databasen är det nödvändigt att ersätta användningen av gamla element med element från huvuddatabasen.
Sådana fel i databasen kan identifieras med en fråga som:
VÄLJ typer av kontaktinformation. Namn på fördefinierade data, MÄNGD(OLIKA typer av kontaktinformation. Referens) AS Antal fördefinierade FRÅN katalog. Typer av kontaktinformation AS Typer av kontaktinformation GRUPP EFTER Typer av kontaktinformation. Namn på fördefinierade data HAR KVANTITY (OLIKA typer av tactInformation.Link) > 1
Denna fråga returnerar en lista med fördefinierade element som mer än ett informationssäkerhetselement är associerat med.
Om sådana element finns, är det nödvändigt att ta bort anslutningen med den fördefinierade för en av dem. De där. Det är nödvändigt att entydigt bestämma för systemet vilket informationssäkerhetselement programkoden ska referera till när man använder detta namn. För att göra detta, kör bara koden.
3. Felaktig specifikation av ett fördefinierat element.
Felet är att det fördefinierade elementet motsvarar ett element som inte tillhandahålls av programlogiken. Sådana fel är de svåraste att diagnostisera. Till skillnad från de två första typerna kan konfigurationen inte kontrolleras automatiskt för dessa fel. De kan bara identifieras genom att analysera arbetets logik. Om du är osäker kan du kontrollera om rätt element används.
För att göra detta, kör bara ett av kommandona.
//Definiera ett informationssäkerhetselement som är kopplat till den önskade fördefinierade Notify (Directories.Types of Contact Information.Email of the ContactPerson) //Definiera ett fördefinierat element som den valda Notify är kopplad till (Link to Element.Name of Predefined Data) )
Om sådana fel upptäcks är det nödvändigt att ta bort den felaktiga anslutningen med det gamla elementet och lägga till en anslutning med det nya elementet. Operationskoden liknar koden för att korrigera de två första typerna av fel.
Tja, kortfattat om fel under programarbete eller i konfiguratorläge:
"Det fördefinierade elementet hör inte hemma<Имя справочника>" - ett fel uppstår när man försöker skriva ett fördefinierat element med ett namn som inte matchar namnet i konfiguratorn.
"Icke-fördefinierade objekt kan inte ha fördefinierade subconto view-poster" - ett fel uppstår när man försöker göra ett element i en fördefinierad kontoplan ofördefinierad. För att eliminera fel är det nödvändigt att ta bort flaggan "Fördefinierad" från varje elements underkontaktlinje.
"Icke fördefinierade objekt kan inte ha fördefinierade poster av ledande beräkningstyper"- ett fel uppstår när man försöker göra ett fördefinierat element i planen med beräkningstyper ofördefinierat. För att eliminera fel är det nödvändigt att ta bort kryssrutan "Fördefinierad" för varje rad av elementets ledande beräkningstyp.
"Fördefinierade element är inte unika"- ett fel genereras i konfiguratorn vid uppdatering av informationsbasen för en konfigurationsversion utan kompatibilitetsläge med 8.3.4. Det är nödvändigt att kontrollera efter dubbletter och eliminera dem innan du uppdaterar.
"Namnet på det fördefinierade elementet är inte unikt" - ett fel uppstår när det finns flera fördefinierade element med samma namn i konfigurationen vid uppdatering till plattformen8.3.6.2332 och högre. Det är nödvändigt att eliminera dubbletter i konfigurationen.
För att arbeta med fördefinierade data rekommenderar jag bearbetning. Den kan utföra alla åtgärder med fördefinierade data och kan också kontrollera konfigurationen som helhet för förekomsten av fel av de två första typerna (duplicerade och saknade element) i alla informationssäkerhetsobjekt (kataloger, kontoplaner, PVC, PVR) .
Alla vet skillnaden mellan fördefinierade element och vanliga: "Fördefinierade element skapas i Configurator-läget och kan inte tas bort i 1C:Enterprise-läge." I användarläge kan du skilja ett fördefinierat element från de som lagts till av användare med hjälp av en speciell ikon (se följande skärmdump).
I grund och botten skapas fördefinierade element av utvecklare för att binda algoritmer till dem i olika konfigurationsobjekt. Till exempel, i "Manufacturing Enterprise Management"-konfigurationen i "Quality"-katalogen, lade utvecklarna till ett fördefinierat element "New".
Detta element används i många konfigurationsmoduler. Så i dokumentet "Mottagande av varor och tjänster", när du bokförs i alla register där det finns en "Kvalitet"-dimension, ersätts värdet av ett fördefinierat element. Följande är en lista över att fylla i postningstabellen för registret "Organisationers varor":
// PRODUKTER EFTER REGISTRERA ProdukterOrganisationer. MoveSet = Flyttar. ProdukterOrganisationer; Om kvittotyp = överföringar. Typer av mottagningar av varor. Till lagret då // Få en tabell med värden som matchar strukturen för registerpostuppsättningen. MotionTable = MotionSet. Lasta av() ; // Fyll i rörelsetabellen. Generell mening. LoadValueTable(ProductTable, MovementTable) ; // Saknade fält. Rörelsebord. FillValues(Organisation, "Organisation" ) ; Rörelsebord. FillValues(Odefinierat, "Kommissionsagent"); Rörelsebord. FillValues(Kataloger. Kvalitet. Nytt, "Kvalitet" ); // Fyll i kvaliteten från ett fördefinierat elementSåledes är egenskaperna hos fördefinierade element och deras syfte ganska enkla. Låt oss titta på hur de lagras i databastabeller och hur de skiljer sig från vanliga element.
Skillnader
I testkonfigurationen skapades katalogen "Produkter". Gruppen "Testelement" har skapats i den. Du kan se innehållet i gruppen i skärmdumpen i början av artikeln. För katalogen "Produkter" har SQL-databasen en motsvarande tabell "_Reference37" med följande struktur:
Men hur kan vi avgöra om detaljerna motsvarar konfigurationsträdet och fälten i SQL-tabellen?
Vi kommer att använda den vanliga globala kontextmetoden "GetDatabaseStorageStructure()", som kommer att returnera oss en värdetabell med en beskrivning av tabellstrukturen.
I värdetabellen "Fält" ser vi överensstämmelsen mellan fälten i SQL-tabellen och objektdetaljerna i metadataträdet. I vårt exempel tar vi hänsyn till strukturen för katalogen "Produkter". Alla kataloger har ett standardattribut "Fördefinierad" av den booleska typen, som är satt till TRUE för fördefinierade element:
Baserat på tabellen med kataloglagringsstrukturen i databasen kan vi definitivt säga att fältet "Fördefinierad" motsvarar fältet "IsMetadata". Om vi tittar på innehållet i tabellen "_Reference37" i SQL-databasen kommer vi att se följande:
I posten för det fördefinierade elementet är värdet för "IsMetadata"-fältet satt till "0x01", vilket motsvarar flaggan TRUE. För normala element är värdet satt till "0x00". Detta är huvudskillnaden mellan fördefinierade element och vanliga. Alla andra fält lagras i databasen på samma sätt som fält i vanliga objekt som lagts till av användare.
Fördefinierade element kan ha mycket intressanta användningsområden. Med deras hjälp kan du förhindra att grupper av element tas bort/markeras för radering i katalogen och andra objekt där de kan läggas till. Om vi försöker ta bort eller markera för radering gruppen "Testelement". då får vi följande fel:
Således gör fördefinierade element gruppen där de är placerade också "fördefinierade".
Komplettering
Fördefinierade element är en integrerad del av de flesta konfigurationer. Deras användning förenklar utvecklingen och gör konstruktionen av funktionalitet logiskt mer "harmonisk" och integrerad.
När man arbetar på 1C:Enterprise 8.x-plattformen finns det ofta ett behov av att binda i programkoden till vanliga (ej fördefinierade) katalogelement. Till exempel kan en organisation ha fem typer av priser som används i nästan alla mekanismer. I det här fallet utförs programmatisk åtkomst till ett specifikt pris i bästa fall antingen genom att gnissla med kod i katalogen, eller i värsta fall genom namnet på elementet.
Jag såg hur i rapporter, för att få det erforderliga priset, urval användes efter pristyp i en förfrågan med dess namn (se följande skärmdump).
Dessutom, om du länkar till namnet eller koden för katalogelement, då när du får en länk till ett element, kommer en sökning alltid att utföras i katalogtabellen. Trots att standardsystemdetaljer indexeras av DBMS, kan sökning efter dem i vissa fall ta betydande resurser i anspråk. Dessutom skulle det vara mer rationellt att inte utföra en sökfråga med referenstabellen om, låt oss säga, länken till elementet redan är "känd i förväg".
Som en utväg kan du lagra en länk till varje ofta använda element i katalogen "Artikelpristyper" i separata konstanter och få värden från dem i begäran. Men i det här fallet måste utvecklaren lägga till en separat konstant för varje sådant element. Situationen kommer att bli betydligt mer komplicerad om sådana element inte bara finns i katalogen "Artikelpristyper", utan också i andra kataloger ("Objektkategorier", "Kvalitet", "Nomenklatur" och andra). Då kan antalet konstanter i systemet öka flera gånger!
Naturligtvis skulle det vara möjligt att lägga till fördefinierade element till var och en av katalogerna och det skulle bli mycket lättare att komma åt dem. Att ändra standardobjekten skulle dock göra det svårare att uppdatera konfigurationen från leverantörspaket.
Det finns ett mer optimalt tillvägagångssätt både när det gäller att utveckla och när det gäller systemprestanda. Detta är vad vi kommer att prata om idag.
Universell lösning
Kärnan i den universella lösningen kommer att vara följande: en katalog kommer att skapas där utvecklaren kommer att lägga till fördefinierade element. Attributet "Värde" har lagts till i uppslagningen, vars typ beror på de värden för vilka korrespondensen "Fördefinierat uppslagselement -> Associerat värde" kommer att skapas. Katalogmetadatastrukturen ser ut så här (se följande skärmdump).
För att få ett fördefinierat element är det bästa alternativet att använda den globala metoden "Fördefinierat värde(<Имя>)" . Den fullständiga sökvägen till det fördefinierade elementet skickas som en parameter till metoden. Syntaxen liknar frågespråksfunktionen VALUE().
För att underlätta utvecklingen rekommenderar jag att du placerar funktionen för att erhålla värdet som är associerat med ett fördefinierat element i en gemensam modul. I testkonfigurationen, tillgänglig för nedladdning via länken i slutet av artikeln, skapades en gemensam modul "Värden av fördefinierade element" med en exportfunktion "GetValue of PredefinedElement(<ИмяПредопределенногоЭлемента>)" . Funktionens programkod tar emot en referens till ett fördefinierat element och tar sedan emot värdena för attributet "Value" med hjälp av en begäran. Följande skärmdump visar hela funktionslistan.
Som vi kan se genererar funktionen en begäran om "Värde"-attributet för det fördefinierade elementet som skickas som en parameter. Funktionsparametern är en sträng med namnet på ett fördefinierat element.
För att den skapade mekanismen ska fungera korrekt måste du länka ett fördefinierat element i användarläge med ett vanligt katalogelement genom att välja motsvarande element i attributet "Value". Låt oss gå vidare till frågan om inverkan på prestanda.
Prestandapåverkan
Jag genomförde ett hastighetstest för båda sökalternativen: med namn och via länk från ett fördefinierat element. Sökningen skedde i katalogen "Produkter" med 20 000 poster. När man utförde tester på en fildatabas erhölls följande resultat:
Resultaten visade att för filversionen av arbetet är det nästan 4 gånger långsammare att använda fördefinierade element för att erhålla ofta använda element från andra kataloger!
I klient-serverversionen av arbete visar testresultaten en helt annan bild. Hastigheten för att få en länk till det önskade elementet har inte minskat nämnvärt (ett av testerna visade 0,002 sekunder för sökning med namn och 0,0008 sekunder när man arbetade genom ett fördefinierat element), men programmets tillförlitlighet har ökat avsevärt!
Slutsatser
I de fall det ofta är nödvändigt att länka till vanliga katalogelement rekommenderar jag att man inte använder bindning med kod eller namn. Detta tillvägagångssätt minskar systemets tillförlitlighet och prestanda.
Under min tid som jag arbetade med plattformen har jag mer än en gång stött på situationer där, efter att ha ändrat namnet, till exempel katalogelementet "PriceNomenclature Types", arbetet med de flesta icke-standardiserade rapporter misslyckades.
Ju fler algoritmer som är kopplade till vanliga katalogelement genom en kod eller ett namn, desto mindre stabilt är systemet.
Dessutom kommer detta tillvägagångssätt att tillåta dig att inte ändra standardkonfigurationsobjekt om du behöver lägga till ett fördefinierat element till dem. Detta kommer att göra processen att uppdatera konfigurationen något enklare i framtiden.
Filer för nedladdning:
- Laddar upp en testdatabas med exempel från artikeln.
God dag.
Idag ska vi prata om innovationen i plattform 8.3 när det gäller fördefinierade element.
Introduktion
Låt mig påminna dig om att jag tidigare i praktiken väldigt ofta ville titta på ett katalogelement för att ta reda på dess fördefinierade namn. Till exempel skapade du två fördefinierade motparter och döpte dem till IPSidorov och OOOMeteor. Och de sydde lite logik på dem.
När allt var felsökt och utarbetat visade det sig att uppgiften var omvänd och logiken för den enskilda entreprenören behövdes för LLC, och logiken i LLC behövdes för den enskilda entreprenören. "Inga problem", säger vi, och i företagsläge byter vi namn på elementen. När allt kommer omkring är det mycket svårare att komma in i koden. Ett år går och du får en ny uppgift: att ställa in lite mer logik för IP Sidorov. Du går in i konfiguratorn, skriver logik, börjar kolla och ingenting fungerar, eftersom... i IPSidorov-konfiguratorn och i företaget - OOOMeteor. Hjärnan är trasig och jag vill förstöra den här raken. Det enklaste och mest uppenbara är att visa namnet på ett fördefinierat element i form av en lista. Här är haken: du kan bara få namnet på en fördefinierad i 8.2 med metoden. Men metoden har sina egna olägenheter den kan inte erhållas i en begäran. De där. Det första besväret är att få namnet på den fördefinierade från en referens till katalogen.
Den andra olägenheten är när vi redan har ett katalogelement och vi behöver göra det fördefinierat. Vi skapar ett fördefinierat element och får två element i katalogen. Den ena är fördefinierad, den andra är operativ, vilket hänvisas till i alla våra dokument. Att ersätta länkar hjälper säkert, men om databasen är stor är det svårt.
Nu till saken
Den första är att katalogen nu har egenskapen "Uppdaterar fördefinierade data".
Vad ger detta fält oss? Om den är inställd på "Uppdatera inte automatiskt", så kommer vi inte att se det i katalogen omedelbart genom att lägga till ett fördefinierat element. De där. metadata har inget med data att göra. Och om du inte skapar det i katalogen kommer det att orsaka ett syntaxfel om du kommer åt det med dess namn via kataloghanteraren.
Mycket intressant, men varför? Hur kan vi skapa ett element i katalogen? Du kan skapa den hur du vill, eller så kan du länka den till en befintlig. Nu har katalogen attributet "Namn på fördefinierade data". Vi skapar ett katalogelement programmatiskt som vanligt genom "Directories.Contractors.CreateElement()" och fyller dess attribut "PredefinedDataName" lika med namnet på det fördefinierade elementet. Eller om elementet redan finns, hämtar vi dess objekt och fyller i "Namn på fördefinierade data" igen. Allt.
Och till sist lite sirap
Detta nya attribut är inte bara läsbart och skrivbart, det är också tillgängligt i förfrågningar. På så sätt kan du ställa villkor på den i frågor, avgöra om den är fördefinierad eller inte.
Tack för din uppmärksamhet.
I den fjärde lektionen av vår vi kommer att fortsätta att bekanta oss med programmet. Idag ska vi bekanta oss med praktiska exempel ochhierarkiska kataloger och även lära dig hur du skapar fördefinierade element.
Tidpunkt för 4 lektioner av kursen:
00:19
Ändringar i katalogen Anställda efter avslutad läxa för lektion 3 i kursen
00:35
Redigera ordningen på detaljer i kataloger
02:54
Skapa en katalognomenklatur
03:40
Skapa och sätta upp en hierarkisk katalog
05:10
Skapa grupper Tjänster och produkter i nomenklaturkatalogen
06:05
Fyller i nomenklaturkatalogen
07:14
3 sätt att överföra ett katalogobjekt till en annan grupp
08:21
Skapar katalogen Warehouses
09:19
Skapa fördefinierade katalogelement
11:25
Fyller i lagerkatalogen
12:20
Gör testet på lektion 4 material
Hierarkisk katalog– en katalog med möjlighet till hierarkiskt arrangemang av dess element. Till exempel, i nomenklaturkatalogen, kan grupper skapas: Produkter, Tjänster, etc., där element som tillhör dessa grupper finns. Dessutom kan kataloggrupper inkludera andra grupper och därigenom skapa en hierarkisk struktur på flera nivåer.
Dessutom stöder kataloger också en annan typ av hierarki, där katalogelement inte kommer att relatera till grupper, utan till andra element i samma katalog. Denna typ av hierarki ( elementhierarki) kan användas till exempel när du skapar en katalog med divisioner, där en division (en division är i detta fall ett element i katalogen, inte en grupp) kan inkludera flera andra divisioner. Denna typ av hierarki används ganska sällan.
Katalogformulär– visuell representation av katalogen. Beroende på vilka specifika åtgärder vi vill utföra med vår katalog, måste vi visa katalogen i "olika vyer". Så i lektion 4 av kursen redigerade vi ordningen på detaljer i form av en lista och i form av ett katalogelement.
Systemet skapar (genererar) formulär automatiskt, men vid behov kan utvecklaren "rita" formulären självständigt.
Det finns totalt 5 formulär (typer av formulär) för kataloger:
- elementform– för att skapa eller redigera ett katalogelement;
- gruppform- att skapa eller redigera en kataloggrupp;
- listformulär– för att visa en lista med katalogelement;
- urvalsformulär- används för att välja ett av elementen i denna katalog i ett fält av en viss form. Till exempel, för att välja ett specifikt lager från lagerkatalogen i dokumentet Godsmottagning i lagerfältet;
- gruppvalsformulär– används för att välja en av grupperna i denna katalog i ett fält av en viss form.
Fördefinierade katalogelement– katalogelement som skapats av utvecklaren i Configurator-läge och som kan nås från det inbyggda 1c-språket efter Namn.
Det finns en grundläggande skillnad mellan vanliga och fördefinierade katalogelement. Vanliga element är inte konstanta i konfigurationen. Under användarens arbete kan de skapas, redigeras och raderas och av denna anledning bör de inte litas på vid exekvering av några algoritmer (koden och namnet på elementet kan ändras av användaren).Fördefinierade element, å andra sidan, är permanenta. Under drift, även om användaren byter namn på ett sådant element, kan det nås från det inbyggda 1c-språket. Detta uppnås genom att det fördefinierade elementet har rekvisita namn, som inte är tillgängligt för användaren. Vanliga katalogelement har inte sådana attribut.
Viktig! Tekniskt sett har användaren möjlighet att ta bort ett fördefinierat katalogelement, men som regel nekas användare rättigheter att ta bort fördefinierade katalogelement.
Läxor för lektion 4 i kursen
Läxor för den fjärde lektionen av kursen kommer att vara tillgängliga för dig omedelbart efter att du lyckats lösa det teoretiska provet.
