Group Form View Access

[rackem]

First of all, this is regarding F!3.1 on J!3.

I would like to hide view access to a group in my form but still have information displayed in list view. So I change the Access setting in my group to "Nobody". Which, according to the help text, should just hide the group in my form. However, it is also removing the display of this group in my list view. Is this expected behavior or a bug?

Some background: I have a "player" list that is joined to a mySQL View containing "ratings". I just want to be able to display "ratings" in list view but obviously not allow users to edit that information.

 

[rackem]

Or perhaps it isn't a good idea to join to a mySQL view? I get

Error
The target table mpsV_latest_info of the INSERT is not insertable-into SQL=INSERT INTO `mpsV_latest_info` ( `player_id`,`rating`,`robustness`,`date_time` ) VALUES ( '5','','','2013-06-22 01:02:00' )

when I try to add a new player. However I can't find a way to tell F! not to insert into the view.

Hmm... Seems like I should be able to just display it somehow with a join but I suppose I could write a Form PHP plugin to update my player table.

 

[cheesegrits]

Hmmm, I thought we'd added some code in the processToDb() method in 3.0, so we don't even try and save a joined row if it's a view ... but looking at the code, it looks like that was my imagination.

Ignore this bit about 3.0, it's just "notes to self" ...

OK, I see what happened in 3.0. The getPrimaryKeyAndExtra() method used to return null for a view, but we "improved" it, so it uses a different method to get the key that Fabrik uses as the PK (rowid), even tho views don't really have a PK.

This had the side effect of breaking this, in the processToDb() method:

            $aKey = $listModel->getPrimaryKeyAndExtra();
            if (!$aKey)
            {
                // $$$ hugh - most likely a view, so lets not try and store it
                continue;
            }

... because getPrimaryKeyAndExtra() no longer returns null for a view. So To fix this in 3.0, need to add an explicit test there for $listModel->isView().

OK ... but in 3.1, we've completely rebuilt the way we write out joins, it's now in the group model. And I'm not familiar enough with that code yet to start messing with it. I *think* I see where I need to insert some code, but I need to set up a test case.

-- hugh

 

[cheesegrits]

OK, I've done some playing around in the new 3.1 join code, to see if I can easily splice in a check to see if the table a group sits on is a view or not ... and it's a little above my pay grade. I need to get more familiar with the new code, before I start messing with it.

So I'm raising a github issue for Rob on this one. I'll carry on playing around here, see if I can get it going without breaking anything, but I suspect it'll need Rob's Magic Touch.

https://github.com/Fabrik/fabrik/issues/761

-- hugh

 

[rackem]

Thanks for checking it out! It helps me out a lot just knowing it will be possible to use a view once the issue is resolved.

 

[cheesegrits]

I'm working on it. I've copped the isView() code from our list model, and am working on splicing it into the join model. The issue being, when we're processing joined groups during form submission, currently we only have a $listModel->isView(), which only tells us about the main list / table. What we need is a version of that method which will tell us about the table associated with the joined group.

And it's not as simple as it sounds, because the only way to tell if a "table" is actually a "view" is to query MySQL's information schema table, which on shared hosts is mind bogglingly slow (like 30+ seconds per query). So we have to do some trickery to make sure we only ever do that test once, and auto-store 'isview' as a fake element parameter (i.e. as if it was something you set in the backend params for the group / join).

Anyway, I've got it on one of my back burners, working on it as I get time, and there's a github issue on it to keep it on the radar.

-- hugh

 

[rackem]

I remember working with you to debug an issue I ran into that came down to a frequent but unnecessary query to the information schema table. Which, as I am on a shared server, pretty much made my site unusable. Whew, thanks again for fixing that! Hope you enjoyed your 4th of July holiday.

 

[rackem]

*friendly bump*