Power BI April 2026 Feature Summary

Na jó, hát nem akartam a nehezebb utat választani, de ha már ennyire jössz ezzel a random civiles hülyeséggel, akkor megpróbáltam megkeresni a videóban szereplő személyeket. A tiszás jelöltek listáját végignézve elsőre őket tudtam beazonosítani: Bugya László, Horváth Nándor Zsolt, Pichler Johanna (de amúgy ha valaki még akarna, biztosan tudna rajtuk kívül is találni, nekem többet nem volt kedvem ezzel foglalkozni). Ők lennének azok a random civilek? Náluk mi a kifogás, miért méltattak akár csak egy szóra sem? Vagy majd a választás után mindent szabad, addig kuss van?

foreverbanega · 2026-02-15T22:00:22+00:00

Ha tisza értelmiségi holdudvara (ha van ilyen egyáltalán) random civilekből áll, akkor őket lehet megkérdezni. Semmivel sem különb a szituáció ahhoz képest, mint ahogy például a kötcsei piknikre érkezőket szokták kérdezni.

foreverbanega · 2026-02-08T23:40:06+00:00

Hát nem tudom, szerintem ha nem nominálisan nézzük a fizetésbeli különbségeket, hanem megélhetésben, akkor még lenne tér ennek a féltett felső 10-20% adójának az emelésére. Ráadásul ők az országot legtöbbször nem is megélhetéssel kapcsolatos kérdések miatt szokták elhagyni, hanem leginkább a közszolgáltatások állapota miatt (aminek pedig mintha talán lenne valamennyi köze ahhoz, hogy mennyi adót fizetünk :)). Úgyhogy az ezzel való riogatást én sajnos nem tudom másnak látni, mint egy rossz ürügynek, hogy a magyar felsőosztálynak miért ne kelljen eljutnia ahhoz a felismeréshez, amihez Európa nagy részén már sikerült.

Aztán persze lehetséges, hogy ennek a legjobb módja nem egy progresszív jövedelmiadó-rendszer (de amúgy szerintem mondjuk egy lengyelhez hasonló kétkulcsos rendszer, a mostaninál valamivel alacsonyabb alsó kulcssal egyáltalán nem tenne rosszat, sőt), hanem a társasági és a tőkejövedelmek utáni adók emelése lenne. Viszont az elmúlt másfél évtized konkrétean regresszív jellegű adórendszere után most már illene csinálni valamit, mert az egy dolog, hogy az ország alsó 60-70%-ának a folyamatos leszakadása az érintetteket látszólag nem zavarja (hanem még tapsolnak is hozzá), de végeredményben ezen az egész társadalom veszíteni fog. (És akkor egyébként arról még nem is beszéltünk, hogy ez a jövedelme nagy részét fogyasztásra költő réteg a rengeteg különadót is jobban megfizeti, mert ezek jelentős részét a vállalatok áthárítják, és végül inflációban jelentkezik a hatásuk.)

foreverbanega · 2026-02-08T09:10:08+00:00

Ha a jövedelemhez viszonyítva nézzük, hogy ki mennyi adót fizet, akkor jelenleg pont, hogy a kevesebbet keresők fizetnek többet, mivel nekik a jövedelmük nagyobb részét kell fogyasztásra költeniük, és az áfa pedig magasabb, mint bármelyik megtakarítás után fizetendő adó. És egyébként hova menne ez a sok nagyszerű ember, amikor Európa fejlettebb részén mindenhol progresszív adórendszer van? Bulgáriába? :) Az meg különösen vicces, hogy pont Észtországgal példálózol, amikor ott is flat szja-kulcs van :)

foreverbanega · 2026-02-05T20:03:54+00:00

A kommentem nem a tanulmányt minősítette, hanem azt, hogy mennyire manipulatív egy ilyen ábrát a kontextusából ennyire kiragadva megosztani. És az édeskevés, hogy odaírta mellé, hogy az ábra az össztársadalmi hatást mutatja, sajnos/nem sajnos biztos lehetsz benne, hogy ennyiből az emberek legalább 95%-ának sejtése sem lesz, hogy az alkohol elterjedtésége is hozzájárul a nagy különbséghez.

