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.

Sign up for GitHub

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

Jump to bottom

Remove visibility "Private" from POC #944

Closed
arnoldnipper opened this issue Feb 19, 2021 · 16 comments · Fixed by #1051
Closed

Remove visibility "Private" from POC #944

arnoldnipper opened this issue Feb 19, 2021 · 16 comments · Fixed by #1051
Assignees
@arnoldnipper
Labels
Time:Minor Up to 4 hours
Milestone
2.30.0

Comments

@arnoldnipper
Copy link
Contributor

I fail to see the use case for a poc with visibility "Private". There are tons of poc with this level. However, this is due to "Private" being the default for quite a while.

Now, @peeringdb/ac sees more and more tickets where users don't understand that they can not add a connection to an IX although there is technical poc. Of course with visibility "Private", only.
@arnoldnipper arnoldnipper added this to the 1 Decide milestone Feb 19, 2021
@arnoldnipper arnoldnipper self-assigned this Feb 19, 2021
@leovegoda
Copy link
Contributor

Who, other than the org that has the poc can see it if it is marked "Private"? What was the original rationale for this level of visibility?

@arnoldnipper
Copy link
Contributor Author

Who, other than the org that has the poc can see it if it is marked "Private"? What was the original rationale for this level of visibility?

Only the Admins (org and PDB) can see the poc with visibility "Private". @grizz and/or @vegu: please respond to the 2nd question.

@ynbrthr
Copy link

ynbrthr commented Feb 21, 2021

+1

@leovegoda
Copy link
Contributor

Who, other than the org that has the poc can see it if it is marked "Private"? What was the original rationale for this level of visibility?

Only the Admins (org and PDB) can see the poc with visibility "Private". @grizz and/or @vegu: please respond to the 2nd question.

If we have a lot of poc with visibility "Private" it is possible people ste the permissions like this thinking they were achieving something else. If and when we change this, we should probably create a simple guide to permissions and publish that at the same time.

@arnoldnipper
Copy link
Contributor Author

If we have a lot of poc with visibility "Private" it is possible people ste the permissions like this thinking they were achieving something else.

Visibility "Private" was the default for quite a while. This is the only reason we have a lot of poc with this level of visibility.

@leovegoda
Copy link
Contributor

Visibility "Private" was the default for quite a while. This is the only reason we have a lot of poc with this level of visibility.

When we change this, do we want to make all these poc visible, ask people to change their visibility, or something else?

@arnoldnipper
Copy link
Contributor Author

When we change this, do we want to make all these poc visible, ask people to change their visibility, or something else?

One step after the other. @peeringdb/pc, could you please make up your mind. If we have a quorum, then let's discuss what to do.

@mcmanuss8
Copy link
Contributor

Is there a valid reason for having a Private POC?

@arnoldnipper
Copy link
Contributor Author

Is there a valid reason for having a Private POC?

I can't see one. In 192 @grizz agreed that visibility "Users" as a default makes sense. However, we did not discuss what the use case for "Private" is. @grizz, @vegu: what was your reasoning?

@leovegoda
Copy link
Contributor

Is there a valid reason for having a Private POC?

I can't see one. In 192 @grizz agreed that visibility "Users" as a default makes sense. However, we did not discuss what the use case for "Private" is. @grizz, @vegu: what was your reasoning?

It would be good to know if there is still a valid reason for having "Private" as a visibility status. If there is none, perhaps we could schedule this change for some time towards the end of 2021Q2, so we can make sure we communicate the impact of the change to affected users some time before we implement. Thoughts from @peeringdb/pc ?

@arnoldnipper
Copy link
Contributor Author

It would be good to know if there is still a valid reason for having "Private" as a visibility status.

Fully agree. Would you mind to ask @grizz and/or @vegu directly and give feedback here.

If there is none, perhaps we could schedule this change for some time towards the end of 2021Q2, so we can make sure we communicate the impact of the change to affected users some time before we implement.

Q: what to do with existing poc with visibility: "Private"?

  • remove them (IMO less ideal)
  • set visibility to "Users" (and explain in a blog post why we did this)

@mustangthz
Copy link

If an admin has set a POC to private, PDB should not make them visible without their permission.

I'd like to understand the reasoning for why the exist before a decision is made.

@leovegoda
Copy link
Contributor

When the @peeringdb/pc met earlier today, @grizz explained that this is a remnant from v1 and that the status is no longer useful. One suggested approach was to make the status invalid and require the user to review and update contacts when next making an update to their information. If there's a consensus to go ahead with this, we might want to close #862

@arnoldnipper
Copy link
Contributor Author

Summary

@peeringdb/pc, please vote

@mcmanuss8
Copy link
Contributor

I'm ok with this, but we should be very clear that we don't silently flip the contacts to publicly viewable if we said they wouldn't be.

@arnoldnipper
Copy link
Contributor Author

I'm ok with this, but we should be very clear that we don't silently flip the contacts to publicly viewable if we said they wouldn't be.

It's up to the Admins what to do with the POC. PDB itself will not do anything other then invalifdating.

@grizz grizz mentioned this issue Jun 18, 2021
Closed
@vegu vegu added the Time:Minor Up to 4 hours label Jun 18, 2021
vegu added a commit that referenced this issue Sep 14, 2021
@vegu
private pocs are no longer valid (#944)
ebf7f18
vegu added a commit that referenced this issue Sep 14, 2021
@vegu
Merge branch 'gh_944' into 'support_202108'
c518b4b 
private pocs are no longer valid (#944)

See merge request gh/peeringdb/peeringdb!208
@grizz grizz mentioned this issue Sep 14, 2021
Merged
grizz added a commit that referenced this issue Sep 14, 2021
@grizz @vegu
Support 202108 (#1051)
636f37e 
* add OPERATIONS_EMAIL setting

* fixes #1019: redundant saves to deleted netixlans during ix-f import

* private pocs are no longer valid (#944)

* poetry relock (handleref update)

* fixes #1032: __id api filter not working

* Additional self-selection fields for Facilities #800

* advanced search fields for available voltage, property and diverse serving substations (#1016)

* When network sets netixlan speed to 1200000 only 1T is shown instead of 1.2T ... sometimes #500

* add search-data

* comment out mount points for api-cache, search-data, django-peeringdb

* poetry relock (django-peeringdb 2.9.0)

* linting

Co-authored-by: Stefan Pratter <stefan@20c.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@arnoldnipper arnoldnipper

Labels
Time:Minor Up to 4 hours
Projects
None yet
Milestone
2.30.0
Development

Successfully merging a pull request may close this issue.

Support 202108 peeringdb/peeringdb
7 participants
@grizz @vegu @mcmanuss8 @arnoldnipper @mustangthz @ynbrthr @leovegoda