report little bug

[samani]

hi
when i copy the list and i change the form name in the page that has 3 field for new name for form,group,list---> the new copied form has old name and new name not created for that.
i'm using final stable official version of fabrik and joomla

 

[troester]

I can't replicate.
The new list, form, group have the new names

 

[cheesegrits]

I can't replicate either.

-- hugh

 

[samani]

look at the screencast...
it's occur when i use non-english lang.
https://www.screencast.com/t/BpCc4rIVICr6

 

[troester]

Yes, replicatable:
If the form name is starting with a non-ascii it's taking the old form name (list and group are ok).

But you can edit the new form and set the new label directly.

 

[cheesegrits]

Can someone give me an example of text I can use to test, preferably something I can copy and paste?

I tried with a UTF-8 multibyte character as the first character (y with a hat on it, "?Connection Test") but that copies fine.

-- hugh

 

[Bauer]

Speaking of copy problems...
I can't even use the this list copy plugin, because most of my lists use databasejoin elements - and when a row is copied in a list that contains any dbj elements, the records in the associated tablename_repeat_elementname table are not included/updated.

A similar problem exists when a row is deleted - i.e. the corresponding row(s) in any repeat tables are not being purged. I pointed this out years ago and it has yet to be fixed. This means that, even if you don't use the copy plugin, you might have some repeat tables that are 10s or (depending on how active the table is when it come to deleting rows) maybe even 100s of times the size they need to be - because of the orphaned records remaining from deleted rows. Also these 'repeat' tables are not purged from the database when the parent table that uses them is deleted via Fabrik.

I'll be happy to add/edit the code to github that would check all of this and purge the needed records and/or files - if someone can direct me to the correct place to insert the code after a list is deleted or copied, or datbasejoin element is deleted.

 

[cheesegrits]

Can you post a separate thread about this, as it's an entirely different subject (copying list rows, as opposed to copying lists themselves).

-- hugh

 

[samani]

you can use this:
???

 

[troester]

If the form name is starting with a non-ascii it's taking the old form name (list and group are ok).

Correction: if ALL characters are non-ascii it keeps the old form name (e.g. ??? )

 

[cheesegrits]

Ah, OK. Yup. Fixed:

https://github.com/Fabrik/fabrik/commit/1452e559bf3aa63354778835f03b87acd6bdf6e3

-- hugh

 

[Bauer]

Can you post a separate thread about this, as it's an entirely different subject (copying list rows, as opposed to copying lists themselves).

-- hugh

The thread is already there, for over 2 years. No one replied.
Link: Copy problems - followup

 

[cheesegrits]

Well no, I often don't reply in the free forum, as you know. If it's something important to you, keep bumping it, or post in a paid forum.


Sent from my HTC6545LVW using Tapatalk

 

[Bauer]

Well no, I often don't reply in the free forum, as you know. If it's something important to you, keep bumping it, or post in a paid forum.

As I've argued similarly before, IMO it should be important to you too - simply because it is important to the integrity of Fabrik; that when Fabrik 'says' it has deleted or copied something, it should be deleted or copied as expected - regardless the types of Fabrik elements involved.

Neither 'delete row' nor 'copy row' has ever worded correctly if databasejoin or cascadingdropdown elements are involved. The delete problem is an acceptable bug, I suppose - because all it does is leave orphaned records in a table referencing the deleted 'parent' record (but they accumulate and can slow things down).

On the other hand, the failure to create new records in the repeat table(s) when a row is copied makes the copy feature unusable for any List that has dbj elements.

 

[cheesegrits]

The deletion for multi-select joins and CDD's was fixed a year ago:

https://github.com/Fabrik/fabrik/commit/7ce625f0b500e5e031f825d786a08ed45f58a966

The list copying was fixed today.

As you know, I have a very limited amount of time I can devote to Community issues, due to having pesky things like rent to pay. And I have to prioritize them by how many people the issues affect. And "multi select joins with list copy plugin" just doesn't meet the "affects a majority of users" criteria. Judging by the historical data on number of downloads of the list copy plugin, less than 10% of users use it. Of those, I doubt more than 10% use checkbox joins (going by my experience of how many people overall use them). So that's what, 1% of the overall userbase? So it may be a mission critical issue for you ... but it's nowhere near the top of the list on my overall priority totem pole.

Because I'm sometimes a nice guy, I fixed it today. But it took almost 3 hours to track, fix and test. For the benefit of, as far as I can tell, nobody who actually contributes financially to Fabrik, or my next meal.

-- hugh

 

[Bauer]

I get it, really. All of it.
Thanks so much for taking the time to fix the problem, Hugh. Makes my week!

 

[cheesegrits]

-- hugh