Articles Idea: Category-Based Permission Model

Shadowdare · July 2015

This discussion was created from comments split from: Articles Application. Article Categories.

rbrahmson · July 2015

I just installed the Articles application to try it out. Seems like the permission model is set on the entire application, not by category. In our implementation we use category permissions to separate different types of audiences which are not allowed to access content out of their roles - a setup that works fine with discussions (each discussion category is set with its own permission).

Can this be applied to Articles as well? Otherwise the security requirement of separation of "communities" won't allow us to use this application.
Thanks for your work so far!

Shadowdare · July 2015

@rbrahmson, there is actually a request for this feature that someone made in the GitHub repo related to getting a category-based permission model coded into Articles already, so this is a feature that has been on the plate of things to be considered.

Before considering this feature, I'll be releasing Articles v1.1.0 this week first with all the changes that have been made in the development code on GitHub so far, along with a "similar/related articles" feature added in.

Right now, Articles is pretty handy to have with the public permission model for news/public blog websites, which is what most users are hosting. Changing the permission model would require adding and modifying a lot of code, so ideas and planning should be made in another discussion, which I'll create right now by splitting this discussion, since the topic has changed.

As a side note, for your security requirement concerning separation of "communities" and for websites that require more flexible category-based permissions for Articles, what advantages does Articles offer compared to just using discussions in Vanilla?

Later on, a proposal could be drafted up on how a category-based permission model could be implemented and detail use cases later on whilst getting other people's input if this feature were to be considered.

rbrahmson · July 2015

Articles are inherently different than discussions as you expressed clearly in the application description. The issue for us is to have it integrated as smoothly as possible with the main discussion model.

Theoretically you could have developed this using the standard discussed model with special treatment for discussions marked as "articles" (similar to QnA, polls, etc.) and then the security model for categories would have been built in (but of course you would had other hurdles to deal with). I'm too unfamiliar with Vanilla to say one way or the other.

At the end of the day our use of categories permission based model allows us to use one site for multiple different audiences - easier to administer and using unified branding.

Shadowdare · July 2015

It is true that the discussion model can be extended via applications and plugins to add new types based on discussions that could be handled by addons as some plugins currently do. Addons that do so require a dependency on the Vanilla application being installed and enabled. Due to articles being different than discussions in nature, this dependency isn't good to have.

This brings up another point that a lot of code in Garden, the underlying framework of Vanilla, work only when the Vanilla application is enabled. This is expected since people download Vanilla Forums to use the forum features and not just to use an application like Articles and then probably enable the forums later on. Meanwhile, a rewrite of Garden has started as an independent framework, but that project will take a while to come about.

I've discussed the idea of extending the discussion model to implement key article/blogging management functionality with other developers including @hgtonight and @peregrine before I developed Articles.

I actually have developed numerous addons using different concepts to implement article/blogging management functionality and tested those out on a live Vanilla Forums installation. I also looked into plugins that extend discussions to have blogging capabilities, such as NillaBlog and BlanderBlog, and looked at them as the basis for the following concepts.

On one website, I used WordPress for the blogging front-end. SSO wasn't tightly integrated enough for me to use, and Vanilla runs on the same site, so I looked into plugins, such as Glue by @Linc, for some integration features. I have included Vanilla functions in WordPress and was able to include some theme elements such as modules from there and also have it create discussions to be used as comments when WordPress posts are created. Synchronization between WordPress post/comment statuses and discussions (closed for comments) could have been implemented, too. There were some performance issues and WordPress is bloated and becoming a mess, in my opinion.

Alternatively, I ran WordPress as a back-end system for composing articles only and created an application in Vanilla that had fetched posts with the proper business logic applied to do so. Unfortunately, having the two systems separate is not as good as having everything in one front-end interface, so that each author can have a more streamlined experience.

In any case, this application was pretty neat because it would be able to output WordPress posts in the Vanilla theme itself and fetch templates from the Vanilla application to display the comments. WordPress would still have the login integration and create discussions with a custom type called "article." Discussions with this type were hidden from the discussion list and then outputted separately on a new "articles" controller.

The convenience with this concept is that functionality that is present in Vanilla discussions and comments are supported. For example, if the Yaga application were available back then, I'm sure it would run just fine out of the box with this concept. Custom themes wouldn't have as much custom CSS to write due to having mostly the same functionality as discussions. The same thing goes for the comment model with Vanilla's social sharing, Quotes, reporting, and other various plugins.