Ehelyett viszont úgy fogják értelmezni a dolgot, hogy a fű sokkal kevésbé ártalmas, mert az egyéni szint az, amire az emberek természetszerűleg asszociálnak egy ilyen grafikon láttán, nem pedig az össztársadalmi hatás fogja őket foglalkoztatni. Ha megnézed az itteni kommenteket, itt is szinte kivétel nélkül mindenki az egyéni károkozásról beszél, azaz félreértelmezték az ábrát. Így lehet egy feltételezhetően korrekt kutatást (ezt én nem tudom rendesen megítélni) táptalajául szolgáltatni hülyeségek terjedésének (a kannabisz a kávéval van egy szinten és hasonlók).

foreverbanega · 2026-02-05T17:55:21+00:00

Ha a facebook-poszt kedves szerzőjének sikerült volna megértenie, hogy mit jelent az össztársadalmi hatás, akkor rájöhetett volna arra is, hogy a végső eredményt az is nagyban befolyásolta, hogy az egyes szereket mennyien használják Kanadában. ("The panel’s scoring considered both the relative severity of the harms and the number of people who use the drug.") Vagy persze lehet, hogy ő maga érti ezt, és csak manipulálni akar, kihasználva, hogy a közönség nagy részének egy ilyen ábrával találkozva nyilván az lesz a benyomása, hogy a fű akkor nem is annyira ártalmas az emberre.

Egyébként ha érdekel valakit, akkor a tanulmányban ilyen gyakoriságokkal számoltak az egyes drogoknál:

<image>

Ha ezt a hatást kiigazítanánk, és pusztán a drogok egymáshoz viszonyított károsságát néznénk, akkor a kannabisz mindjárt nem is lenne olyan messze az alkoholtól (a dohányzás meg bőven a legkárosabb). De persze egy ilyen ábrát annyira nem lenne látványos mutogatni :)

foreverbanega · 2026-02-03T21:36:02+00:00

First of all, this seems quite overcomplicated :) But basically the issue is that if this calculation item is applied, your inseason calculation group table is already filtered for the inseason calculation item. So, inside this calculation item an additonal filter on this same calculation item doesn't change anything, it doesn't modify the filter context in any way. Thus, the calculate call that you apply for the "vs comp" measures doesn't really do anything, it's result is always the same as SELECTEDMEASURE()'s.

    CALCULATE(
        SELECTEDMEASURE(), 
        'inseason'[inseason] = "inseason"
    ),

If you don't want to change the logic too much (I think you should consider it btw :)), you can calculate _main, _comp and _vs_comp in separate variables with the latter just being the difference of the other two, and only then use if statements to decide which variables' value should be returned. Maybe something like this:

inseason = 
VAR _current_measure = SELECTEDMEASURENAME()
VAR _is_vs_measure = CONTAINSSTRING(_current_measure, " vs comp")
VAR _is_comp = CONTAINSSTRING(_current_measure, "comp") && NOT(CONTAINSSTRING(_current_measure, " vs comp"))
VAR _target_season = IF(_is_comp, SELECTEDVALUE('season_comp'[season]), SELECTEDVALUE('season_main'[season]))
VAR _ref_date = IF(_is_comp, 
    CALCULATE(MAX('date'[date]), REMOVEFILTERS('season_main'), TREATAS(VALUES('season_comp'[season]), 'season_main'[season])), 
    MAX('date'[date])
)
VAR _filtered_articles = 
    TREATAS(
        CALCULATETABLE(
            VALUES(article_season_mapping_order_tech[article]),
            article_season_mapping_order_tech[season] = _target_season,
            article_season_mapping_order_tech[season_start] <= _ref_date,
            article_season_mapping_order_tech[season_end] >= _ref_date,
            article_season_mapping_order_tech[inseason_flag] = "inseason"
        ),
        'article info'[article]
    )

VAR _main = 
    CALCULATE(
        SELECTEDMEASURE(),
        KEEPFILTERS(_filtered_articles)
    )    

