Hi everyone,
this is another proposal regarding an aspect of document rights. Document rights are trying to solve the problem that the rights of “active content” in a page like script macros or script 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 document 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.
The question I want to answer with this proposal is what such a “right” is in the context of document rights. The initial implementation just uses a Right but in my opinion this misses an important use case: many objects that are active on the whole wiki like translations or UIX require admin right not on the document itself but on the wiki. From my point of view, the primary use cases for now are:
- Script right
- Wiki admin right
- Programming right
In the case of the required rights analyzer, we had the same problem and chose a combination of a right and an entity type as solution. So for example, you have Right.ADMIN, EntityType.WIKI for wiki admin. This could be a solution here, too.
Alternatively, we could also just say that “admin” right is a special case and we always check that on the wiki.
A different option could be to have a mechanism where extensions can register custom document rights that are represented as string constants, with the mentioned three values registered by default.
I can also see some more advanced use cases for document rights:
- The PDF Viewer Macro (Pro) has a parameter “asauthor” that uses the view right of the author on the PDF file to display it. This could be represented as a required view right on the PDF file.
- A script using
$doc.saveAsAuthor()could use an edit right on the target document. - A script displaying a document could use a view right on the displayed document.
Apart from the first case, I have no idea how this could/should work as usually the target pages are dynamic. However, I think for the first use case document rights could be very interesting as in that case you would certainly want to avoid that somebody who cannot view the PDF file edits the page.
For such advanced use cases, it could be interesting to use a combination of a right and an entity reference as document right. To keep this usable, we could offer checkboxes for all right/entity reference combinations that a required right analyzer detected and offer the option to add arbitrary right/entity reference combinations only to advanced users.
To make sure that this stays somehow sane I would say that any such “delegated” right check shouldn’t take document rights into account. So when you say that document A has edit right on document B, to check if user U can edit A, we would only check if U has in principle edit right on document B, not if U also fulfills the document rights on B. Further/alternatively, we could exclude edit right from the rights that can be configured as document rights.
What I’m not sure about is the impact on the security cache as this could add arbitrary cross-dependencies between security cache entries. I think it should be possible, but it would certainly make an already difficult data structure more complex.
Regarding the security cache, I think we could have an access entry without document rights and then when necessary a child entry that takes document rights into account. That child entry with document rights could have other access entries (without document rights) as parents to take their rights into account, thereby ensuring that we get no dependency cycles. Further, to properly represent the notion that document A has right X on document B I think we basically need to treat document A similar to how we currently treat users.
In general, I tend to imagine document rights as being similar to making it possible to assign rights to a document in the same way as we currently assign rights to a user. Except that storing them in the same way would make things super complicated as I feel you should be able to indicate in an extension that a document should have admin right on the wiki for example without adding a right object on the global configuration. But maybe that’s also the right way to store them and we just need to find better ways to distribute them?
To summarize, I see three options:
- Do the same as for required rights, each document right is a right and an entity type, allowing values like “Wiki admin”.
- Really just use a
Rightand ignore the wiki admin use case or interpret admin right as wiki admin right. - Use custom values that can be extended by extensions.
- Each document right is a pair of a right and an entity reference.
To me, option 4 offers most flexibility but is also most complex and could offer unintended features. For example, I noticed that document rights offer a way to specify that a document can only be edited by wiki admins. With arbitrary entity references and rights, edit rights of document A could even be tied to edit right to document B. I’m not sure whether that’s a good idea.
Option 1 would be consistent with document rights and cover the use cases we care about most. Option 3 sounds like it would offer good extensibility, but I’m not sure if that’s necessary.
Overall, I think I’m +1 for option 1, but I also fear we might be missing an opportunity to express more complex things where we’re using the author’s rights on other entities. If it wasn’t for the complexity, I think I would be for option 4. Option 2 is probably easiest to implement but also sounds like a hack.
Thank you very much in advance for your opinions and suggestions.