So you get an error during the refreshData run?

mitchell_neill wrote:

No, no errors are shown.

Just noticed that it dropped all my numeric property values as well. This is not good :(

This is strange indeed, since refreshData does essentially the same as a normal page edit. Can you get this effect even if you have a simple page that contains only something like [[Menu Item::false]]? It would be good to reproduce the issue using as little templates and extensions as possible.

Which SMW version exactly are you running? There have been many changes recently related to the storage of properties. Did you make any custom LocalSettings for selecting a storage engine (e.g., "$smwgDefaultStore = 'SMWSQLStore2';")?

mitchell_neill wrote:

Yes, it is odd.

I think this could be a permissions issue. What MW user does the refreshData effectively run as - Administrator or a "normal" user? I say this because I think the problems started after setting protection on the templates and properties.

I'm using everything "out of the box" settings wise. Precise SMW version is r113227

I have seen this intermittently before usually after a SF template edit (I've posted on the list about it). I think a few others have seen it too - badon, for instance. This is the first time I've seen it do it consistently though.

Cheers
Neill.

The code that is used to update does not edit pages and only calls MW parsing and SMW storage functions. There is no permission system in MW or SMW on that level, and there is no user account involved in calling these functions.

Did you try with a simple page that contains only a direct assignment of a Boolean property value?

mitchell_neill wrote:

Hi Markus.

I guess there is going to be a permissions issue if the template has something like:

Correct?

Thanks
Neill.

mitchell_neill wrote:

I guess permissions is the wrong word - visibility might be better :)

We cannot support this. If the page content depends on the user who views the page, there might not be any configuration of group memberships that sees all property assignments. It would be very bad if SMW data was depending on the user who last stored the page, since data is not user-specific but global. You get the same issue with category memberships, I suppose. This is just not going to work.

If this is the actual cause for the problem, then this would be closed as INVALID (since whatever we do, one can always find a situation where this bug occurs).

Side remark: Is it possible that Extension:UserFunctions is broken by design? User-dependent parsing can hardly work well with the MediaWiki parser cache, or can it?

mitchell_neill wrote:

I think it would be safe to assume that the Administrator user will see everything in 99.9% of wikis and so parsing as that user would guarantee visibility. I just assumed, not unreasonably I think, that this was the case and parsing would be done as a sysop user. There is often a real world need to restrict certain functionality to admins and it all actually works rather well :) I agree that support for more complex group memberships would be untenable.

I have never seen this problem so reproducible before the 1.18alpha though or I would have noticed it years ago, so perhaps something else is going on. I just need to find time to strip this all back to basics and test.

Side remark: I've never had any problems running UserFunctions on a page even with APC and memcaching.

Thanks for your input on this.

I do not see any SMW error here. A script that refreshes a page does not run as any user. The page content should not depend on the user who last viewed the page. This is a basic design decision in the architecture of MW and we will not be able to change this here.

This bug should be assigned to Extension:UserFunctions; maybe it can find a way to assume Administrator privileges for MW operations that do not normally involve users. Closing it as invalid for SMW.