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
sitewide default access permissions part 2 (Trac #744) #744
Comments
Attachment added by cash on 39107070-06-04: default_site_permissions_core.diff |
Attachment added by cash on 39107071-10-26: default_site_permissions_plugins.diff |
cash wrote on 39107088-03-02 I did two clean test installs with these changes. I also went through every permutation of group permissions to check those changes. Lighter testing on the rest. The administrator can choose for the site permissions to be private, logged_in, or public on the install. That can be changed at any time in the future but it only affects future content obviously. The only time I override the default site permissions is on widgets. If the default permission for the site is private, I set the widget access to logged_in. Oh, and I'm using a trac id of cash instead of costelloc. |
cash wrote on 39132379-12-31 Due to the changes to group access permissions, the core patch needs to be updated. Any thoughts of putting this into 1.5 or should I just wait to redo the patch in case other changes are made related to this? |
benwerd wrote on 39149727-03-28 I think this should definitely make it into 1.5. Will look at the groups issues, but it looks like everything else can still go in as-is. |
benwerd wrote on 39149761-09-17 (In [svn:2885]) Added site default access permissions. Refs #744 |
benwerd wrote on 39149774-11-12 These patches have now been merged in with the exception of groups functionality. |
cash wrote on 39150618-03-13 I think
was dropped from the application of this patch. Or did I miss it? It was in egglib with the other access defines. |
benwerd wrote on 39150627-01-26 You're right, it was somehow missed over. Odd - thanks for the spot. |
cash wrote on 39151605-10-22 Ben, regarding the check you added in the plugins so that the default access code doesn't cause problem for people not running the latest svn. You are passing the constant to the function defined rather than the string. It should be: defined("ACCESS_DEFAULT") See commit 822 in the extensions repository. |
cash wrote on 39183200-12-20 This can be closed. |
cash wrote on 39193743-05-04 Since this is still open, I'll add two more patches here:
|
Attachment added by cash on 39193744-09-12: groups_discussion_access.diff |
Attachment added by cash on 39193746-04-26: groups_minor_tweaks.diff |
trac user marcus wrote on 39344278-09-22 This appears to have been done, closing ticket. |
Original ticket http://trac.elgg.org/ticket/744 on 39103474-12-15 by trac user costelloc, assigned to unknown.
Elgg version: 1.2
Part 1: #687 (using defines for access ids now)
Part 2:
Question: an admin can set the default site access permissions to private. This can make some sense for objects like pages or files in certain settings, but how about widgets and profile fields? I suggest that the highest (lowest?) default access id for a widget should be ACCESS_LOGGED_IN (or ACCESS_FRIENDS when it is implemented). This is because it is set on widget creation without input from the user and what good is a private widget on a user's profile. For profile fields, I'm leaning towards just having them pick up the default site permissions.
The text was updated successfully, but these errors were encountered: