Naming of document/required rights

Hi everyone,

in this proposal I would like to talk about the naming of the “document rights” or “required rights” feature.

For those who haven’t followed the topic so far: The background of required rights is that currently the rights of the “active content” in a page like script macros or skin extensions only depend on the last author. This makes it easy to accidentally remove or grant rights when the author or the author’s rights change. The idea of required rights is to improve this situation by explicitly specifying what rights a document has and doesn’t have. Editing would then be restricted to users with the specified right(s), and regardless of the last author, nothing in the document can have more rights than specified in the document. At least for now, the last author would still be relevant and checked, so denying rights to a user could still break content, but it would be much easier to detect. For backwards compatibility, there will also be a “legacy” state where the current behavior is maintained. Take a look at the design page for more details.

The question is now how to name these rights that you can set on a document that affect the rights that are available to scripts and other “active” content of the page. Historically, there is the “required rights” XClass that has this purpose for programming rights. I later suggested the name “document rights”.

Here are some pros/cons for both names:

Required rights

Pro:

  • the terminology has already been used in the same context in the past (see, e.g., XWIKI-6297)
  • the recently introduced required right analyzers are closely tied to this new concept and match in their naming
  • matches well that users are required to have these rights to edit the page
  • matches well that the page’s content requires these rights
  • the name is sufficiently different from existing rights

Contra:

  • I could imagine a future in which we remove the dependence on the last author of the document for granting in particular programming right as it seems very unnatural that, e.g., an extension depends on the rights of the user who installed the extension. In that case, it seems unnatural that “required rights” determine the rights that the page content has independent of the author.
  • Doesn’t really match the fact that you “grant” these rights, i.e., by adding a “required” right you’re granting that right

Document rights

Pro:

  • document rights grant rights to a document similar to existing “user” rights that grant rights to a user

Contra:

  • the term can be confused with the existing rights that also apply to documents

Conclusion

Given the current reliance on the last author for many purposes I currently don’t see us moving into the direction of not using the last author anymore, despite this becoming more and more difficult, e.g., with real-time editing. Given these arguments, I think it makes sense to stick with the original term “required rights”, so here is my +1 for that.

I’m looking forward to hearing your opinions and possibly also other naming suggestions.

I’m not sure I like “required rights” that much since “required” is a vague concept and not self-explicit. Required for what?

I think I’d prefer “content rights” which would mean the rights under which content executes. Another alternative would be “execution rights”.

WDYT?

Thanks

PS: I prefer “required rights” over “document rights” which I find too close to the standard user rights set on documents.

Both sound interesting. Regarding “content rights”, we have a dedicated content field, but these rights aren’t just about this field but also about XObjects for example. Regarding “execution rights”, not everything is executed. For example, these rights would also be needed for translation documents, or certain kinds of configurations that aren’t necessarily executed.

I think I like “content rights” best because it has the same idea as “document rights”, I’m just not sure about the confusion with the content of the document. We also have a content author for example, and this author just applies to the content and not XObjects.

I’m +1 for document rights as, once introduced should lead to:

  • “legacy rights” for what we currently have
  • “document rights” for the rights of a document
  • “user rights” for the rights of a given user

The generic term “rights” alone does not give us much information anyway.

I’m -1 for “execution rights” as well.
I’m -0 for “content rights” as this is more general than just the content of the page.
I’m +1 for “required rights” as it also convey the relationship to user rights (i.e., the rights required from the user to perform X). Though, I personally have a slight preference for “document rights”.

Another option is to use “page rights” as the term page is more familiar to end users than document which is a technical term (though we could us both based on the context, as we do for page vs document).

I’m not a fan of “execution” or “content” rights either, as it’s too limiting.

Among the previous proposals I think the less confusing (colliding less with other concepts) choice is “required” rights, even if I agree that those rights are essentially the rights of the document.

Another possibility I can think of is “authors rights”, the rationale being that it’s the rights which are going to be assigned to the author of the content evaluated in that document.

To me, “authors rights” is too similar to user rights, I think this only makes sense if you’re deeply familiar with the concept that the rights of the content of the page depends on the last author. Unfortunately, I fear that most users aren’t (that) familiar with that concept.

I agree that from a technical point of view, “content rights” is wrong, but I wonder if from a user’s point of view this isn’t the correct term: These are the rights of the content of the page. Sure, from a technical point of view, the “content” is just one part. But from a user’s point of view, I don’t think this separation exists - when you edit with a sheet, there is no real distinction between the actual “content” and other fields, and for users it is actually impossible to know if they’re editing the content at all (none of the fields might correspond to the actual content). If we take this distinction seriously, we should introduce “content rights” and “metadata rights” but I believe this distinction is just confusing and leads to all kinds of problems which is why I didn’t suggest separating between content and metadata here. We have the same kind of confusion between content and metadata author, I believe it would be best to remove that distinction there, too, but that’s another topic. However, if you don’t agree that this distinction is bad, we should probably introduce “content rights” and “metadata rights”.

To summarize the discussion so far:

  • everybody seems to agree that “required rights” would be okay as kind of a “fallback” option
  • regarding “document rights”, the opinions are split
  • “content rights” seems to have less agreement than “document rights” or “required rights”

It would be great if you could provide some more feedback on the “content rights” vs. “metadata rights” question above.

Maybe we need a naming which is different in the API and in the final UI. I’m never a huge fan of this kind of inconsistency, but it seems that most of the debate is “this is better for the API” vs “this is better for the end user”.

1 Like