You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@sepehr-dh99 suggested adding a "Status" field to the CrowdfundCampaign records in the database to track whether the campaign is active or disabled. This might seem like a good idea, but there is a design flaw with this approach.
Commands like Crowdfund (or similar systems like Zealy) are based on having one active campaign at a time. If we have more than one campaign, the question becomes: which one should we choose? Adding a "Status" field won’t help, because we could still have multiple active campaigns. We might think of using the last active campaign, but this is not a good solution.
Another idea is to change the frontend to show all active campaigns, but this would make the frontend more complicated. The user would need to select a campaign first and then choose the package. It seems better to keep the frontend linked to only one active campaign (or none).
So, the solution should be:
There should be either one or no active campaigns at any time. If there is no campaign, the command should not be active.
Another issue is that we might need to test the campaign in staging mode. For this, we would need to add a campaign that only moderators or staging bots can access, but not production bots.
So, the solution can be rewritten as:
There should be either one or no active campaigns at any time for a specific bot. If there is no campaign, the command should not be active on that specific bot.
One way to solve this is to define the active campaign as a session setting for each bot. This would allow production bots to have no active campaign, while staging bots can have an active one. The question then is: where should we define this session setting? We could add it to the configuration file, but this would require manual changes.
A better solution is to store the session setting in the database. Once the configuration is set, we can retrieve the values from the database. This setting can be modified using moderator commands to help manage active campaigns.
P.S.
The author of the Zealy campaign likely faced the same issue but solved it in a simple way: by deleting the old record from the database. This also works!
The text was updated successfully, but these errors were encountered:
"Prevent more than two campaigns from having active statuses."
This approach ensures that whenever a new campaign is created, the system checks for any existing active campaigns. If an active campaign already exists, an error is returned.
@sepehr-dh99 suggested adding a "Status" field to the CrowdfundCampaign records in the database to track whether the campaign is active or disabled. This might seem like a good idea, but there is a design flaw with this approach.
Commands like Crowdfund (or similar systems like Zealy) are based on having one active campaign at a time. If we have more than one campaign, the question becomes: which one should we choose? Adding a "Status" field won’t help, because we could still have multiple active campaigns. We might think of using the last active campaign, but this is not a good solution.
Another idea is to change the frontend to show all active campaigns, but this would make the frontend more complicated. The user would need to select a campaign first and then choose the package. It seems better to keep the frontend linked to only one active campaign (or none).
So, the solution should be:
Another issue is that we might need to test the campaign in staging mode. For this, we would need to add a campaign that only moderators or staging bots can access, but not production bots.
So, the solution can be rewritten as:
One way to solve this is to define the active campaign as a session setting for each bot. This would allow production bots to have no active campaign, while staging bots can have an active one. The question then is: where should we define this session setting? We could add it to the configuration file, but this would require manual changes.
A better solution is to store the session setting in the database. Once the configuration is set, we can retrieve the values from the database. This setting can be modified using moderator commands to help manage active campaigns.
P.S.
The author of the Zealy campaign likely faced the same issue but solved it in a simple way: by deleting the old record from the database. This also works!
The text was updated successfully, but these errors were encountered: