Via uw connector connecteer ik op Odoo en laden veel tabellen perfect in. Enkel Account.move_line laadt niet goed; het laad de kolomnamen, maar toont geen data.
Ik heb voor zover ik weet alle rechten op mijn account staan. Ook als ik naar scherm Sessie I/O’s kijk zie ik geen foutmelding en staat er ‘geslaagd’. Ik ben door uw forums gegaan maar zie hier omtrent geen casus terugkomen.
Enig idee waar dit aan kan liggen?
Is het mogelijk om een (geanonimiseerde) schermafdruk van de details van het verzoek in Online Monitoring op Invantive Cloud toe te voegen zoals beschreven in Meer inzicht met nieuwe Online Monitoring?
De details vindt u door te klikken op het downloadverzoek welke het onderwerp van dit onderwerp representeert.
Het downloadverzoek heeft meestal een SQL-statement waarin de tabelnaam zichtbaar is.
Gelieve tenminste de volgende gegevens zichtbaar te laten van beide kolommen:
Bijvoorbeeld:
Controleer zorgvuldig dat u zich aanmeldt op de Invantive Cloud-website met dezelfde gebruikersnaam als waarmee u gegevens verwerkt via bijvoorbeeld Invantive Bridge Online. U ziet alleen de verzoeken van de Invantive Cloud-gebruiker waarmee u zich aanmeldt op de website.
Zorg ervoor dat u het verzoek eerst selecteert om de details weer te geven. Er hoort maar één verzoek zichtbaar zijn in de schermafbeelding.
Controleer ook zorgvuldig of het verzoek een pad heeft met odata4, apps of mcp. Verzoeken met andere paden zijn over het algemeen niet relevant voor dit doel.
Daarnaast zal de Invantive Cloud-gebruiker die de foutmelding heeft op zijn e-mailadres veelal een e-mail ontvangen met een foutmelding en tips als er sprake is van een foutmelding in Power BI, Power Query, Azure Data Factory, Qlik of Tableau.
Advies is om de spam van de betrokken gebruiker te controleren op dergelijke e-mails verzonden vanaf support@invantive.eu.
We kunnen het gedrag aan onze kant reproduceren, al is het niet duidelijk of de oorzaak dezelfde is. We voegen hiervoor wat logging toe aan de software.
De foutmelding is:
You do not have enough rights to access the field “analytic_coverage” on Journal Item (account.move.line). Please contact your system administrator.
Operation: read
User: 2
Groups: allowed for groups ‘Analytic Accounting’
Hoewel de bewoording dat doet vermoeden, lijkt dit eerder een instellingenkwestie te zijn dan een licentiekwestie.
Kun je:
Dat zou ons helpen om te bepalen wat de beste volgende stap is.
We gebruiken geen analytische boekhouding, daarom is de optie niet aangevinkt. Zou het mogelijk zijn om deze kolommen buiten de gegevensupload te laten?
Het probleem is nu dat we niet kunnen bepalen welke velden welke functies vereisen, dus het zou betekenen dat we deze kolom (of kolommen) volledig moeten verwijderen of ze moeten toevoegen aan een afgeleide tabel.
Is het problematisch om het vakje aan te vinken en te kijken of dat het probleem oplost, of verandert dat het beheer? Het zou helpen om te weten of dit hetzelfde probleem is. (Dit kan ook gedaan worden bij een testbeheer wanneer beschikbaar.)
Bedankt voor de snelle reactie. Dat heeft het probleem opgelost!
Bedankt voor het proberen en fijn dat het heeft geholpen. We zullen intern bespreken wat de beste weg voorwaarts is en de software aanpassen wanneer dat nodig wordt geacht.
Na intern overleg is besloten om de huidige logica in stand te houden: indien een gebruiker geen rechten heeft op een model volgens de API-server (in dit geval van Odoo), dan worden geen rijen teruggegeven.
Dit zorgt er voor dat het gedrag voorspelbaar is en blijft over alle platformen heen en alle gekoppelde tabellen.
Wel is een (interne) registratie toegevoegd zodat het in de toekomst eenvoudiger analyseerbaar wordt via de code itgenodo111. In Sessie I/O’s moet het zichtbaar zijn dat de rechten ontbraken en mogelijkerwijs wordt het nog verfijnd dat het zonder doorklikken zichtbaar wordt.
There is a new provider attribute that can be set on the startup SQL or preferably when testing tables from the UniversalSQL editor in Invantive Cloud:
set skip-error-on-no-access false
This way an error message comes through when there is no access, which makes it easier to diagnose the issue. Additionally session I/Os will be updated to show a failed HTTP request.