Skip to content
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

WIP: For logged #272

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

WIP: For logged #272

wants to merge 3 commits into from

Conversation

urielarg
Copy link

@urielarg urielarg commented May 27, 2019

This would allow for topics to be invisible for non logged users.
I opened this PR as work in progress so I can get an idea if this is something that you want to see implemented or not.
If you think it is I could work in tests, upgrade, etc.
The main flaw of the feature as it is now IMO is that the "security" around non logged users to be able to see topics it's a bit useless since there is no control in user's registration.

@nitely
Copy link
Owner

nitely commented May 29, 2019

What is the use-case for this? I gather this would allow a moderator to restrict access to some topic. But in what case is that needed?

What I wanted: A way to have "visible only for logged in (authenticated)" feature.
Why?: My blog has a topic, people will be respectful with one another but they might not feel safe showing their posts to everyone.
What I did: add a new property to topic: "for_logged" (or similar), it gets filtered in the view. I added it as another option to update a topic, maybe still need to add during creation. I'll push it to a fork just in case anyone interested.
Once I have all these running I'll get into groups permissions.

This is what you wrote here. But this use-case seems to be covered by the "private forum" setting. A half private/half public forum would require the group permission feature, to restrict access to an entire category rather than individual topics.

@urielarg
Copy link
Author

What is the use-case for this? I gather this would allow a moderator to restrict access to some topic. But in what case is that needed?

What I wanted: A way to have "visible only for logged in (authenticated)" feature.
Why?: My blog has a topic, people will be respectful with one another but they might not feel safe showing their posts to everyone.
What I did: add a new property to topic: "for_logged" (or similar), it gets filtered in the view. I added it as another option to update a topic, maybe still need to add during creation. I'll push it to a fork just in case anyone interested.
Once I have all these running I'll get into groups permissions.

This is what you wrote here. But this use-case seems to be covered by the "private forum" setting. A half private/half public forum would require the group permission feature, to restrict access to an entire category rather than individual topics.

I didn't know about that setting, I missed it.
I see now how categories would be broken, not sure why you think it requires groups.
Shouldn't we only filter categories for non-logged to all which have at least one visible topic (for him)?
I see why you'd have categories and not topics with permissions.

@nitely
Copy link
Owner

nitely commented May 29, 2019

If you were planning on setting every topic in a given category as private, then that use-case is better solved by group permissions. The category would be visible to some group(s) as well as all the topics in it. So, categories only visible to logged-in users would be covered by the group permissions feature (i.e: a user must be logged-in and be in an authorized group).

@urielarg
Copy link
Author

urielarg commented Jun 1, 2019

Makes sense, so do you think it's just better to create the whole groups feature rather than doing this "only-for-logged" small one? I will probably keep using this fork and make another fork for the whole "groups-permissions" (if that's what you think is best)

@nitely
Copy link
Owner

nitely commented Jun 2, 2019

On a second thought, I'm not sure groups would replace this. Since it's a small change, I say we add this but for categories instead of topics. How that sounds?

@@ -25,6 +25,9 @@ def visible(self):

def opened(self):
return self.filter(is_closed=False)

def for_non_logged_users(self):
return self.filter(is_for_logged=False)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it may be better to change the visible filter to take a user parameter and do the (conditional) filtering there.

We would otherwise be adding this new filter everywhere where visible is used. Also, since we are breaking the visible API, then the test should fail in all the places where this filtering is required (i.e: the user profile comes to mind).

@@ -44,6 +44,7 @@ class Topic(models.Model):
is_globally_pinned = models.BooleanField(_("globally pinned"), default=False)
is_closed = models.BooleanField(_("closed"), default=False)
is_removed = models.BooleanField(default=False)
is_for_logged = models.BooleanField(_("is for logged"), default=False)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be a better name would be is_login_required (like the decorator) or is_for_logged_in_users (but it's loooong)`

Don't forget to run the makemigrations command and commit the new migration file.


ACTION = (
(COMMENT, _("comment")),
(MOVED, _("topic moved")),
(CLOSED, _("topic closed")),
(UNCLOSED, _("topic unclosed")),
(PINNED, _("topic pinned")),
(UNPINNED, _("topic unpinned")))
(UNPINNED, _("topic unpinned")),
(FOR_LOGGED, _("topic for logged users")),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"logged users" -> "logged-in users"

@nitely
Copy link
Owner

nitely commented Jun 2, 2019

I added some comments to the code with changes I would have requested, just in case.

@urielarg
Copy link
Author

urielarg commented Jun 2, 2019

On a second thought, I'm not sure groups would replace this. Since it's a small change, I say we add this but for categories instead of topics. How that sounds?

Yeah, that is definitely a better idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants