Readthedocs.org: Remove project level privacy

[agjohnson]

Currently, we support both project and version level privacy. This is an extra layer of privacy that really just translates to having a default privacy level for versions. Currently, we treat project and version level privacy as different constructs. There are two options here:

• Make the project level privacy the "default version privacy level" and remove the default for the version privacy. Changing this version privacy away from None overrides the project level setting. The project level setting isn't directly used in privacy level determinations.
• Just drop it, leave this decision to project versions entirely. This setting will be set to None for all projects going forward.

Work items

• TBD
• But also make sure downloads behavior matches the intended new logic. See #4816

[stsewd]

As mention here https://github.com/rtfd/readthedocs.org/pull/3444#issuecomment-354175116, the first step will be removing this option from the forms, what would be the options for projects that already have a non-public level?

• All new project can't change its privacy level.
• Current projects with a non-public privacy level will be able to change their level to public only (or remain with its current level for some time).

Something like that would work?

[agjohnson]

Hiding the form field via a feature flag (and adding a feature flag migration to indicate a date-based flag) would be a place to start. You're correct that we need to discuss what the logic change should be. Another option:

• Project/version privacy agree -- project gets the feature flag and project level privacy is now hidden.

I don't think the actual value (private/protected/public) matters.

Also, a couple of other related decisions:

• [ ] make sure protected project status isn't used anywhere (i think we only used this in project listings, like our old list all projects page).
• [ ] remove protected status completely?
• [ ] add a feature to versions with is "published" or something similar, as this seems to be the only use case for protected anymore

[humitos]

I have some thoughts here:

• Protected projects involves a "hidden feature" that some people is using: keep _all the versions_ online but do no list/show deprecated/very old ones in the flyout menu.
  
  
  
  • I think it's a good feature to have/support. Maybe in a different way instead of privacy levels, but something to consider.
  
  
  • If we remove this privacy level, we don't have a way to have the same behavior.
  
  
• .com site uses these privacy level correctly
  
  
  
  • by removing them from .org we need to keep in mind that this code is still needed in the .com site and we will need to move it there or something similar
  
  

Make the project level privacy the "default version privacy level" and remove the default for the version privacy. Changing this version privacy away from None overrides the project level setting.

I think this option is the one that makes most sense.

This option is "more configurable" by the user. In the case of the .com, if you have a Public project you will create each version as Public which is probably what the user wants.

Otherwise, with your second idea, the user will need to change the privacy level on every new version that she creates (in case we default the privacy level to settings.DEFAULT_PRIVACY_LEVEL.

Hiding the form field via a feature flag (and adding a feature flag migration to indicate a date-based flag) would be a place to start

I'd say that new projects should know nothing about Privacy Levels. Old projects will remain the same for now.

[agjohnson]

I just suggested adding a version field for "published" or something, but maybe the clearest field name would be hidden. A hidden version can be active, and is published, but not listed. Hidden versions can be public, or private on our commercial hosting.

[agjohnson]

@rtfd/core Where do folks stand on taking on this work for v3? If we can just hide the field and field choices we don't want anymore, and we don't need a migration event to upgrade old projects to the new logic, this becomes vastly simplified and is probably doable by EOY.

If not, this will be a much larger event and will likely need a separate deprecation event.

Discovery

• Can we handle this with a migration? Projects have public/private/protected privacy level, project versions have public/private/protected, these operate differently on community and commercial hosting. If there are upgrade paths for all permutations, then we can probably just migrate all projects.

If not, can we:

• hide project level privacy from new projects without complicating logic?
• hide protected privacy level from projects without complicating logic?
• give users an opt in method for upgrading?

My take is if we can automate this with a migration, we might not want to take this on immediately unless someone feels they have a few weeks to tackle this.

[stsewd]

hide project level privacy from new projects without complicating logic?
hide protected privacy level from projects without complicating logic?

+1 on this, I think we can worry about migrating old projects later, but this will be the first step.

Also, I think you were talking to only have privacy levels on versions, but don't we need a way to show/hide the project dashboard/page in .com?

[agjohnson]

I think that showing the project dashboard page for public projects should be considered buggy behavior on the .com. This was a hold out from how the community site works, and I don't think translates well to customers using our commercial hosting.

[ericholscher]

Ran into this again with search, where we were respecting the Project privacy, but not the Version, which is almost always what we want to be doing.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stsewd]

The only thing missing here is the removal from the usage of privacy level in .com, after that we are safe to remove this field from the db.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stsewd]

We are going to re-evaluate this, as some users want to have the dashboard public among other things.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.