Rights and Permissions Workgroup

saccade · 2006-04-09 18:59:11

sorry, I have such a lot of work to do (doing my job, paying bills) and a lot of very urgent tasks came up, that I rarely find time to develop thoughts so far into a proposal. It’s a great pity.

But it is still in my heart and I am keen for free time to finish!

hcgtv · 2006-04-09 21:27:16

saccade,

No need to apologize, life has a way of getting in the way at times ;)

I’ve read the whole thread and appreciate the thought that has gone into this discussion. I’d much rather wait than use something else and have to deal with URL’s changing, etc.

sonoramark · 2006-05-25 19:40:46

My apologies if the issues I raise here have been covered already. I’ve tried to read through this fascinating thread as thoroughly as I can, but it’s a long thread and I’m sure there’s information I’ve overlooked.

I’m fascinated, but not surprised, at how much a designer/programmer/author perspective dominates the discussion on rights and permissions. This is in contrast to a customer/user perspective. Let me explain:

I’ve worked for several companies, and I’m working on an endeavor now, where rights, permissions, and access control matter a great deal in a content management system. The last company I worked for had a particularly difficult time with MediaWiki, for example, which is a great, easy to use system, but very much embodies the Wikipedia philosophy of “everyone can do everything”.

Now, in talking to customers — real, live, paying, breathing people who want a CMS for various reasons — it’s clear that the #1 concern they have is not permissions, but privacy. In other words, their top request is a system that limits who can see what. They actually don’t care that much about who has permission to do what, since they believe — correctly, in my opinion — that social governance is as good or better than software governance in controlling what people are allowed to do.

But without controlling what people can see, a CMS is severely limited in its application areas. Here’s a typical example, taken from real professional life:

Company A wants a platform on which Engineering and Product Marketing can share ideas about what’s needed for the next version of their Foomatic software product. This platform needs to have a content area that only employees of Company A can see.
Product Marketing from Company A needs to be able to share certain parts of this content with customers, so they can do a proper requirements gathering process and in turn kick this back to Engineering in the form of a Product Requirements Document. So this platform needs to have a content area that employees of Company A and designated outsider can see.
When the next version of Foomatic goes beta, Company A wants a release area where they can make release notes and documentation available. So the platform needs to have a content area that is completely public.

Variations on this scenario happen all the time. The platform needs are something like this:

The owning organization of a content area needs a private area that only org members can access;
They also need a semi-private area where some content can be accessed by a limited but larger external group;
They also need a public area with unrestricted viewing access.

I don’t see that Textpattern has this kind of fine-grained access control right now, nor that this working group is thinking in that direction. That’s fine; Textpattern is still a great system with many uses. But it would be nice if this aspect of rights and permissions found its way into the discussion.

-Mark Stone

Walker · 2006-05-25 22:50:48

Sorry, but it doesn’t sound like you’re talking about content management. You’re talking about Document management. If a company is worried about who can see what … and we’re talking about users who can log in here, then you’re not talking about a content management system.

Content management systems should be concerned, on the user side with:

“Can this user edit this?”
“Can this user create this?”
“Can this user delete this?”
“Can this user create but not publish (or go live with) this?”

These are the user centered questions a CMS is trying to answer. Many CMSes answer the “edit” question with something like: “Yes, they can edit this but not that.” Where this and that can be anything from articles to design elements to pages that appear within the site.

sonoramark · 2006-05-25 23:03:24

Walker wrote:

Sorry, but it doesn’t sound like you’re talking about content management. You’re talking about Document management. If a company is worried about who can see what … and we’re talking about users who can log in here, then you’re not talking about a content management system.

A content management system is a fairly empty excercise if it isn’t also a content publishing system. And in fact, I’ve seen people describe Textpattern as more of a content publishing system rather than a content management system. Either way, when you move from management to publishing, the question immediately arises, “published for whom?” An ideal platform would allow for differentiation (access control) in answering that question.

Nor is this mere semantics or an idle intellectual exercise. I have an immediate product need for that kind of access control in a platform, and I’ve encountered a number of similar real, live, customer examples in the last several years.

