In some cases where there were category restricted house ads we were not
showing ads on reload. This commit filter out all the ads that should
not be shown on current page, leaving only allowed ads. So now we'll
show ads on every reload in all the cases.
Internal ticket: t130920
# Description
This PR adds the ability to apply **group** and **category** restrictions to a **house ad**.
# What is included
- In order to get the group and category selectors to work within `admin/assets/javascripts/discourse/controllers/admin-plugins-house-ads-show.js` I needed to modernize the file.
- I dropped the `bufferedProperty` implementation in favor of a vanilla ember approach
- I added `category_ids` and `group_ids` to our house ads model
- I added tests for group / category restrictions
- I added a preview button to display the house ad
- `/site.json` would return a object called `house_creatives` and a list of key value pairs that matched the ad name with the html, like so:
```js
{ AD_KEY: ad.html }
```
I need access to the category ids on the client to conditionally render the house ads so the new format will be:
```js
{ AD_KEY: { html: ad.html, category_ids: ad.category_ids } }
```
# Screenshots
<img width="658" alt="Screenshot 2024-04-08 at 2 39 22 PM" src="https://github.com/discourse/discourse-adplugin/assets/50783505/b44b386d-65a1-4a2a-a487-d735b13357dd">
# Preview Video
https://github.com/discourse/discourse-adplugin/assets/50783505/6d0d8253-afef-4e15-b6fc-c6f696efd169
If the selected group to not display ads to had its visibility set to
not be visible then this setting wouldn't work correctly because that
group wouldn't be available client side. The change moves that group
check to be server side so that we can correctly see all the groups that
should not see ads.
Changes in 0948d6b19e caused the post-bottom-ad component to start receiving the widget-ised 'transformedPost' instead of the original `post` model. In most cases this difference didn't matter, but it did cause noticable issues with `@model.category` and `@model.topic`.
This commit also deletes the unused `post-bottom/discourse-adplugin.hbs` connector. In the past, the adplugin itself was defining the post-bottom outlet. But now, we use RenderGlimmer to load the `post-bottom-ad` directly.
With the new group system for displaying ads we no longer can check if a
user belongs to a trust level group lower than specified. The other
problem is that ALL users including staff and higher trust levels all
belong to trust level 0. So without this fix if we say that an ad should
be visible to trust level 0 users then it will be shown to all users.
This fix adds a new default setting for each ad platform for excluding
trust level 3, 4, and staff users from being shown ads.
- Make display_groups hidden (they will be removed in a later commit)
- Switch to using only exclude_groups instead of display groups and
exclude groups
- rename showToDisplayGroups to showXAds for each provider
* DEV: Convert TL settings to groups
This change converts the TL site settings in this plugin to use groups
instead.
See: https://meta.discourse.org/t/283408
Co-authored-by: Martin Brennan <martin@discourse.org>
In the past, the ad plugin relied on two side-effects to achieve this behaviour:
1. Components being fully destroyed/rendered when navigating between pages. This stopped working when Discourse core moved to the more efficient 'loading slider' UI
2. The `listLoading` argument. This was an implementation detail of the old discovery routing infrastructure. Core recently overhauled this and removed the `listLoading` argument, because loading is now handled properly by the Ember router.
Instead of these two properties, we can use the `currentRoute` property of Ember's router service to trigger changes when navigating between pages. A common `{{#each` trick is used to fully destroy/re-render components even if the ad network is unchanged.
This commit adds 2 new settings to house ads to control whether an ad is shown to anonymous users and logged in users. Existing ads that were created before this feature will default to true for both settings; i.e., they will remain to be visible to both anonymous and logged-in users, but it will be possible to change the settings. Turning off both settings will effectively disable the ad completely.
We expose the ad-slot logic to determine which ads are potentially available for each slot and don't render the connector when there are none. Leaking the component logic is not ideal, but I don't see a better solution given the
current design.
* init
* more
* Pass td and colspan to component
* various fixes for house ads between n topics and add a test
* Make adComponents condition easier to read
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
Co-authored-by: romanrizzi <rizziromanalejandro@gmail.com>
The tests were using an incorrect value for the site setting (the name of the group instead of the id).
`no_ads_for_groups` shows groups names in the UI byt actually stores IDs.