Another advantage is the ability to use the category-based permission model that is already in Vanilla. If someone wanted to avoid a dependency on having Vanilla enabled, but there was no way around it, then I guess they could only have categories with proper permissions set for storing "article" discussions.

This could have been taken further and probably could have had key article management functionality, such as publishing workflow, author meta, special fields for thumbnails and images, and guest commenting implemented and added columns to the Discussion DB table named "ArticleStatus," "ArticleThumbnailMediaID," and so on.

This concept became a bit convoluted when it came to things like:

Should the discussions with the "article" type be filtered out of the "Discussions" index for user profiles and then displayed in a separate tab? If so, should the view for the discussions index be copied and modified, or without modifying any core Vanilla files, is there an event handler in place that would allow modifying the "get discussions" query or the final result set before the pager is calculated and before it is displayed?
Should categories designated as "article categories" be hidden from the post form? If so, then should a new compose controller be created to handle posting to the categories? What would happen if those categories were reverted to the standard mode?

Back to the Articles application: it's not dependent on the Vanilla application being enabled. Everything is integrated into one framework. Features such as threaded commenting is one example of something that should be separate from the Vanilla comment model in most cases. Due to articles being a different content type than discussions in nature, being totally decoupled from the Vanilla application is beneficial in terms of scalability.

This is slightly off-topic from possibly implementing a category-based permission model for Articles down the line, but I just wanted to share conceptualizations that I've come up with in the past as an interesting read to show how they worked out and how extensible Vanilla Forums is.

I'd like to know what other developers here think about these concepts.

R_J · July 2015

Thanks for that very insightful summary! I really enjoy to read about the thoughts behind design decisions. While I refuse to seriously be called a developer, I'm still someone who is writing code and is thinking about how something should be implemented best. So here are some thoughts of mine...

When I first got to know about the programming language Ruby, I was excited because of the "everything is an object" philosophy which implements, that everything shares a common base. The bigger such common base is, the more useful it is. And if you extend the base object, you extend the functionality of everything! Great. That's why I would prefer to always use the biggest common base.

You have decided to recreate articles from ground on up, even including the comments. That results in an independent application which is great if you do not want to couple it with a forum, but has disadvantages, when you want to streamline forum and articles.
I have not tested it, but I guess that plugins that enhance discussions and comments will not enhance articles and article comments. In worst case, an existing plugin uses a mixture of base- and discussioncontroller/commentcontroller hooks so that the base hooks might influence the articles app while the other hooks do not.

So I would prefer to rather see addons extending what is already there in order to get synergy effects wherever possible.

PS: I can't wait to see a Garden framework with a decoupled dashboard and a decoupled forum! That will be awesome! Only recently I was searching for a framework with a nice dashboard that you can hook into and reading your text now makes me think of simply using Vanilla/Garden and ignore the dependencies.

rbrahmson · July 2015

Thanks @Shadowdare for such an elaborate explanation. I understand your design decisions but for my own purposes I would have liked to see a more integrated solution.

But from your article I understand that the term "integrated" is a but fuzzy - integrated with what? You explain how Garden and Vanilla are different, but to be honest for me and probably for 90+% of the users there is no difference - it's all in one black box. Not everyone is a developer...

I would venture to say more -- that it would have been really great if the discussion/comment in Vanilla (the one black box for the larger community) would had a built-in facility of multiple discussion types. That way another type could b created by a plugin (Q&A, Polls, articles, problem-tracking, events, and more) that would still leverage all the things the black box offers and works smoothly with everything else.

Right now, it seems to me, every plugin developer adds their own stuff independently. It can and is done, but I believe that what I described is easier and more powerful,

