[BUG] Conflicting permissions between frontend and backend on some resources

[Aadesh-Baral]

Description: Currently, the API allows organizational managers to perform actions such as creating, updating, and deleting interests/categories, licenses, and campaigns. However, these capabilities have been restricted to system administrators in the frontend interface. It's worth noting that in practice, these actions are typically carried out by system administrators exclusively. Additionally, there is currently no mechanism in place to track and record the creators of these resources, which could provide valuable information.

Suggested Solution: To address these concerns, i propose the following changes. For campaigns, i suggest opening up the ability for organizational managers to create, update, and delete campaigns. However, to maintain a degree of structure, i recommend enforcing a rule that requires at least one organization to be attached to a campaign. As we already have functionality to attach multiple organisations to a campaign in the backend we need to implement it in the frontend too. For interest/categories and licences we can just store the creator of these resources.

cc @ramyaragupathy @SColchester

[SColchester]

Fantastic. It would be great if organization managers should create campaigns, at the moment they need to complete a Google form at then an admin manually creates the campaign, but this is an unnecessary time-sink.

[Aadesh-Baral]

Might be related to #583 for campaigns.

[Aadesh-Baral]

I think we also need to store more metadata about the campaigns. Currently we only have campaign name stored. Additional metadata could be:

• Impact areas
• Affiliated organizations
• Description
• Countries (Can be extracted from projects attached)
• Image (Not mandatory)
• Default Hashtags (Which will be copied over to attached project's default changeset comment) so that we can extract campaign statistics.

cc @SColchester @ramyaragupathy

[SColchester]

@Aadesh-Baral yes this metadata would be great to store, I feel that based on the projects in the campaign, most of this data could be automatically read:

• if the 'Impact Areas' you refer to is the same as 'Categories' (e.g. Water & Sanitation) these would be great read automatically from the projects in the campaign.
• Affiliated organizations could also read automatically from the projects in the campaign, e.g. if there was a 'Vaccination Botswana' campaign with projects in it from HOT and German Red Cross then the campaign could automatically list HOT and German Red Cross
• Description, this would have to be a free text field in the Campaign edit page, I'd recommend that this is also not mandatory, some campaigns are described entirely by their name. Would be interested to hear where you think this would be displayed?
• Image, interested in this but curious to hear where you think the image will be displayed?
• Default Hashtags, really like this idea of copying across, but would need to think carefully about how these are displayed to project manager looking at a single project so that it is clear to them where they can edit the 'Campaign hashtag' they might be seeing

[Aadesh-Baral]

@SColchester, I agree with all the points you've made regarding fetching metadata from attached projects:

1. Yes, when I refer to "Categories," I mean "Impact Areas." While analyzing campaigns, I came across one campaign containing more than 1000 projects and another with more than 900 projects within it. This could potentially impact performance, as querying over 1000 projects to compile a list of categories could become a concern. However, this situation might be more manageable for campaigns with fewer projects.

2. In my opinion multiple organizations could be involved in managing a campaign, not just the one creating the project (I think you are expert managing campaigns and you can verify if this case exists). Managers from these organizations should possess the necessary permissions to modify and delete the campaign. They should also have the capability to associate projects and other organizations with the campaign.

3. As there isn't currently a dedicated page to view campaign details for general users, addressing issue #583 and creating campaign pages might be important. This is the context where I envision the display of campaign images and descriptions.

4. Presently, we don't allow Project Managers to delete the default changeset comment, which is automatically populated after project creation, as seen in instances like "hotosm-project-14986." Similarly, we can consider disabling the removal or editing of hashtags populated from attached campaigns.

[SColchester]

@Aadesh-Baral agree on your second point, would be great if several organizations could manage a campaign together: including ability to modify and delete the campaign, to associate projects and other organizations