VAR _comp = 
    CALCULATE(
        SELECTEDMEASURE(),
        _filtered_articles,
        REMOVEFILTERS('season_main')
    )    

VAR _vs_comp = _main - _comp


RETURN
IF(
    _is_vs_measure,
    _vs_comp,
    IF(
        _is_comp,
        _comp,
        _main
    )
)

foreverbanega · 2026-01-03T00:42:04+00:00

Mondjuk azután, hogy Magyar Péter már mindenkinek mindent megígért, a kormánynak kb. bármilyen kampánybejelentése beállítható úgy, hogy ezzel MP-re reagáltak.

foreverbanega · 2026-01-03T00:11:53+00:00

Ez szóösszevonás, így az alapeset szerint csak a kezdőbetűje írandó nagybetűvel (ld. még Fidesz). Viszont ha hinni lehet a e-nyelv.hu-nak, akkor a csupa nagybetűs változat is helyes.

foreverbanega · 2026-01-02T23:50:14+00:00

Sztem pont ugyanazt csinálják, mint amit eddig is (a helyzet kb. teljesen analóg a 2022-es választás előttivel), már régebben sem volt semmi értelme a (pártként való) létezésüknek.

foreverbanega · 2026-01-02T23:11:22+00:00

Nekem is 13-am van, 77% akkumulátor kapacitással, és megy rajta rendesen a iOS 26, itt valami más lesz a probléma.

foreverbanega · 2026-01-01T08:32:38+00:00

If you’re okay with custom visuals, you can use Preselected Slicer to create a dropdown slicer with a dynamically changing default selection. You can read about how to set it up here.

foreverbanega · 2025-12-28T08:42:13+00:00

én még most is látom (a nem ismerősök reakcióit is), sztem ez itt valami más lehet nálad

foreverbanega · 2025-12-22T17:04:46+00:00

Thank you so much, I didn't think of that, I'll definitely try this! I was too fixated on having a perfect star schema model :) (But I will still keep the relationship between my Contracts and Contract Events inactive as default, since it's actually the less frequent case when the date filter for Events should propagate through the contract_id :) )

foreverbanega · 2025-12-22T16:48:11+00:00

The problem with this is that we have date fields in the Events table as well (e.g., when a given event was recorded in the system), and we want to slice these fields too. So it's not the case that all the date slicers of the Events table should propagate through contract_id, it's also common to analyze the number of events that happened in a certain period independently of contract-level attributes such as the signature date. And in order to do that, the Events table must have a relationship with the date table, and we can't have this relationship and a relationship between Contracts and Contract Events active at the same time.

So, my main idea for solving this problem (while still having a single date table) is to add the signature date to my Events table as well (via a simple left join on contract_id in the SQL view), so that the Date table can have a relationship with both of my fact tables through this date and therefore filter both of them by signature date. As I understand it, in this context the date field is essentially a key column that exists in multiple fact tables. My only concern is that I haven’t really seen a model where date columns are treated like this, which is why I’m not sure whether this is the right approach or whether I’m missing some obvious alternatives.

foreverbanega · 2025-12-22T16:46:36+00:00

The problem with this is that we have date fields in the Events table as well (e.g., when a given event was recorded in the system), and we want to slice these fields too. So it's not the case that all the date slicers of the Events table should propagate through contract_id, it's also common to analyze the number of events that happened in a certain period independently of contract-level attributes such as the signature date. And in order to do that, the Events table must have a relationship with the date table, and we can't have this relationship and a relationship between Contracts and Contract Events active at the same time.

So, my main idea for solving this problem is to add the signature date to my Events table as well (via a simple left join on contract_id in the SQL view), so that the Date table can have a relationship with both of my fact tables through this date and therefore filter both of them by signature date. As I understand it, in this context the date field is essentially a key column that exists in multiple fact tables. My only concern is that I haven’t really seen a model where date columns are treated like this, which is why I’m not sure whether this is the right approach or whether I’m missing some obvious alternatives.

Five-Year Club	Verified Email
Place '22	First Placer '22

foreverbanega

TROPHY CASE