Too much of the web assumes that content is either completely open for anyone to look at, or completely private behind the company firewall. In fact there is a very large class of cases in between, where one or more formal organizations exist at the center of a larger, informal community. In this context, there is often a need to be able to publish out selectively.

Not enough web publishing systems deliver this capability, and none that I’m aware of deliver it with Textpattern’s administrative ease of use.

-Mark Stone

squaredeye · 2006-05-25 23:27:19

sonormark,
i don’t see any difference between what you are suggesting and what you have said is either an all or nothing way of publishing content on the web.
It seems to me that the issue that you raise is primarily about organization of internal content, which is governed by passwords. This isn’t content management and here I have to agree with walker. However, I think this kind of functionality, the kind you speak of, is possible, given the route that we have been pursuing here, its only that the pages you describe would be governed internally via login, and the external pages would be, or could be, 100% open.

Thanks for your thoughts. its good to see alittle life in the thread. There has been a lot of work in here, and life, as saccade rightly aknowledges, takes precidence. This thread needs prayer. :)

Matthew

sonoramark · 2006-05-25 23:54:39

ma_smith wrote:

It seems to me that the issue that you raise is primarily about organization of internal content, which is governed by passwords. This isn’t content management and here I have to agree with walker. However, I think this kind of functionality, the kind you speak of, is possible, given the route that we have been pursuing here, its only that the pages you describe would be governed internally via login, and the external pages would be, or could be, 100% open.

OK, here’s a nuance I’m curious about: I can imagine various ways that articles could be access controlled. But what about sections? It may well be (in fact I can pretty much guarantee it) that a group would have sections and even categories that they would want to show up only for certain users. How feasible is this (a) in general, and (b) within the scope of what this working group is proposing?

-Mark Stone

hcgtv · 2006-05-26 00:48:01

sonoramark brings up a good point, who can see what.

With permissions on the backend, Textpattern can be used to build a community. Giving the newly online the capability to tag their content – for your eyes only – would surely induce their participation, ala Flickr.

We recently started a plugins request thread, in it we pledge interest and dollars towards our plugin of choice. What about doing the same for feature requests, I’ll ante up for a permissions system.

Walker · 2006-05-26 03:47:46

I’m not at all sure that these suggestions would be pushing textpattern in a meaningful or useful direction.

Document management solutions are made to aid process within a company. They allow for a certain amount of privacy that I believe is unnecessary or unneeded within textpattern. The secrecy built into these systems is needed because of the environment they are developed for. As for community building, allowing people to share things within a family unit or strictly with friends is a good thing, but I’m not sure that this is a goal of textpattern.

Going between a company’s internal documentation, how they share it with the consumer/user, and how they deal with certain information between people and company units is a question of process.

Textpattern can fill a certain place in this process well, but it should not try to do it all. Do one thing with excellence, not everything with mediocrity.

Last edited by Walker (2006-09-11 14:23:39)

Ace of Dubs · 2006-07-15 17:06:05

My Facelift Thread has spun out of control and crashed into this one.

Relevant Link

Check out post #116, bout halfway into it

Textpattern CMS

Textpattern CMS support forum

#157 2006-04-09 18:59:11

Re: Rights and Permissions Workgroup

#158 2006-04-09 21:27:16

Re: Rights and Permissions Workgroup

#159 2006-05-25 19:40:46

Re: Rights and Permissions Workgroup

#160 2006-05-25 22:50:48

Re: Rights and Permissions Workgroup

#161 2006-05-25 23:03:24

Re: Rights and Permissions Workgroup

#162 2006-05-25 23:27:19

Re: Rights and Permissions Workgroup

#163 2006-05-25 23:54:39

Re: Rights and Permissions Workgroup

#164 2006-05-26 00:48:01

Re: Rights and Permissions Workgroup

#165 2006-05-26 03:47:46

Re: Rights and Permissions Workgroup

#166 2006-07-15 17:06:05

Re: Rights and Permissions Workgroup

Board footer