Port field permissions to drupal 8

Any progress?

double post

Are you still working on the migration?

FWIW, the availability of hook_entity_field_access[_alter] seems to indicate this should not be too difficult. The hooks are triggered individually on view/update/delete.

The main issues are probably:

• ensuring consistency of access checks given field caching
• performance
• building a usable UI to define which permissions to instrument

This would be a very useful module to port to D8.

Wondering when the drupal 8 porting will start for this module, as this it is quite fundamental to many tasks.

Hi, have someone started with porting this module to D8?best regards andy

Looks now is a right time to port

@sic looks nobody works on that

Related pages

• Drupal 8.0.0 will be released on November 19, 2015
• News about "Porting modules and themes to Drupal 8 "
• "Drupal Module Upgrader" module. Which can do some of the port automatically for you, covering many API hooks.
• Documentation about "Converting 7.x modules to 8.x"

We would be happy to contribute testing patch, quality assurance, documentation, and agile project management services if needed

This module would be essentiel for my new D8 project. Any progress appreciated a lot. All the best, John

I also need this module to migrate my D6 site to D8. Thanks...

What's the progress on the port process. I would like to port this module to d8 if anyone is not doing it already.

I recommend you go ahead with the port, the module contributors have shown no interest in responding to this thread, even after reaching them via pm. While you are at it create a sandbox project, that ways it can be a new module rather than being at the mercy of non responsive module authors.

Hm. I am just also waiting for the port of this modul. Unfortunately i am not a coder ... :-(

But there is still some information how to build such a modul:

https://api.drupal.org/api/examples/field_permission_example!field_permi...

It looks like Asibona has started work here:
https://github.com/drugo32/field_permissions/

https://github.com/drugo32/field_permissions/

Hi, Is there plans to introduce D8 version of this module? We (@InternetDevels team) would like to help you with development of this version. Thanks, sic.

I put the changes on the master and now it works and if you want you can test,

Could we please have an 8.x-1.x branch to patch make issues against?

@asibona: It'd be great to port the tests, too. https://www.drupal.org/node/2166895 https://www.drupal.org/node/2118119

Speaking of Examples, there's an 8.x version of field_permission_example already: https://www.drupal.org/project/examples

@asibona: I created pull request to your GitHub, so you are now able to edit fields without several fatal errors.

@Mile23 :Immediately creates a branch called 8.x-1.x. and thanks a lot for the sample link.
@mirom : Thank you so much I try to take your branch and to do testing. :)

@asibona - thanks, any luck so far?

@all Hi guys i'm finishing to write test, when i finish i will push in 8.x-1.x drupal branch, i think do it in weekend :)

hi guys.
I added the permissions to administer the module and the first test file in remote branch 8.x-1.x.
I continue to write the rest of tests on the comment fields and on users fields.
:)

Hi asibona, I just wanted to thank you. This module is one of the big ones I use for my sites so I really look forward to the d8 port, and I really, really appreciate all your hard work!! =D

How is the work on this going on?

well, the module is testable, I'm finishing up writing tests.

Great! :)
Which branch do we use: 8.x-1.x or test?

I am referring to this --> https://github.com/drugo32/field_permissions/tree/8.x-1.x

@joco_sp then use the 8.x branch - 1.x
write me if you have problems :)

@all PULL REQUEST
I solved many bugs and now passes the test !!!
for the moment only on the body of a new content.

:)

good evening.

Could you please provide a patch here so we can put it in the project repo?

Thanks.

Hi @Mile23 here is the patch, let me know if it works.

I am testing the 8.x branch - 1.x for a couple of days and it seems to be working fine.
Will keep you posted if I try it on other fields or if I encounter some issue.

I am testing it on core 8.0.6
Testing on: Entity reference - Taxonomy term fields

@joco_sp thank you.

@All
HI.
I finished writing the comments and fix the code to make php-cs.
the next step
I add JavaScript to manage the permissions matrix
and I write tests for other cases.

I just finished loading a patch,

I created a patch which only creates permissions when field_permissions is used on a field. This prevents the permissions table to get overpopulated when installing the module.

@Napche
Thanks a lot. :)
That was one of the things that I needed to continue with the tests.

:)

I went push the several changes.
Including the previous field_permissions.no_permissions_for_default_type.2196303.patch. #35

I add hook_help descriptions
add file field_permissions.links.menu.yml
and I have added more consistent comments to the functions.

Checking the field permissions on a field located on the user (profile) form results in an error (Call to undefined method Drupal\user\Entity\User::getOwnerId()). Added a patch to fix this error.

@cgoffin Oh yeah.
I think we have to add fields to comments and taxonomies.

