-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: redefine "public" and "private" #121
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on what decision did you change this definition?
Based on my experience, what people most often want when they use the terms "public" / "private". This code change doesn't have a direct impact, it's rather like a default, that can be used or overwritten on a per-project-basis. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable to me. Are these changes in line with what we have most commonly in the database? Is the PRIVATE
one the same as the current default DOAPs used by the API for new projects? Because this is currently our "canonical definition of private". And does this align with what RDU wants?
Thanks for your input. Unfortunately, your questions have different contradictory answers ;-) 1. What is most commonly in the database (stage)?There are more than 20 different public-ish permissions. One among them is far on top (much more frequent than the others): For private-ish, there are 3 candidates:
2. What is the default DOAP for private that the API sets?Surprisingly, the default private DOAP is the one that appears the least frequent on stage: 3. What does RDU want?Since they don't care about permissions at such a low level, I had the following approach until now: Every time I had to do a permissions change, I translated the high-level instructions ("private" / "public") into something that seemed reasonable to me, and then checked back with RDU. Mostly, they just accepted what I suggested to them. But it also depends from case to case. So this question cannot really be answered. 4. What makes sense?According to my gut, PUBLIC is now quite sensible. However, I think that PRIVATE should rather be changed to |
👍
Considering how much easier it is to create numerous resources with dsp-tools (where other permissions may be provided) than with the app, this may not be as surprizing.
I asked the wrong question anyways - the right question would be "what do the projects want?" but the same would apply there, I guess.
Giving CR to Creator sounds reasonable, but I think sticking to the current default for now is also a good idea. In the end, the permissions system has to change over time anyways, so we will have to see what we make form all this... |
I cannot find the source of these:
But it doesn't matter that much. I guess that these permissions really stem from dsp-tools, even if I cannot reconstruct the exact way how they came into being. More importantly: I will tend for the standardized way, and merge this PR as is. Thanks for your thoughts 👍 |
No description provided.