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

1 - Developer can disabled tchat tools in settings #161

Merged
merged 3 commits into from
Oct 13, 2022

Conversation

YglesEyes
Copy link
Contributor

Add in settings

{
  "public": {
    "disabledFeatures": ["textualCommunicationTools"]
  }
}

@YglesEyes YglesEyes requested a review from Donorhan October 10, 2022 16:28
@ramnes
Copy link
Contributor

ramnes commented Oct 11, 2022

#139 architecture doesn't work for what you want to achieve? We could extend it with a dropdown for all textual communications tools.

@ramnes ramnes added the enhancement New feature or request label Oct 11, 2022
@YglesEyes
Copy link
Contributor Author

The goal is to have a more global restriction for the server and not only for a team, for the moment it seems easier to use flag instead of rework the code to have optional modules.

@ramnes
Copy link
Contributor

ramnes commented Oct 11, 2022

Okay, then we probably want to streamline the way these permissions work because it seems to me that it's going all over the place.

I would suggest a common list of modules across the different types of feature flag systems and a generic way of toggling these modules at each level (guests / level / server), with a config that would look like this (or anything really):

{
  "features": {
    "useMessaging": {
      "enabled": true,
      "guestEnabled": false,
      "levelConfigurable": true
    },
    ...
  }
}

What do you think?

@ramnes
Copy link
Contributor

ramnes commented Oct 11, 2022

At the very least we should use the same format and module names, i.e. here we should replicate how guests is structured:

{
  "features": {
    "useMessaging": false
  }
}

rather than

{
  "disabledFeatures": ["textualCommunicationTools"]
}

or it will be a nightmare to streamline later. :(

@YglesEyes
Copy link
Contributor Author

Like it, it is more generic and configurable, i don't have time yet but I will implement it ASAP

@YglesEyes YglesEyes merged commit 87788b8 into master Oct 13, 2022
@ramnes ramnes mentioned this pull request Oct 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants