make the related_flag id unique

Given the way the flag module is doing it, will your patch solve the problem? The reason for doing it the way it was done was to be compatible with the flag module. Maybe in the flag case the flags are managed from one place only and because of that it will not be able to create flags with the same name?

What did you do to create the original error? Is that because different user has the same name of the flag_lists?

The unique part of this patch will later go into #3202208: Move Flag Lists actions into a submodule . The "has action part" might not be necessary.

Yes, please!

Thanks!

This is a slightly different patch. To my understanding it do the same. It doesn't however use hooks for the modules own entities.

There are still some things for me to verify. They are mostly related to importing from an old D7 site.

Hmm, there were two active dpm() calls in the previous patch...

I have been running with this patch for some time now and I see no problems for my use cases.

The pushed patch to the -dev also include an enhancement so that it is possible to identify the creator of each flag_list in the overview.

Hi, sorry for not getting back to you earlier but I have been on vacation!

The main reason for not going directly for your solution was that it was not implemented inside the Class. When I looked into moving it into the Class there was no obvious way of getting the id of a entity to be created before it was actually created. It was a sort of "Catch 22" situation if I remember correctly. But of course it should be possible without indirectly affecting the useful length of the name (Like truncating the name of the Flaglist to be created).

Give me some time, (Being back from vacation means that my backlog currently is quite long...) and I will try to solve it and also fix an update function to update existing records.

/Thomas

An attempt. But I need to review it a little more.

Now also with an update function to update all old records to the new naming scheme.

I am getting this error from the update in your new patch:
Call to a member function id() on null in flag_lists_update_8004()

Following this comment in another issue (and using DISTINCT in the first query, otherwise the first query is larger than the second), there are 2 names of relatedflag in flagging_collection_field_data that do not exist in config. I checked a copy of the DB from before trying to run this, and there was no discrepancy there before.

In other words, after trying and failing to run the update, this turns 67 rows (2 if I use 'SELECT DISTINCT relatedflag'):

SELECT *
FROM flagging_collection_field_data
WHERE relatedflag NOT IN (
    SELECT fd.relatedflag
    FROM flagging_collection_field_data fd
        INNER JOIN config c
        ON c.name LIKE CONCAT('flag.flag.', fd.relatedflag)
);

I will have to stick to RC1 for now.

Hi,

thank you for the report! Let me look into it!

/Thomas

Hi,

I can't reproduce it here but what you basically is proposing is to add "DISTINCT" into all the 5 update questions in flag_lists_update_8004?

/Thomas

Is this what you propose? I have not been able to test if it is OK.

I have also moved the update to a new update run. I am not sure if this is necessary. If you have skipped -rc2 then it should not be necessary because then 8004 has not been executed yet. But I can't fully figure out what happens if you have run -rc2. In my case it worked with -rc2. The upgrade contains a check to see if the name already is updated, so there should be no problem to run it again...

Unfortunately there is no such thing as distinct for updates. So this must be related to something else. To places where things has been shown to cause problems are the following:

#3257955: Error: Call to a member function isSyncing() on null in flag_lists_actions_flagging_collection_presave() (line 71 of modules/contrib/flag_lists/modules/flag_lists_actions/flag_lists_actions.module).
#3259130: Views support

Marks this as need more info

This patch doesn't fix the problem in #24 but it mitigates it so that it can be fixed later.