BUG: Field element with Advanced / Disable Element = Yes still attempted update.

[Sophist]

I have joined my table to Joomla's users, user_usergroup_map and usergroups tables.

When I save the form it tries to update the user_usergroup_map with:

UPDATE `j3_user_usergroup_map` SET `group_id`='13' WHERE user_id='456'

This is invalid because there are several records with user_id='456' (all of which will be updated by this) and there is a primary key on user_id+group_id.

I have set the group_id element to have both Read-Only and Disable Element set to yes, but this UPDATE statement is still executed.

 

[cheesegrits]

Well, I don't think you'll be able to join to the user_usergroup_map, as we don't support composite keys.

-- hugh

 

[Sophist]

I don't want to support composite keys - I want it not to attempt to update the table.

I will see if I can track this down further - it may just need some improvements to the description.

 

[Sophist]

As far as I can tell, it is the Store in Database which controls the writes to the database, and disabled controls the html disabled attribute.

If you agree with this I will submit a PR to change the descriptions of these fields to be more meaningful.

 

[Sophist]

P.S. Setting Store in Database to No for InternalId elements gives an SQL error on the Update statement with an incomplete WHERE clause (the internalid is used to create the where clause).

I do not propose to fix this, but instead to document this in the wiki.

 

[Sophist]

https://github.com/Fabrik/fabrik/pull/1901 submitted to improve the description of the Store-in-Database and Deleted fields.

 

[cheesegrits]

I'd rather not put that kind of hyper-specific info in the tooltips. Tooltips need to be the general overview, with more detailed information in the wiki. For example, the info about the internalid element ... I would strongly suspect that you are in the only person in the history of Fabrik to turn off Store In Database for an internalid element. So it's appropriate for a wiki entry, but just makes the tooltip itself harder to understand for non-techies.

Also, don't worry about changing other translations, except maybe to comment out a line if it isn't actually translated. I recently modified the plugin language loading so if a given language doesn't have a tag, it'll default to en-GB (although I do need to check that the main backend language loading works the same, come to think of it). So as long as en-GB is up to date, and the other (untranslated) language tags are commented out, you don't need to update other languages (unless you are translating them).

I'm not entirely sure why, but at some point early in Fabrik's history, a lot of other languages got the comment prefix removed from untranslated strings. So definitely worth fixing that if you change an en-GB translation - make sure any untranslated versions of that tag are commented out.

-- hugh

 

[Sophist]

I changed the other files because they had the same text in them. I will take out the internalid note - I was in two minds myself about whether it should be in the wiki.

But I am willing to bet I am not the only person ever to join to the Joomla users table - though I might well be the only one to be persnickety enough to ensure I don't write the same data back to the joomla tables when I write to my own join to those tables.

 

[cheesegrits]

You definitely aren't the only person to join the users table, I do it all the time, but there's something about the way you are doing it which is different to the way it's usually done. Which is fine, but leaves you out in the cold when it comes to getting it to work.

So yes, comment those untranslated strings out in the other languages, rather than changing the text. I'll have a look later and make sure we do fall back to en-GB if a language tag doesn't exist, for the main component language. I know the change I made recently works for plugins (so when you load a form or element plugin on the backend) but I can't remember if I checked the extension backend itself.

-- hugh

 

[Sophist]

What we probably need to do its write a script that runs through all the translation files in Fabrik and removes everything that is either commented out or the same string that is in the en-GB file.

Also, we should probably delete the "en" language files (because the correct files are en-gb).

Want me to do this?

P.S. I was tempted to say we should just comment out the english in non-english files, but that would still leave a big overhead every time we change english text.

 

[Sophist]

P.P.S. Did we ever think about switching to using Transfex as a translation platform?

 

[Sophist]

Yes - the outer join is a bit odd I have to admit - but I want to present the data editor with a complete list of users, and not have to have them manually add a row for every new user. (I suppose I could have done it differently by creating missing records as a pre-data load event and then load the list as normal with an inner join - but this seemed more intuitive when I started to develop this bit of functionality. That said, if you think that it will be a support nightmare this way, it would not be too much effort to switch.)

All that said, switching to an INNER JOIN would still require turning off the Store-in-Database for the joomla native tables to avoid writing the data back to these tables. (As a To Do, when you do a join in the list and it autocreates the Groups/Elements for the existing Joomla tables, you might want to default the Store in DB to No.)