Some testing was already be done in the original PR. But this needs to be properly retested since there are a lot of differences (not a simple rebase).

There were two issues raised by @kofaysi which I have looked at now:

• Cache: Cache will now be disabled if a user is logged in. This behavior is similar to com_content.
• Duplicate Alias will not be resolved automatically. While com_content does that by appending a number, it's something that is done in com_content both in front- and backend. One can add this in com_contact as well, but it's out of scope fro this PR. For now frontend behavior will be same as backend.

In Joomla 4 we are really trying not to have useless _DESC strings unless they are absolutely necessary - they dont appear to be here

In Joomla 4 we are really trying not to have useless _DESC strings unless they are absolutely necessary - they dont appear to be here

True. Forgot that those were removed in 4.0 when I rebased the PR.
Should I just remove all of them or is there one which needs to stay?

edit: Just removed all of them.

Thanks @Bakual

@Bakual
Please correct the contact admin model to include a similar code to what we have for com_content
https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_content/Model/ArticleModel.php#L632-L649

Also, we just added in 3.9 this
#24216
and I guess we should o the same for contact.

@infograf768 First one is code in the administrator model. Which means that bug already exists in com_contact backend form. So it's unrelated to this PR and can be done in a separate one.

The second one I don't understand the issue it tries to solve. I could change categories just fine in frontend and don't see a reason to prevent this.
Is this related to workflows? If so then it doesn't apply to contacts as it doesn't use workflows.

@infograf768 As discussed in Glip I added code to prevent changing the language of already associated contacts.
I've not touched anything related to categories. That should be done in separate PRs if needed (I don't see the need yet).

There is some additional styling necessary

There is some additional styling necessary

Screenshots to the Styling

Can you check if this styling issue specific to the contact edit form? I'd expect it to be the same as in the article edit form. If the same issue exists there as well, it's out of scope of this PR.

Can you check if this styling issue specific to the contact edit form? I'd expect it to be the same as in the article edit form. If the same issue exists there as well, it's out of scope of this PR.

The styling in the editform is correct. But not in the list view of the Category. Please look to the added Screenshots

I'm currently unable to check this myself as my 4.0 installation is broken. If someone can check why that is, I'm more than happy.

Merged 4.0-dev so it's up to date again.
Adjusted the icons so they match the changes in template. Eg using Font Awesome class now.

Should be testable again.

test on multilingual site, frontend

Creating a new contact in frontend by super user or author
Impossible to choose category (No field). Selecting language works fine.
Error displays

In backend we can see the new contact is created in the Uncategorised category.

Editing an existing contact in frontend (as super User)
Category should display as greyed (but field is not present), possible to change contact language although it should also be greyed.

Please look how we do for articles creation and edit.

When I try to create a new contact, I can select the category just fine from any available category, be it specific to a language or "All". The field is under "Publishing", same place it is for articles.

I'm also able to change language and category of a contact as I would expect.

As I wrote before, I don't understand the category issue and thus if something needs to be fixed it has to be done separately.

I've tested with articles, and it is broken there. So I surely will not do like there ?

Now saw the category field...
Will try asap to explain again the issue in multilingual concerning contacts assigned to a specific user.

Will this feature be available in Joomla 4? Currently using 3.9.14 and I think it would be very useful!

@johnnydevs Only if enough people successfully test it.

@Bakual I think it would be a great feature, I'm willing to test it also :)

@johnnydevs See https://docs.joomla.org/Testing_Joomla!_patches on how you can help.

Resolved conflicts and did some codestyle. Testable again.

I get this error:
0 Class 'Joomla\Component\Contact\Site\Helper\Route' not found

Please see my PR to your branch.

Good find, that is because of the renaming in #27510
Thanks for your PR, I've already merged it.

I checked a contact front end. I do not see the icon for editing, although I logged in as super user.

After applying this patch i could add a menu item for creating a contact.

I created the menu item.

I checked, if I see the edit icon with a already existing contact, when I log in as super user.

I was able to edit the already existing contact.

I could submit a new contact.

If I do not explicitly click on a category, this message appears when I create a contact. In my opinion, this is not an error. You could only make it more user-friendly.

I have tested this item ✅ successfully on 94bb762

If I do not explicitly click on a category, this message appears when I create a contact. In my opinion, this is not an error. You could only make it more user-friendly.

I'd like to follow the behavior of com_content here. But haven't tested this exact behavior so can't say how it is done for articles.
Anyway, it would be easy to do afterwards as well. Would be great if this could be merged into 4.0 so it's part of beta.

@Bakual @astridx I get the error alert "Category not found" after saving if I have select a category for the contact, regardless if the selected language for the contact is "all" or one of the installed languages, and regardless if this selection matches to the category's language or not. Is this expected? Everything else seems to work, including ACL. So shall I give it a good test or wait for some changes? Not sure now, am open for opinions and advise.

@Bakual Could you solve conflict in file components/com_contact/tmpl/contact/default.php and update to 4.0-dev base branch?

