ACL for Content Language and dropdown

[infograf768]

Install staging as multilingual with 3 languages with the new asset_id in the _languages table.
Create a subgroup of administrator and add a user to that group.

Edit any Content Language new Tab Permissions.
Set the newly created group to Denied for the "JACTION_PERMISSION"

Save. Now login with the new user and edit an article for example;
Look at the language dropdown: the Content Language which is denied to this group will not display.

[infograf768]

For info, the other Actions in the new Permissions are not used at all for the moment.

[andrepereiradasilva]

since 3.6.0

[andrepereiradasilva]

this will only go for 3.7.0. now.

[andrepereiradasilva]

@infograf768 i notice that by default the permission is set to "Not allowed".
This needs to be by default "Allowed". On upgrade and when creating a new content language.

[andrepereiradasilva]

Also you can't remove the langauge from the dropboxes, we need to have it there, but disabled.

For instance, if i have a module in portuguese even if i can't change the language to portuguese i need to know that it is portuguese and not fallback to "All" when saving.

[andrepereiradasilva]

For info, the other Actions in the new Permissions are not used at all for the moment.

i can work on this part and make PR here and when this is ready (probably for 3.7.0) we send it to main joomla repo, ok?

[andrepereiradasilva]

merge #31 for first part of ACL in languages list view

[andrepereiradasilva]

I think the language itself doesn't need the core.manage acl.
I also would move the core.permission to be the last one.

[andrepereiradasilva]

merge #32 for second part of ACL in languages list view (do not allow to delete without permissions)

[infograf768]

@andrepereiradasilva @robclayburn

In fact, the more I think of it, the more we should limit the new ACL in back-end to the associations (new component and present implementation of associations per item). I.e. not modify for now the contentlanguage field type but create a new field type that would be used only for the new component.

As for the existing associations implementation, it will need a specific coding in the preprocessForm() for each core component.

The reason is that a back-end user who is not permitted to choose a specific content language but is allowed to edit items will not be able to keep the existing tagged language if he has no permission for that language as the field for all items is the default contentlanguage field type.

To implement this, it would need a lot of work which is not for this GSOC project.

Now looking for the implementation of permissions in our present item per item associations.

[infograf768]

@andrepereiradasilva
I merged both your PRs

[infograf768]

Modified access.xml as you suggest. I do not think we need core.permission for the component.

[infograf768]

For contenlanguage type, let's wait we agree on my comment above as we may need a new type instead of modifying the existing one.

[andrepereiradasilva]

Modified access.xml as you suggest. I do not think we need core.permission for the component.

I mean as fallback for "Undefined" (when contentlanguage is deleted and there are items associted to it) language.

[infograf768]

This needs to be by default "Allowed". On upgrade and when creating a new content language.

I would love it but I have no idea how to.
Rob provided a fallback to true when the content language is used without saving, to be B/C

// Default to true for old content languages which have not had their acl saved.
            $canDoAssociations = !is_null($asset) ? $user->authorise('core.permission', $asset->name) : true;

But I have no idea how to set it to Allowed as default if a user edit a content language or create one without dealing with its permissions.
See https://issues.joomla.org/tracker/joomla-cms/7517

[infograf768]

[08/06/16 12:39:17] Thomas Hunziker: You can create the ACL the opposite way: "Block Language". When it's "inherited/disabled" it will show. :)
[08/06/16 12:39:28] Thomas Hunziker: But it's a hack :p
[08/06/16 12:39:51] infograf768: ah, fun
[08/06/16 12:39:57] infograf768: indeed
[08/06/16 12:40:18] infograf768: good idea

But Bakual also says that he would not personnaly add this to core...

[andrepereiradasilva]

But Bakual also says that he would not personnaly add this to core...

why not? add ACL in a component that doesn't have ACL now shouldn't be part of the core?

[andrepereiradasilva]

if is null i think it meand not allowed so it can't.
So, it should be just this line:

$canDoAssociations = $user->authorise('language.permission', 'com_languages.language.' . (int) $language->lang_id);

[infograf768]

To be B/C, it had to be true by default, as Rob proposed. If your last ACL patch goes in, we can test what it gives then and decide.

