-
Notifications
You must be signed in to change notification settings - Fork 116
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
podcast:locked owner attribute necessary when feed is locked or unlocked? #170
Comments
Our interpretation at Buzzsprout was no. We won't transfer if the the podcast is locked. We use the email address to notify the "owner" if an attempt is made so they can understand why the transfer failed.
We don't use the owner attribute if the podcast is locked. |
@tomrossi7 that is how I originally interpreted it as well, but my developers pointed out that the documentation states you should verify the owner and it was not explicit on which context you do that (yes or no), which means you should confirm the owner no matter what. You would verify the owner when it is locked or when it is not locked as it is written currently, but you can't transfer it if set to "yes". A note I pointed out to my developers is that if it is locked but you have verified the email, you are the owner of the show whether the feed is locked or not you should be able to transfer it, but again the documentation does not explicitly state that. There is a 3rd case, where it could be "yes", "confirmed", and "no". The "confirmed" case would cover the situation where it can be transferred if the email address is confirmed, and "no" means no without any other complication. |
We can always update the documentation. I think we should avoid dictating how tags are used and focus on a standard for communication. IMHO if an RSS feed tag is locked, it shouldn't be transferred. The owner attribute is useful for getting in touch with the person to have the feed unlocked. |
Tom has the right sense of it and the wording can be clarified pretty easily so no issue there. I can update along with the other wording change. Basically a no is always a no. And a yes is always a yes. The owner email is how you let the true owner know that a yes needs to be a no for things to proceed. |
I've submitted a pull request to remove some of the implementation language around the tag. @cio-blubrry I don't know about making the owner attribute optional though. To me it is kind-of like a domain registrar. The owner attribute should point to the person that can get the lock status changed? What do you think? |
Merged. Thanks Tom. |
Currently the wording for the podcast:locked tag is not clear, and the examples imply that the owner attribute is used in both cases of "yes - locked" and "no - not locked". Clarity on this is requested.
Please see issues for context of this question:
<podcast:locked owner="[email protected]">yes</podcast:locked>
When is this case relevant? Can the podcast be locked and also transferred if the email is verified?
<podcast:locked owner="[email protected]">no</podcast:locked>
When is this case relevant? Can the podcast be not locked but still require email verification?
The text was updated successfully, but these errors were encountered: