User tests: Successful: Unsuccessful:
This PR adds frontend editing to com_contact.
Adding form view and accompagning controller and model to com_contact frontend
Test adding and editing contacts from frontend. If the user is authorised, he should see an edit link in the category view and contact view. The category view additionaly has a "New" button.
The featured view doesn't have any such links.
There is a menuitem to point to create new contacts.
Test that data doesn't get lost when saving (especially data not available to edit in frontend vs backend).
Test especially also ACL. JSST should look over it for possible security issues.
Works
Frontend editing not possible.
A new help page will be needed. Possibly also other doc pages.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_contact Language & Strings Front End |
Labels |
Added:
?
?
|
Codestyle issues solved now.
After saving in PHP error log:
PHP Notice: Undefined index: params in \administrator\components\com_contact\models\contact.php on line 353
I have tested this item
We have modify a single contact and it has worked fine
We have created a new contact from the category view and modify it
We have checked the public cannot edit the contacts
We have created a menu item for new contacts
Everything worked as expected
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
@joomla/cms-maintainers Can I have a decision here if this goes into 3.10 or 4.0?
I think the decision was no new features in 3.10 (or whatever the bridge version to 4 is called) so this has to go into 4 if we don't have a minor version before the bridge
I have tested this item
All the following are frontend issues.
Custom field groups are not visible and editable. Even not for a new contact.
I sometimes experience a major delay in applying the access or view rights:
The privacy request label is not rendered, but I guess this is not belonging to this PR.
In the list of the items (contacts) of the category, two edit link are accessible: an icon and a text link.
Oh, and after reverting the patch I realized that the subcategories heading was not displayed in any of the categories, while the patch was applied.
Labels |
Added:
?
|
Oh, and after reverting the patch I realized that the subcategories heading was not displayed in any of the categories, while the patch was applied.
I can't imagine how that could be related to this PR. I didn't touch the code related to showing subcategories.
The text link context help (on cursor hover) reads "Edit article".
Found the culprit for that one. Good catch.
The icon context help reads "Edit contact | Published | [some date] | Written by" -- the message is truncated, the name of the editor is not displayed.
this shows fine for me. Could it be that the user who created that article has been deleted?
Regarding the privacy stuff, I have no clue how that is supposed to work. I've never looked into that so far.
With Editor user you refer to a user with edit privileges? And non-editor would be one who is only able to create?
Oh, and after reverting the patch I realized that the subcategories heading was not displayed in any of the categories, while the patch was applied.
I can't imagine how that could be related to this PR. I didn't touch the code related to showing subcategories.
I have missed that one. It is me, who did not checked back on it. Sorry, The subcategories show up.
The icon context help reads "Edit contact | Published | [some date] | Written by" -- the message is truncated, the name of the editor is not displayed.
this shows fine for me. Could it be that the user who created that article has been deleted?
No, he/she still exist. I checked and it does not happen with the new commit. The snippet seems non-truncated and full.
Regarding the privacy stuff, I have no clue how that is supposed to work. I've never looked into that so far.
With Editor user you refer to a user with edit privileges? And non-editor would be one who is only able to create?
Yes, please. It is about the right to edit and create the contacts. But we have only users who can both create and edit and those who cannot do it.
I have tested this item
I sometimes experience a major delay in applying the access or view rights, described earlier. Login and logout various test users. The edit links appears after few seconds of active browsing the contact items.
Custom field groups (tabs) are missing from the edit interface entirely.
No, he/she still exist. I checked and it does not happen with the new commit. The snippet seems non-truncated and full.
I haven't changed anything there, so it seems to have been a glitch.
I sometimes experience a major delay in applying the access or view rights, described earlier. Login and logout various test users. The edit links appears after few seconds of active browsing the contact items.
That's real strange. it's probably related to session lifetimes, cache or whatever. You probably get the same effects with com_content frontend edit.
I doubt it's related to this PR itself.
Custom field groups (tabs) are missing from the edit interface entirely.
Yep, confirming that and I need to investigate why that is.
I also have to test again with various users to see what this permission thing is.
Status | Ready to Commit | ⇒ | Pending |
Labels |
Back to pending.
Back to pending.
Labels |
Removed:
?
|
I found the issue with the custom fields. They were actually showing, but those from the mail section and not the ones from the contacts.
I've now renamed the form so I can properly detect it in the validateSection function. Now it works for me.
I couldn't reproduce the permission issue with the editor and non-editor users. That sounds like something on your setup which doesn't play nice. Maybe cache related?
I found the issue with the custom fields. They were actually showing, but those from the mail section and not the ones from the contacts.
I've now renamed the form so I can properly detect it in the validateSection function. Now it works for me.I couldn't reproduce the permission issue with the editor and non-editor users. That sounds like something on your setup which doesn't play nice. Maybe cache related?
I switched off System cache (OFF - Caching disabled) and the behavior is correct -- tried to log in and out of various users a couple of times. Previously the progressive caching has been set for system cache. Does that make sense to you? I have no knowledge about these cache relations.
I have tested this item
Saving data ok.
Custom fields displayed, editable.
The previously experienced regression with view and edit rights was due to system cache probably. System cache set to "OFF - caching disabled" instead of the previous "ON - progressive caching".
By using the frontend, I was able to create two test contacts with the same alias and no warning has been issued.
When creating the same test contact in the backend, a warning has been issued
Although, no alias has been inserted by the editor, only the contact name.
I have a single remark to both above behaviors:
I'll check the cache thing. I haven't used cache much myself but I think it usually gets disabled when a user is logge din. Maybe that's not done in com_contact.
I'll check the alias as well and see how that is done in com_content. So we have the same behaviour in both places.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-03-22 10:18:20 |
Closed_By | ⇒ | Bakual |
I will solve the various codestyle issues later. Those are the ones PhpStorm either does wrong or doesn't detect.