And due to recently merged PR #27657 , there was a change of the fontawesome so-called style prefix. It's not really a prefix, it is the first css class used for the style, solid (fas), regular (far), brand (fab), and refers to the package where it's in. Not to be mixed up with the "fa-" prefix at the beginning of the icon name, this stays the same. So e.g. fa fa-eye changes to fas fa-eye, or (just as exmaple, not relevant in this PR) fa fa-joomla to fab fa-joomla (because it's in the brand backage). Could you update your icons? I think they all belong to "fas", but am not 100% sure. Maybe @N3REJ can check.
Update: Silly me. Changes for "fab" have been made long time ago by Brian. Only thing to do here is replace the fa by fas , so e.g. So e.g. fa fa-eye changes to fas fa-eye.

If you don't have time for that, I can make a PR to your branch for this PR so you can merge with 1 click. But before that you should update with the base branch (4.0-dev) e.g. by using the button here at the bottom.

Regarding my test I am a bit uncertain: I had the red error alert shown in Astrid's screenshot also when selecting an existing category. With com_content, when creating a new article in frontend, this doesn't happen in any of these 2 cases. I really would like to see this in beta but would feel more comfortable with givign a good test when this error alert would not be there :-)

Updated branch and adjusted the FA icons.
I'm looking into that category thing if I can reproduce and tackle it

I can't reproduce the "Category not found" thing. Do you know where it is coming from? Maybe related to menuitems?

@Bakual Will check tomorrow after work. But PHP logfile or MySQL logfile didn't show anything special.

@Bakual Strange .. now I can't reproduce it either. I've did (almost) same as last time when I've checked. New clean current 4.0-dev install, one new administrator user (not super user, just admin) created, no categories for contacts created, logged in on frontend as the new admin user and created the contact. No issue. Is late now, have to continue tomorrow.

One question: Is it correct that the frontend editing form doesn't show a field to assign a user to the contact? Or is it a mistake? Or did I just not see it?

@astridx Could you test this again? Am curious if you get the error alert about category not found again. This time I didn't get it, last time I did.

Maybe the last update to latest 4.0-dev base branch solved it? Maybe was something not ok in 4.0-dev when it was pulled in last time? Have to test more tomorrow.

One question: Is it correct that the frontend editing form doesn't show a field to assign a user to the contact? Or is it a mistake? Or did I just not see it?

From memory, which may serve me wrong at this time: In frontend, the user select field can't be used for security reasons. Since you would see a list of all users. So I didn't include that one.
You also can't change the author of an article for that same reason (I believe) in frontend.

In frontend, the user select field can't be used for security reasons. Since you would see a list of all users.

Oh yes, that makes pretty much sense!

Regarding my suggested change for check if published: we meanwhile have real null values for published up and down in J4 and don’t use the old nulldates anymore. I have to check tonight after work if my suggestion was correct or needs a fix maybe. If you are faster you can look up in com_content Frontensegeln editing how it is done there.

I did look up how it is done in com_content before I merged it ?

@Bakual In J3? Or in J4 but before November 2019? In end of 2019 we have changed the nulldate stuff.

Or maybe it was October.

@Bakual Can it be you once gave me write permission for your repository? I wanted to make a PR for your branch. Normally I do this by edfiting a file of the "victim" (=you) and then cancel. Then I have a branch in my repo based on the "victim's" branch, then I pull that and edit locally. But because I have write access it doesn't work like that, it edits directly in your repo. Because I don't have much time I've committed now directly to your branch.

I've changed the check for publish up and down times so it is like we have it here since the nulldate changes end of last year: https://github.com/joomla/joomla-cms/blob/4.0-dev/layouts/joomla/content/icons/edit.php#L36-L41.

If possible, could you revoke my write permission to your repo? I don't feel comfortable with having that permission on other people's repo.

@Bakual P.S.: If one of my previous change suggestions was for a part of code which hadn't been touched by your PR before that, then it was a mistake, not by purpose. I wanted to change only those which you had touched.

Can it be you once gave me write permission for your repository?

That's because you're now a maintainer. When creating a PR I can set a checkbox to allow edits from maintainers.
That doesn't mean you have write permissions to my repo, just to that particular branch. Which is fine for me ?

@Bakual Well thanks god it is possible to undo commits with git. Just in case I edit someone's PR and fall asleep because so late and then my forehead hits the keyboard ;-)

@richard67 @astridx Could you test this again? Am curious if you get the error alert about category not found again. This time I didn't get it, last time I did.

I have repeated my test. I did not get the error alert about "category not found" again.

@astridx Is the test good enough to set a good result in the issue tracker? If so, pls. do.

I have tested this item ✅ successfully on 8f01ab1

ah i was just a bit too impatient ;-)

@richard67 Since something similar has happened to me today, it may also be that I am too slow.

@infograf768 Do you think you have time to test this, too? I am sure if there is a multilanguage issue we have not seen, you would see it.

I have tested this item ✅ successfully on 8f01ab1

RTC