When I updated SMW to newest version this problem went away. Sorry, didn't realize I had an outdated version of it.

This might be fixed. I updated SMW to the newest version and my jobs queue empties properly now. Don't know what I need to do to clear this out of Phabricator.

Maybe I should explain. What I was really trying to do is add easy access to this to any page. I could have seen it being a tab a the top, or something in the sidebar using {{PAGENAME}}, but since it seems to have to sit on a page, I thought I'd add it to a template or similar.
What might be even better is if it were accessible like the SMW queries, where I essentially build a query and store it as a link and the page it goes to doesn't need to "exist".

1.28

You were right, that error was an accesslog extension issue. That was fixed.
However, still having the same problem, template is generated but forms or properties are not.

Template Data Element is as follows. I initially had all the fields of it in the form but took all but one out as part of troubleshooting:

Here is the form definition:

Ciencia_Al_Poder: I just tested this and you are right in that this works if I set
$wgGroupPermissions['user']['editmyprivateinfo'] = true; (instead of *).
I unset all user rights because I wanted to cut out all who have an account that is not "legit". So, giving the right to "user" is better than giving it to "*", but I am still wondering why anyone other than the ones we still want onboard need rights to this.

MediaWiki 1.26.0
PHP 5.4.45 (cgi-fcgi)
MySQL 5.6.26-cll-lve

If RSS feeds from mediawiki are to be accessible from a feed reader that is web based then cookies won't do the trick but a token would. To me, being accessible from multiple devices is one of the main benefits of a feed aggregator, so this would be a good feature.

Sm8ps, I tested this a while ago and it works great. Thanks for your help!

Thanks Aklapper for explaining the priority field. I had misunderstood it to be some sort of triage.
You changed the title of this as well, adding "Use the watchlist token". I changed the wording slightly because on first read that looked to me like using the token might solve the issue, which it does not.
Regarding coming up with a fix, I think this might be first a philosophical problem and only second a technical one. For sake of argument, let's assume I were to work out how to add an exemption to the API that omits login requirement for token access to watchlist. I would expect there to be resistance from whoever implemented this to not work that way in the first place. When I tried to find out how the RSS feeds are supposed to work, documentation is kind of slim to start with, so how would one find out the intended functionality and/or a place to discuss it? I have a reasonably good understanding of how the content side of wikipedia deals with this sort of thing, but have not contributed to the code side.
Thanks! T

I second Tessus: I think this is not a low priority. Especially since Mediawiki already doesn't accept logins from RSS (https://www.mediawiki.org/wiki/Thread:Project:Support_desk/feed_from_private_wiki). To me the community surrounding mediawiki seem like the kind of people who would see the importance of being able to use automated tools to manage ones web feeds.
Could someone direct me somewhere to explain what that watchlist token is actually for?

TinyRSS forums got back saying that for an authenticated feed listing to work, "http basic/digest auth" needs to be supported and that "digest authentication requires curl". Does Mediawiki work like that?

I think there are two things going on. For one, the login/authentication between mediawiki and tinyRSS is not working. The api comes back with a message "You need read permission to use this module". I would be interested to know how to troubleshoot that... I don't know how to view what is going on there.