Ticket #756 (closed Task: fixed)
Observations on recent nightly
| Reported by: | JuergeN | Owned by: | jri |
|---|---|---|---|
| Priority: | Major | Milestone: | Release 4.5 |
| Component: | DeepaMehta Standard Distribution | Version: | 4.5 |
| Keywords: | Cc: | ||
| Complexity: | 3 | Area: | |
| Module: |
Description
Hey, I know things are not ready yet, but as I do not want to forget about it, I out my recent observations of the status quo here:
- Create New User
Any user can create another user (in their private workspace). From workspace ACL logic this is clear, because the user has read permission on the type and write permission in their private workspace. The question is: do we want this?
My opinion: NO - I think that only users with write permission on the system workspace should be able to create new users, unless we have a self-register plugin installed or we think it is really charming that anyone can create new users. ;-)
- Search
I do net yet fully understand the impact of our workspace ACL to the search. It seams that a search|~result is stored in the workspace where I search. What does that mean, if I do not have write permission on a workspace? In the very logic of our workspace ACL it would mean that I need to be in a workspace where I have write permissions, to be able to place a search. I think this is very logical, but it also means, that people who are not logged into the system in any way, cannot do a search, unless the system allows for annonymous editing. Am I right?
Change History
comment:1 in reply to: ↑ description Changed 10 years ago by jri
comment:2 in reply to: ↑ description Changed 10 years ago by jri
Replying to JuergeN:
[...] I think that only users with write permission on the system workspace should be able to create new users ...
This is realized meanwhile.
See ticket:751#comment:30
comment:3 in reply to: ↑ description Changed 10 years ago by jri
Replying to JuergeN:
It seams that a search|~result is stored in the workspace where I search. What does that mean, if I do not have write permission on a workspace?
Yes, indeed, this let come up the question to which workspace a Search is supposed to be assigned? My suggestion: we always assign a Search to the user's private workspace. A search would appear in the current topicmap (as it is now) but would be assigned to the private workspace, regardless which workspace is selected. From the design perspective the rationale would be: Searches are private. Nobody is supposed to see what another user is searching for.
However, one question remain: where to assign the searches created by anonymous? Anonymous has no private workspace. Searches performed by anonymous are in fact abandoned. So, who is supposed to delete them? Should we assign them to the System workspace, in order to let the "admins" delete them once in a while?
Replying to JuergeN:
Yes, we already agreed on that (on the phone I think).
This will be implemented very soon.
Yes, indeed, search is a special case.
From the design perspective I would pursue the behavior that is realized now: a user can search/find any content where she has READ permission to, regardless whether the selected workspace is WRITEable or not. (See also the hint below). Otherwise the case for search would be too limited.
One could argue that way: traditionally search/retrieve is a read operation, that is GET semantics. It is only a DM specialty that things are created while a search (namely the Search topic and Search Result Item associations), that is POST semantics. So, currently we interpret a DM search in the "traditional" sense, not strictly technically.
Already with DM 4.4 and before search is treated special in this very regard. By default a user who is not logged in is not allowed to issue POST requests at all. We worked around that by triggering a search via a GET request (instead POST what would be adequate).
Currently with 4.5-SNAPSHOT search is functional only because access control for create operations is not yet strictly enforced at the backend. Once it is, I think we need to implement an exceptional rule to widen the permission for a "create search topic" operation, in order to keep the behavior as it is now.
One general (not 4.5 specific) hint about permissions and topicmaps: a user who has no WRITE permission to a topicmap is still free to manipulate the topicmap in any possible regard (e.g. move things, hide/reveal things, place new things, change topic colors), however these -- view related -- manipulations are not made persistent. Content manipulations are made persistent (provided the user has WRITE permission to the respective object of course), but view manipulations are not. A topicmap is a view (to content existing elsewhere). The rationale here is to allow the user all the DM freedom to adapt a view to hers personal/situation-based need without undermining access control. So, the current interpretation is: a user who has no WRITE permission to the view (= topicmap) is not allowed to make persistent changes to the view.