[andrepereiradasilva]

my patch that sets "Allowed" as default is already integrated into this one :)
so IMO this doesn't make sense anymore

[andrepereiradasilva]

@infograf768 where we are on this.
we will need this merged for associations gsoc project

[infograf768]

@andrepereiradasilva

As I said above, we need to create a new field type and that field type should normally be placed in com_associations. Therefore we have to wait for com_associations to have a bit more than what it has right now...

[andrepereiradasilva]

ok then let's wait

[infograf768]

This is what I proposed in chat:

There is a solution for the time to come.
We do not change the JHTML contentlanguage (which I was doing here), neither do we change the contentlanguage field itself for now.

What we can do is create a new JHTML assoclanguage in com_associations/helpers/html/ and a new field type assoclanguage in com_associations/models/fields/ loading the new JHTML.
then we use the new field in filter_associations.xml

For the side by side view, we modify itemlanguage.php to take into account the new permission.

This modified PR would be included when we propose com_associations to PLT

[infograf768]

I have prepared the 2 necessary files for com_associations + some changes for filter_associations.xml and itemlanguage.php

[infograf768]

Found a possible issue in this PR concerning editing associations in the existing interface (not in com_associations).
I think that if one has access to edit an item, one would be able to choose an associated item, but would only be able to edit it if permission is granted for that content language.

The code we have now does not let choose an associated item.

Therefore the code would be for each component concerned:

                if (empty($data->language) || $tag != $data->language)
                {
                    $add = true;
                    $field = $fieldset->addChild('field');
                    $field->addAttribute('name', $tag);
                    $field->addAttribute('type', 'modal_article');
                    $field->addAttribute('language', $tag);
                    $field->addAttribute('label', $language->title);
                    $field->addAttribute('translate_label', 'false');

                    // Do we have permission to edit this associated item?
                    if ($canDoAssociations)
                    {
                        $field->addAttribute('edit', 'true');
                    }
                    $field->addAttribute('clear', 'true');
                }

@andrepereiradasilva
What do you think? We should take a decision.

(for menu items, as we do not have a modal, we can't edit anyway.)

[andrepereiradasilva]

i'm not yet confortable in understanding the complete solution.
I think we need to put it all in one text so we can decide better to check possible implications.

[infograf768]

@andrepereiradasilva
@roland-d

In fact, night having passed over, what I just wrote above yesterday makes no sense.
Edit should not be depending on Content Language permissions.

After some thought, here is what I came to:

Although we should keep what is done here concerning com_languages permissions (i.e. creating, editing, etc. the Content Languages themselves in the Languages Manager, we should reconsider the part concerning the use of these permissions for associations.

A user should be able to Associate items or not, period. The permissions for that should be in com_associations, used for that component (access or not to the component) but also everywhere where we can associate, i.e. in each component using associations.
In that case, we do not touch at all to the contentlanguage field (in fact JHtmlContentLanguage)

This means that the Associations Tab in general (in each component) would display fully ONLY when the user has permission (fetched from com_associations). Modification to do in the edit_associations.php file.

In these files we do have now:

if ($this->item->id != 0 && $this->item->language != '*')
{
    echo JLayoutHelper::render('joomla.edit.associations', $this);
}
else
{
    echo '<div class="alert alert-info">' . JText::_('JGLOBAL_ASSOC_NOT_POSSIBLE') . '</div>';
}

We would fetch the user, check if he has permission to modify associations and, if not, display a new message. The alert would come before the other one.

For the items themselves, their modification should only depend on the component concerned permissions (edit, create, edit_own, delete), as it is today.
Evidently deleting an item would also, as of today, de-associate it.

NB: Being able to assign/modify a content language to an item, as I wrote in #30 (comment) is a too much complex implementation for now and should be considered for 4.0.

[roland-d]

@infograf768

A user should be able to Associate items or not, period.

I believe that should be the case. He/She can't manage the item without proper permissions but still should be able to associate it.

[sanderpotjer]

@infograf768 is this still the latest attempt to get ACL for content languages in Joomla, or are there other / more recent PR's?