Thank you :)

@All
Hey guys
I added the js library. :)
missing only to write the test !!!

@All
I have push all commit to branch 8.x-1.x

I found a bug with the Boolean fields.
You can see more about the error and setting in the attached images.

So far it seems to work with:
- Entity reference - Taxonomy term fields
- Image
- File
- Inline entity reference
- Text area with summary

Tanks @joco_sp
I just finished loading a patch.
By.

There was a bug in the patch of comment 38. Patch added.

@cgoffin Thank you very much.

Hi to all
I added the test and fixed SOME bugs :)
In testComment four tests fail, but I'm working.
I still have to work on the field comment related to the node,

for the moment
work in comment field.
work in node.
work in user.
In taxonomy field on term can not implement, because It not has author.

in the future
implement on Field_collection

I found a bug doing tests,
in field_permissions.schema.yml
error : {"permission_type_body" not schema mapping present}

I added in files.
Field_permissions.settings:
type: config_object
label: 'Field UI settings'
mapping:
permission_type_body:
type: integer
label: 'Value public private custom permission'

But we must implement Dynamic type with [%parent]
Thank you all

Setting to NR since there are patches here.

Could somebody update the issue summary, and perhaps update #2608918: [field_permissions] Field Permissions to describe the current status of the port? It's hard to tell whether folks should be focused on the github repository, or if we could get an 8.x branch created on drupal.org, then folks would focus on the issue queue.

I work out the last bugs (#46) and try to push on the repository of drupal.org.

yeah !! :D
I fixed the bug.
NOTICE: the value of the fields is to be inserted again.
I'm improving the code and the comments, and then I'm doing the commit on drupal.org.

I made a request to implement the permissions on the FIeldcollection type.
https://www.drupal.org/node/2734551

I simplified the code , and disabled tests for the comment field.
I commit it on drupal.org.
For the moment I am trying to solve the compatibility with field_collection isseu.

HI @ALL

I'm watching this guide
https://www.drupal.org/node/711070#start

but I do not understand how to create the starting branch , someone wants to help me out? Or possibly make the initial commit?
thank you!!! :)

@asibona: Thanks for all of your work on this.

I didn't get a chance to do a thorough review, but in taking a quick look, I see lots of spelling and grammar problems in the patch. In places, these are making the code difficult to read. Would it be possible for us to get this edited before it's committed?

I'm also seeing a lot of code blocks commented out. These need to be removed.

Did you get commit access to the project from the current maintainers? If not, you'll need that before proceeding. Or we can also have the existing maintainers commit this once the status changes to RTBC.

For branching help, see Creating a branch or tag in Git.

@colan Thanks for the answer :)
I try to clean up the code and remove the unnecessary comments.
Every time I add something I create the patch with the changes, is it ok?

Once I am finished with this, I will contact with the current maintainers.

Bye bye.

@asibona

It is unnecessary to continue to upload patches. Apply your changes to the existing module Git tree so there is continuity, then make the module available as a Drupal.org sandbox or Github.

It will make review much easier since it a bulk change. Viewing diffs (patches) tells us nothing when you are doing a big change like D7 -> D8.

Let the maintainers and the followers of this thread know of major changes by posting a comment here.

I skimmed through and saw a lot of calls to the global Drupal object. Please familiarise yourself with dependency injection.

@dpi
ok tanks, :)

I Push a new the changes, :)
Now it works on the comment fields.
I finish writing the test and create new repositories.

By.
Ale :)

Thanks very much :-)

Updated the IS to point at the GitHub repo.

@asibona here are a few comments on the state of the port:

• The 8.x branch appears to have been started as a separate repository, as opposed to branching the existing git repository. This won't matter if your work is brought in as a patch. However, if the branch is merged, then this might cause issues with git history.
• Because of this, several files that should never be committed are in place (LICENSE, and then parts of the field_permissions.info.yml file that are automatically added by Drupal.org)
• In manual testing, simply enabling the module removes access to the home page (node view) and any existing content for basic authenticated users. I haven't had a chance to dig into that

I think next steps are for somebody to apply to help maintain this project, as I don't know if any of the current maintainers are active enough at this time to take this on.

In manual testing, simply enabling the module removes access to the home page (node view) and any existing content for basic authenticated users. I haven't had a chance to dig into that

I was mistaken on this point. Another module and set of permissions was interfering with access.

I opened #2754699: Offering to co-maintain Field Permissions to try and get this moving along.

I've merged @asibona's branch from github here on Drupal.org. Thanks so much @asibona!

I'm closing this out as there is now a branch here to file additional issues against.