-
-
Notifications
You must be signed in to change notification settings - Fork 298
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
Public album is not and can not be configured to be public #1053
Comments
If you are talking about the I do agree this is not a very clearly defined behavior and will need to be fixed. |
That seems to be a rather confusing naming/behaviour, yeah. Is there any other view for the public to see all the pictures that are public ? Because that seems kind of fundamental :D Please let me know what you would like me to do with this issue - close and start new ones about the missing feature / the misleading naming, or continue in this one ? |
The problem here (IIRC) is that you can have "public" photos that are hidden - i.e. accessible by URL, but you might want people to stumble across if they're not logged in. The official way to make photos accessible to the public is with albums. I'll leave @ildyria to decide where to take this next. |
@Gaibhne wrote:
That's intended by design. The smart album Public is basically a query which collects all photos whose attribute "public" is set to true, but the album itself is not public.
@Gaibhne: How did you set the visibility of the smart album Public manually? The GUI should not provide an option to do that. Changing the visibility attribute of smart albums is not supported. Hence, the server-side error is totally correct, but I wonder how you got there. The menu of a smart album should look like this and not provide an icon to change the visibility. @ildyria wrote:
I have to object. The visibility of the smart album Public cannot be changed by a server configuration. The smart album Public is always non-public. You can only change the visibility of the smart albums Recent and Starred. See here: @Gaibhne wrote:
You mean a single public album which contains each and every public photo such that users who are not logged in can scroll trough all public photos at once? No, such a feature does not exist. The normal approach would be to publish individual albums. Then all non logged-in users can see these albums on the front page. Option of individual album: Menu: Resulting front-page: Personally, I am not sure, if I also find it fundamental, to be able to make the smart album Public public. During times this smart album might become very huge and suffer from long loading times, because typically the set of public albums will grow not shrink. Thus having the public photos being nicely sorted in public albums make a lot more sense. This is different for the smart album Recent, because after some time old public photos will vanish from the Recent album. But anyway, it should not be too difficult to also have an option in the configuration, which allows to make the Public album public in the same way as the Recent album. It seems that @ildyria thought we would already have that. |
Yes. I'd be much more in favour of (optionally) making "unsorted" public. I'm still unsure about it, but it seems a better option than "public". |
I don't know. Unsorted contains all photos that are not in an album, both public and private. It strikes me as less risky to make Public public than Unsorted -- though, since this would be enabled by configs that need to be explicitly toggled, I have no problem having such configs for both... |
I was imagining an access check. But I still think the better solution is to use albums. |
Yes, I'm generally not a big fan of either Unsorted or Public... As far as I'm concerned, they serve little useful purpose and their semantics is confusing to users. |
Error 2 should be fixed. Error 1 is more of a new feature request, and it hasn't been addressed. |
To @Gaibhne: We recently had the same question wrt. error 1 on gitter. I simply post the explanation here in case someone stumbles across the same problem:
@kamil4 wrote:
Completely agreed. The question is whether we want to close the issue anyway. Of course, we could implement a public "Public" album quite easily. However, I wonder if this would be reasonable. A public "Public" album which really contains all public photos (even those from public albums) would become quite large even on medium-sized installation and be a true performance bottleneck. Maybe we should just rename the current "Public" album to something which does not confuse users. But I have no good suggestion. |
Detailed description of the problem [REQUIRED]
Despite there being an album named
public
, the album is not actually public. Setting the public albums visibility to public manually results in an album named public, set to be public, but not actually being public. When attempting to save the visibility change, a message appears for a split second in the upper left sayingServer error or API not found
.The
POST
request body isfunction=Album%3A%3AsetPublic&albumID=public&full_photo=1&public=1&nsfw=0&visible=1&downloadable=0&share_button_visible=0
, the server response is a422 - Unprocessable Entity
Steps to reproduce the issue
Steps to reproduce the behavior:
Error 1:
Public
and not being logged inPublic
Public
albumError 2:
Public
while being logged in+
in the upper rightAlbum visibility
Public
toggle of thePublic
albumSave
Album Visibility
again, it will claim to be set toPublic
, but it is not, and after a page refresh, will correctly show the albumPublic
not being set toPublic
Public
albumScreenshots
A sad image of a lack of a
Public
albumOutput of the diagnostics [REQUIRED]
Browser and system
All browsers on all systems I would expect, tested with Firefox, Chrome and Edge on Windows 10
The text was updated successfully, but these errors were encountered: