Add an event and action category per collective

[berleant]

Acceptance Criteria

• [x] Add an event and action category per collective
  • Events and Actions are sub-categories of the collective categories
• [x] Restrict permissions of events to only members of the collective + administrators
• [x] Allow all Debt Collective members to see and participate in discussions about Actions; only admins can create
• [x] Fix up discourse-node-api
• [x] Testing

[berleant]

I'm actually not so sure about this--will think about it

[sarayourfriend]

IIRC there's at least something where sub categories cannot have less restrictive permissions than the parent category, in which case the events could live under the collective category but the actions could not. On the other hand, we could change the model slightly and add a discussion category to each collective category and make the collective and its actions sub category open with the discussion and events sub categories being closed. The ACL would look like this:

Collective (Parent Category) - PUBLIC
  Actions (Sub category) - PUBLIC
  Events (Sub category) - Admins + collective members only
  Discussion (Sub category) - Admins + collective members only

Even it it's not true that sub categories cannot have less restrictive permissions than parent categories this might be a better model over all. Might be easier to pull data from each collective this way. Wouldn't be a big change to our seed script, I don't think.

[sarayourfriend]

Would topic templates for events and actions mean we wouldn't have to do the guided event creation?

At least the templates could be prioritized for May and a guided/wizard type thing could be created after, yeah?

[berleant]

I was reading abut the plugin. I don't think we need to make subcategories. We just have to enable the events plugin for each collective, and add a link at the top to all the meetups and all the actions.

[sarayourfriend]

How would we restrict events and actions differently?

[berleant]

We want any user to be able to see/participate in an action?

Anyway, I think there are better ways to implement permissions. Using categories is a pretty clunky way to do that. The discourse-events plugin has functionality for restricting event creation to admins-only, so we should look at how that plugin does it.

[berleant]

we could automatically tag actions with a "global" tag or something, to allow everyone to see/participate in them

Edit: this would not work as discourse will not set permissions for tags. Official recommendation is to use categories for permissions.

[sarayourfriend]

And that will override the category's permissions?

On Sun, Apr 29, 2018 at 9:26 PM -0400, "Shoshana Berleant" notifications@github.com wrote:

we could automatically tag actions with a "global" tag or something, to allow everyone to see/participate in them

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[sarayourfriend]

Well, the idea behind the categories was that it silos the information into some easy to manage categories. Any admin can understand that if a member wants to be in a collective you just add them to the group. But if there's a better way and we can implement it in time then let's do it! Though I suspect the events plugin does this using normal Rails ACL. Curious to see what you find.

And yes, one of the requirements for actions is that they are open. If the global tag overrides the categories permissions then that would be fine as long as you can extend the events plugin.

[berleant]

maybe actions shouldn't be in categories? The whole point of collectives-as-categories is to limit who can see what, right?

[berleant]

Looks like subcategories don't inherit permissions from their supercategories, which is surprising: https://meta.discourse.org/t/subcategories-do-not-inherit-permissions-from-parent-category/17174

[berleant]

Ah, I remember why we wanted Events to be in their own categories--because "Topic Templates" are defined per category, and we want to use the topic templates as a step toward a guided event creation process.

[sarayourfriend]

The other motivation was that events and actions need to be related to a collective and the easiest way to do that is to have them contained within the collective category. But to manage the permissions separately we need the sub category. At least for Actions. Maybe we don't for Events but it seems short sighted to not split these things into sub categories when it only enhances our permissions model and gives us greater access/ability to select data from discourse's API. After all, it's trivial to retrieve a list of topics for a category. Would be great for other services to be able to efficiently say give me all the events for the student debt collective without having to consider the specific implementation details of the events plugin.

[berleant]

btw I'm mostly just collecting/recording thoughts, so if it seems terse don't take that negatively.

@marcondag Writing a filter for topics is very simple--in fact I've already done it while I was exploring earlier today.

It's not necessarily an enhancement to the permissions model, if it adds complexity that we don't (will never?) need.

The existence of the subcategories is visible to users, and making a UI decision based on programmatic needs feels weird to me. But perhaps it is a UI enhancement?

Adding identical subcategories to each collective isn't DRY, but a little dampness is probably ok, as y'all have pointed out to me in the past.

re: enhancing permissions model, that is an excellent point. Very important for Actions. For Meetups, though, it isn't necessary, because our permissions for meetups and discussion are the same, as far as I know, but that leads to the question:

Do you recall the permissions scheme for meetup and action creation? It appears that we did not document those permissions--or are they same as reading/participating?

(for future reference: turns out one can define topic templates by url, so they aren't necessarily bound to categories: https://meta.discourse.org/t/what-are-topic-templates/38295)

I'm leaning toward one Actions subcategory per collective, and no Meetups subcategories.

[berleant]

https://github.com/debtcollective/discourse-seed/pull/9

[berleant]

:( subcategories with more permissive permissions than their parent categories aren't supported?

https://meta.discourse.org/t/child-category-seems-to-inherit-part-of-the-permissions-in-the-parent-category/84493/3

[sarayourfriend]

Yes, I think this is why I suggested having discussion in its own subcategory so that each collective can be visible to all and then just events (or actions, I forget which is hidden) and discussions be hidden while the other is visible.

This would also solve the problem of figuring out where to link people for the collectives in the header. This way they would see at least the collective and the one publicly visible subcategory even if they're not logged in/a member of that collective.

[berleant]

This would also solve the problem of figuring out where to link people for the collectives in the header. This way they would see at least the collective and the one publicly visible subcategory even if they're not logged in/a member of that collective.

Excellent point!

Yes, I think this is why I suggested having discussion in its own subcategory so that each collective can be visible to all and then just events (or actions, I forget which is hidden) and discussions be hidden while the other is visible.

Yeah, I'm annoyed that the other source I found on discourse meta implied that it was perfectly possible. I swear I even tested it because it was such an unexpected behavior. Edit: I tested it again just now, and yeah, the app behaves as if there is no restriction.

Someone else posted in this thread

the only restriction is that all users with access to subcategories must also have See permission on the parent category, as you need to know that the parent category exists in order to name the subcategories correctly.

So it's only the "see" permissions that cannot be less restrictive. So preventing topics from being created in the collective category without being in a subcategory should be :thumbsup:

I'm going to make this a new issue because this one has gotten really long.

[berleant]

Wait, but @annlarson and Laura wanted the existence of the other collectives to be hidden, right?

[sarayourfriend]

That's not possible if actions are public, right?

[berleant]

I suppose actions could be public, but their relationship to other collectives could be hidden?

[berleant]

Discussed in the slack with project manager. I'l lbe making a new ticket for this.

[berleant]

https://github.com/debtcollective/parent/issues/163