And it might be possible (I'm not sure) that the above could be done by a plugin that facilitates the different discussion models.

Anyway, thanks for your thorough explanation.

Bleistivt · July 2015

@Shadowdare I have utilized the standard discussions as a comment system for a gallery-type plugin (which I'll release very soon, once 2.2 is out).

My goal was complete integration with vanilla (the forum) and dashboard.

I pretty much duplicated the mechanism used for the embedded blog comments, which works smoothly.
However the types of comments, people leave under images, are different from normal forum comments.

Short comments like "love it!" are much more common and creating a new discussion for each of those will quickly flood the main discussion list. It is also confusing for users to see their comments in different contexts.

Hiding those "comment discussions" from the main discussion lists is still easy, but it can't be prevented that they see discussions in the normal view. It will leak through notifications, etc.
This necessitates that the discussion post shows the original image, so that the comments don't appear out of context.

tldr This integration thing creates a lot of unforeseen problems, even if you are not dealing with category permissions.

that it would have been really great if the discussion/comment in Vanilla (the one black box for the larger community) would had a built-in facility of multiple discussion types.

@rbrahmson It does have that. This is what the QnA plugin is doing and other plugins could do it to. Afaik the approach here was to build a blogging application that can be used independently from the forum.

If you need discussion posts as "blog entries" with forum comments, maybe look into NillaBlog or the more modern BlanderBlog plugin.

Shadowdare · August 2015

Thanks for sharing thoughts, everyone. I have been considering a new way to implement articles completely after reading everything said in this discussion so far.

Vanilla discussions are simpler than articles and the crucial functionality of the article model (name field, body field, profile tab views, etc) exists in the discussion model; therefore, discussions could be extended to add special article composition functionality, including:

The ability to upload and set a thumbnail image
Add excerpt/teaser text
Manage publishing states in the case that there are contributors and editors managing the flow and revisions of content
Assigning an attribution user to be displayed as the author of an article separately from whoever created the post
and so on...

Almost everyone who downloads Vanilla Forums will have the Vanilla application enabled. Furthermore, a lot of the code is coupled to Vanilla in the core library/underlying framework. Articles would benefit from being rewritten to extend Vanilla discussions as a base model by setting their "Type" property to "article" and incorporating features from there rather than a totally independent implementation all together. Doing so would also make certain things look cleaner and more friendly for users, such as article comments being able to be shown under the same "Comments" profile tab instead of having a separate tab called "Article Comments."

This could be done by adding new columns to the discussion table in the database like "ArticleStatus," "ArticleThumbnailID," and so on, and a new column to the category table like "IsArticleCategory." We could take a look at how the QnA and Polls plugins do this. Discussions with the "article" type could be hidden from the main discussions list (this could be made into a config setting) and shown in a new controller index.

There are also little things to look out for as well such as how to differentiate and update the discussion count to not include the article count, if it is implemented to be displayed as a separate type to users, in which case "Articles" could be shown on a separate tab in user profiles apart from the "Discussions" tab.

For instance, articles would benefit from the category-based permission model that Vanilla incorporates and applications, such as Yaga, and plugins, such as FileUpload, Quotes, social media sharing, that add functionality to Vanilla would work fine if discussions were used as the base model. As an example, a badge like "first article you edited" could be added to the Yaga application to be rewarded when a discussion with the "article" type is edited. On the other hand, some functionality may not be able to be implemented so easily, such as threaded comments; however, this is not an essential feature to have.

If the articles application were rewritten to be dependent on Vanilla and a user doesn't want to enable forum functionality, they'll have to keep Vanilla enabled, but they could designate categories for article publishing only, if it were designed that way, as a workaround in this case. Additionally, a rewrite would allow for the Articles application to be coded with the new Vanilla coding style from the beginning.

We could always create a new independent implementation for articles if and when development of the new Garden framework is finished if we choose to go down this route.

What do you all think?

mtschirs · August 2015

I see three options:

Articles remain independent, but as long as Vanilla is installed a new article automatically comes with a related discussion e.g. in the category the article is published in. I have seen this apporach on reputable news websites.
Using the embedded comments feature of Vanilla for articles.
Your suggestion, making the article a special discussion type.

As long as you keep the /articles controller so we can build a decent entry page / portal showing just articles, I am ok with it.

Complete "independence" of articles from vanilla - why? Vanilla provides all the tools for discussing articles and moderating article comments, why not reuse it? It would be bad practice to dublicate all that code. One could think of offering a barebone articles app without any commenting and comment moderation features though (see option 1.).

rbrahmson · August 2015

Thank @Shadowdare for sharing your thoughts and even more for considering the change. After reading your analysis I am more convinced than before that articles should be a discussion "type" for all the reasons described as well as a "killer" one - as Vanilla gets extended every new version discussion-based articles plugin will likely be more compatible than a separate application where you may need to duplicate new functionality or worse abandon further development (as is understandable with a volunteer model).

On a somewhat related matter, in the past I suggested that a generalized discussion "type" feature be implemented and gave the examples of QnA, events, polls, etc. Could have added Articles too... I'm not sure my notion was explained well because @Bleistivt responded that it's already there. I was thinking more of an admin-like front end form that let the developer/admin enter the type parameter, columns to add, permissions required and so forth- things that would make plugin writing simpler (moving "housekeeping" from code to definition forms).

Going back to the point, my vote is for a discussion-type Articles.

hgtonight · August 2015

I am really torn on this.

I like the idea of a lightweight blogging software on top of Garden.

On the other hand, maintenance would be way easier if you built it on top of the discussion model.

Just take care of adding extra columns to the discussion table.

rbrahmson · August 2015

@hgtonight - I understand that from a coding/architecture point of view there is a difference between Garden and Vanilla. But all software is written in layers and with rare exceptions everyone using Garden is also using Vanilla and sees them both (actually more that there two - we see everything that is downloadable with it) as one universe that is supposed to work seamlessly together. And if that is an admin's point of view (pointing at myself) you can imagine that the end user point of view is even more encompassing.

I am sure @Shadowdare is capable of delivering an Articles "thing" (I hesitate to qualify it in any recognizable term until he decides how to do it) in ways that are fully compatible and seamless. But in the long run, when some new plugin or a new version of the "Vanilla" (in its expansive meaning) comes out, I wish to have them all working without the need for @Shadowdare or anyone else to make it work, and without a large learning curve for the forum users.

Perhaps the original intent of the developers of Garden and Vanilla was different, but I believe that the market has spoken and to the market at large this is one great piece of software.

Shadowdare · August 2015

I'm currently writing up a conceptualization document to see how Articles could be rewritten to integrate better with Vanilla.

Here's a question about the controller events. A lot of plugins hook into events using a specific controller name like DiscussionController_EventName_Handler($Sender). If I were to create a new controller called ArticleController, plugins would have to be updated to add some hooks to support the new controller name, even if it used the same view from Vanilla as DiscussionController. Perhaps it would also be possible for the application/a plugin to retrieve the plugin instance and invoke methods from there.

I haven't worked with routes in Vanilla in a while. Say I want to create a new route in the format of /article/{year}/{article_urlCode}. Any users that open the URL of the discussion with a type of article should be redirected to the new article route, and the canonical URL of the page should be updated to reflect the new route as well.

Would it be possible to make use of the DiscussionController to achieve this route, either by creating a new method via DiscussionController_Article_Create or creating an ArticleController in the application that will call methods of DiscussionController, so that plugins that use DiscussionController for hooking into events work?

If a new route could be created to just link to the same /discussion/{id:int} (index method) that would have the most support for plugins. In this case, certain views/view functions could just be modified to add article features.

rbrahmson · August 2015

@Shadowdare said:

... If I were to create a new controller called ArticleController, plugins would have to be updated to add some hooks to support the new controller name...

My recommendation is not to do anything that would require plugin developers or admins to have to make changes to support Articles. The best solution is to have it all work out of the box (even if it means that multiple plugins have to be installed - as long as they work out of the box).

That would achieve the highest acceptance of Articles and highest level of additions that work with it.

hgtonight · August 2015

@Shadowdare said:

Here's a question about the controller events. A lot of plugins hook into events using a specific controller name like DiscussionController_EventName_Handler($Sender). If I were to create a new controller called ArticleController, plugins would have to be updated to add some hooks to support the new controller name, even if it used the same view from Vanilla as DiscussionController. Perhaps it would also be possible for the application/a plugin to retrieve the plugin instance and invoke methods from there.

You could explicitly set the class name right before render to discussion controller (or the appropriate "approximate" controller). So: $this->ClassName = 'DiscussionController'; $this->Render();.

Shadowdare · August 2015

@hgtonight, thanks! That sounds like it would do the trick. I'll give that a try. I'll also try to reuse as many Vanilla views and design elements as I can, unless a need for a custom view comes up.

How do you all think CountDiscussions for categories and users should be handled? Assume that a category can be set to an "article category" via the AllowedDiscussionTypes column or something like that, and that discussions with the "article" type could be hidden from the discussions index. Should the count functionality be kept the same and the output just be modified in places around the forum?

rbrahmson · August 2015

I think that the concept of the discussion count already morphed into "the count of every new discussion regardless of its type" and therefore whoever wants to see the count of the original type discussion (namely,not questions, not events,not polls,not articles,etc.) already "lost" their count.

Probably the type-specific count is better displayed in the side panel (similar to the way zero-comment plugin works).

R_J · August 2015

I think that the articles addon serves as a CMS and an article is a more prominent content that can only be created by privileged members.
So I would count them separately them from discussions (and also give them their own entry in the profile). Article comments though, are only comments which I wouldn't handle in any specific way.

hgtonight · August 2015

I would track them separately but not mess with the discussion count.

So all discussions would be listed in the count, but you would also track just article type discussions. This way you stay out of the discussion count but still track the "special" article discussion count.

Shadowdare · August 2015

Setting the $this->ClassName property in a new controller does the trick and lets plugins that hook into events in the DiscussionController do their job. Thanks, @hgtonight!

Those are all solid ideas for how the discussion and article counts could be handled. I'll look into it.

I've been trying to make use of the built-in discussion type feature like the QnA plugin does and put together this class.hooks.php file to test it out:

<?php
/**
 * Articles' event handlers.
 */
class ArticlesHooks implements Gdn_IPlugin {
    /**
     * Add the article discussion type.
     *
     * @param Gdn_PluginManager $sender Event sender.
     * @param array $args Event arguments.
     */
    public function base_discussionTypes_handler($sender, $args) {
        $args['Types']['Article'] = array(
            'Singular' => 'Article',
            'Plural' => 'Articles',
            'AddUrl' => '/post/article',
            'AddText' => 'Compose an Article'
        );
    }

    /**
     * Add the article form to Vanilla's post page.
     *
     * @param PostController $sender Event sender.
     */
    public function postController_afterForms_handler($sender) {
        $forms = $sender->Data('Forms');
        $forms[] = array('Name' => 'Article', 'Label' => Sprite('SpArticle') . T('Compose an Article'), 'Url' => 'post/article');
        $sender->setData('Forms', $forms);
    }

    /**
     * Create the new article method on post controller.
     *
     * @param PostController $sender Event sender.
     * @param string $categoryUrlCode URL code for current category.
     */
    public function postController_article_create($sender, $categoryUrlCode = '') {
        // Create and call PostController->Discussion()
        $sender->View = PATH_APPLICATIONS . '/articles/views/post/article.php';
        $sender->setData('Type', 'Article');
        $sender->discussion($categoryUrlCode);
    }

    /**
     * Override the PostController->Discussion() method before render to use our view instead.
     *
     * @param PostController $sender Event sender.
     */
    public function postController_beforeDiscussionRender_handler($sender) {
        // Override if we are looking at the article URL
        if ($sender->RequestMethod == 'article') {
            $sender->Form->addHidden('Type', 'Article');
            $sender->title(T('Compose an Article'));
            $sender->setData('Breadcrumbs', array(array('Name' => $sender->Data('Title'), 'Url' => '/post/article')));
        }
    }

    /**
     * Run any setup code that a plugin requires before it is ready for general use.
     *
     * This method will be called every time a plugin is enabled,
     * so it should check before performing redundant operations like
     * inserting tables or data into the database. If a plugin has no setup to
     * perform, simply declare this method and return true.
     *
     * Returns a boolean value indicating success.
     *
     * @return boolean
     */
    public function setup() {
        return true;
    }
}

This does let us use the PostController to handle article creation, which is good.

This let's us set the AllowedDiscussionTypes property of a category via the "Add/Edit Category" page. By the way, there is a column in the Gdn_Category table named DefaultDiscussionType in Vanilla 2.2, but it currently isn't being used anywhere in the Vanilla code.

The default behavior may not be suitable for our use at this point because all categories don't have the "this category has custom permissions" setting checked, meaning that both discussions and articles can be posted in the category, so the PostController form would list all categories. This seems like it would get messy, but we can probably code in something to workaround this and still make use of the built-in discussion type feature. Anyone have any ideas for this?