Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wladdons settings #365

Closed
wants to merge 21 commits into from
Closed

Conversation

frankystone
Copy link
Contributor

Probably a solution for #359

I've tried to archive this with the notification-app, but was not very successfull... so now a new app called wladdons_settings.

The label, description and display can only be changed via the file wladdons_settings.settings.py.

The table to retrieve the email setting is called wladdons_settings_addonnotice, the corresponding labels are addon_transifex_issues and addon_deleted. The field which shows if an email should be send is called shouldsend.

@frankystone frankystone linked an issue Dec 10, 2021 that may be closed by this pull request
@frankystone
Copy link
Contributor Author

I have changed the tables to get rid of the settings-file. This has the advantage that the Display and Description values can be changed without hassle. Also adding new noticetypes is much easier. The tables are now:

  • AddonNoticeType : Defines a noticetype, renamed label to slug
  • AddonNoticeUser: Defines the relationship between a user and a noticetype. Also the field shouldsend is stored here

So to fetch a users setting for emailing you need a query like this:

SELECT user_id, slug, shouldsend 
FROM wladdons_settings_addonnoticeuser,wladdons_settings_addonnoticetype
WHERE wladdons_settings_addonnoticeuser.user_id=3714
AND wladdons_settings_addonnoticeuser.notice_type_id=wladdons_settings_addonnoticetype.id;

+---------+--------------------+------------+
| user_id | slug               | shouldsend |
+---------+--------------------+------------+
|    3714 | add-deleted        |          0 |
|    3714 | translation-issues |          1 |
+---------+--------------------+------------+

Is this ok for you?

The workflow after this get merged is now:

  1. Go the websites admin page (admin/wladdons_settings/addonnoticetype/) and create the noticetypes you want. The field send_default defines the default value for AddonNoticeUser.shouldsend
  2. As soon a user enters the according page in his profile, the noticetype/user relationships are created

The 2. point can result in many database entries though, because the database entries are created for all users who enters this page although this user have no add-on created. Looking at the add-ons-server database the user-id's are in the table uploaders so i am looking for a solution to filter the creation of noticetype/user relationships to only those users who really has uploaded an addon. I guess the field uploaders.user refers to the same user id as on the website?

@frankystone
Copy link
Contributor Author

This is how it looks like for user who has no add-ons:
addon_settings_2

And for a user who has uploaded add-on(s):
addon_settings_1

To distinguish between general notice types and notice types for add-on authors the model has an additional field called Author Related Default. The Admin page for creating new notice types looks like this:
addon_admin

@Noordfrees
Copy link
Member

Noordfrees commented Feb 1, 2022

I added a couple of notices on alpha but one appears in the wrong category?

grafik
grafik

Translation Issue should appear under Notice types for Add-On authors not under Notice types for players

@frankystone
Copy link
Contributor Author

Can you look again?

@frankystone
Copy link
Contributor Author

sorry, my change was not sufficient

@frankystone
Copy link
Contributor Author

frankystone commented Feb 1, 2022

Now it should work... Please try again
My list comprehention was wrong, but found a better way anyway.

@Noordfrees
Copy link
Member

👍 Looking good :)

@frankystone frankystone mentioned this pull request Feb 2, 2022
@frankystone
Copy link
Contributor Author

superseded by #374

@frankystone frankystone closed this Feb 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants