conflicts resolved

This pull request has been automatically rebased to 5.0-dev. No new features will be merged into Joomla! 4.3 series. Joomla! 4.4 series is a bridge release to make migration from Joomla! 4 to 5 as smooth as possible.

Would be nice to get some testers here as there were many people asking for this field

@brianteeman The update SQL scripts need to be renamed due to the rebase to 5.0. The new names should be e.g. "5.0.0-2023-07-23.sql".

@brianteeman The update SQL scripts need to be renamed due to the rebase to 5.0. The new names should be e.g. "5.0.0-2023-07-23.sql".

renamed

This doesn't consider my concern about groupfieldlist, and the default_value === null for other field types. Or is this fixed in the meantime?

Should we change the date to 2023?

Should we change the date to 2023?

yes - I noticed it this morning over coffee and am doing it now

Used the discover for a test and it works great. It needs test with fresh installation and update.

thanks for testing. I would use this a lot with one of my custom components. Currently its an ugly sql field

Testing, got as far as Create a menuitem custom field and got this after selecting the New button:

Fatal error: Class Joomla\Plugin\Fields\Calendar\Extension\Calendar contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Joomla\Event\SubscriberInterface::getSubscribedEvents) in /Users/ceford/Sites/joomla-cms/plugins/fields/calendar/src/Extension/Calendar.php on line 26

Uninstalled plugin, reverted patch and the New button works as normal. Work needed?

@ceford Same thing: We have conflicts in the base.sql files for new installations, so when you are testing, the database might not fit. Please don't waste your time with testing PRs which have conflicts. As explained earlier by @brianteeman in another PR, you can see if a PR has conflicts on GitHub at the bottom of the PR.

Conflicts now resolved

I have tested this item ✅ successfully on 8b6d7f0

Front end text from test article:

Test 39192

Details
    Written by: Cliff 
    Category: Uncategorised 
    Published: 18 September 2023 
    Hits: 2

    Test 39192: Atomic 
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/39192">issues.joomla.org/tracker/joomla-cms/39192</a>.</sub>

This pull request has been automatically rebased to 5.1-dev.

I have tested this item ✅ successfully on 8b6d7f0

@brianteeman I've allowed myself to fix the conflict in the FieldsPlugin.php file. What remains to be done is to rename the update SQL scripts from "5.0.0-2023-09-15.sql" to the right version and a newer date, e.g. "5.1.0-2023-11-23.sql". Could you do that? Thanks in advance.

@richard67 thanks for fixing the conflict - my available time is heavily restricted now. I have renamed the files

I have tested this item ✅ successfully on 9c8a2b5

I have tested this item ✅ successfully on 9c8a2b5

I have tested this item ✅ successfully on 9c8a2b5

I have tested this item ✅ successfully on 9c8a2b5

I have tested this item ✅ successfully on 9c8a2b5

RTC

@brianteeman Please rename the update SQL scripts from "5.1.0-2023-11-23.sq" (mind the missing "l" at the end of the extension) to something newer than "5.1.0-2024-02-10.sql", which is the latest update SQL present in the 5.1-dev branch. I suggest to use "5.1.0-2024-02-26.sql" because "5.1.0-2024-02-24.sql" and "5.1.0-2024-02-25.sql" will be used by other PRs.

It will not required new human tests, but the PR should not be merged as it is. With the extension "sq" instead of "sql" the scripts will never be run.

Thanks in advance.

P.S.: Or let me know if I shall do that for you, rename the update SQL scripts.

@richard67 my time in front of a computer is so restrictd right now could you do it please

Done, update SQL scripts renamed to "5.1.0-2024-02-26.sql".

thanks @richard67

Hmm, the update SQL scripts would again need to be renamed to something newer than „5.1.0-2024-03-08.sql“, but if this PR will not make it into 5.1 and be rebased to 5.2 it would need to change also the „5.1.0“ to „5.2.0“.

@LadySolveig Is there a decision yet?

after 488 days if there is no decision then it might as well be closed

Please don’t close. I am optimistic there will be a decision, and then I can help with rebase and update SQL scripts rename.

@richard67 @LadySolveig @pe7er
any decision on this RTC pr. really dont want to have to redo it again for a third release if nothing will happen

@brianteeman I am not a release manager so I won’t decide anything. But @bembelimen is. If this PR is merged into 5.1-dev, the update SQL scripts will need to be renamed to a newer date. And if it will be rebased to 5.2-dev they need to be renamed, too.

@richard67 yes I am aware of that but I am not going to change this pull request again if it is never going to be merged. Thats just a waste of my time. I will update it one last time and then if there is no response I will just close it

This pull request has been automatically rebased to 5.2-dev.

Closed due to the complete lack of any response from release managers which is very disappointing.

@brianteeman Sorry to see that you've closed this issue. @woluweb and I just started as Joomla 5.2 Release Manager 1 week ago. This PR was on our list of PRs to check out.

@pe7er it has been sat here since 2022 and i have updated it 4 times for differing releases. Even though it was RTC and I asked multiple release managers they never had the courtesy to reply.

re-opened and updated for 5.2 - will not update again

@brianteeman I'm sorry that you haven't received an answer here for so long. We discussed this PR at the end of Feburary and made a decision against it. Some reasons are:

• No access rights are checked
• Changing default value in the FieldsPlugin class, this shouldn’t be done in the PR
• Menuitem is only used in 4 places in core, better would be menu_modal

We have noticed at the last meeting that we hadn't posted an answer. So doing it now to stop wasting time on it.

would have been niced if "you" had responded to my numerous requests. Your reasoning is wrong and inconsistent with all the other fields but "you" always know better.

"you" is not an individual but a collective

PS I can accept this being rejected but your reasoning must be valid.

1. No access rights are checked for similar fields such as user and usergroup
2. Default value is not changed. It just checks correctly for null - this was code from @HLeithner previously merged and reverted in error
3. Irrelevant how many times it is used in core. this is for a custom field

All field types that joomla supports should be available via plugin to be used in custom fields.