Content Admin Access will set permissions to show or hide others content in the admin/content overview.

Enabling this module will by default show only your own content in the admin/content overview.

By setting the permission "Show all users content in admin/content" you can undo this functionality for the roles of your choice.

This functionality can be useful for websites which use modules like domain access to generate seperate websites from one database. Content Editors will only see their own content.

https://www.drupal.org/sandbox/stijnstroobants/2316745

git clone --branch master http://git.drupal.org/sandbox/StijnStroobants/2316745.git content_admin_access

Comments

PA robot’s picture

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

stijnstroobants’s picture

Title: Content Admin Access » [D7] Content Admin Access
stijnstroobants’s picture

Issue summary: View changes
domidc’s picture

Status: Needs review » Reviewed & tested by the community

I have reviewed and tested this module. Looks good for a first release.

pushpinderchauhan’s picture

Status: Reviewed & tested by the community » Needs work

@StijnStroobants, thankyou for your contribution.

I appreciate your module idea but it contains very less code. Can't you add some more feature with this. Anyways here are my comments.

Automated Review

Best practice issues identified by pareview.sh / drupalcs / coder. Yes http://pareview.sh/pareview/httpgitdrupalorgsandboxstijnstroobants231674... reported number of issues that need to fix.

Manual Review

Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
(*) Maybe: Does not cause module duplication and fragmentation. Can you follow the steps in the link and confirm that the functionality contained in this module should stay separate from Content Access Admin?
Master Branch
(*) No: Follows the guidelines for master branch.
Licensing
Yes: Follows the licensing requirements.
3rd party code
Yes: Follows the guidelines for 3rd party code.
README.txt/README.md
(*) No: Follows the guidelines for in-project documentation and the README Template. Neither README.txt nor README.md file exist
Code long/complex enough for review
(*) No: Follows the guidelines for project length and complexity. Contains less than 20 lines of code.
Secure code
Yes. If "no", list security issues identified.
Coding style & Drupal API usage
  1. (*) content_admin_access.info file need to be fix. See Writing module .info files (Drupal 7.x)
  2. (+) hook_help() is missing in this module.
  3. (*) It contains just only one alter function with just 2 lines of code, difficult to considering as a separate module.

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

As I am not a git administrator, so I would recommend you, please help to review other project applications to get a review bonus. This will put you on the high priority list, then git administrators will take a look at your project right away :-)

Thanks Again!

klausi’s picture

@er.pushpinderrana: short modules are perfectly fine, I don't think we should ask users to artificially bloat them. We just can't give the git vetted user role away on very short projects, but we can of course always manually promote single projects for the applicants. They can always come back later once they have a new project to promote.

stijnstroobants’s picture

Issue summary: View changes
stijnstroobants’s picture

Issue summary: View changes

@er.pushpinderrana: Thanks a lot for your review. I learned a lot from this for my first contribution.

I fixed:

  • Switched to 7.x-1.0 branch
  • Added LICENSE.txt
  • Added README.txt
  • Fixed content_admin_access.info
  • Fixed pareview Drupal coding standards
stijnstroobants’s picture

Status: Needs work » Needs review
potop’s picture

Status: Needs review » Reviewed & tested by the community

Reviewed the code and tested the module.
Now everything looks fine.

You can also mention in your documentation that your module is compatible with
Administration views

stborchert’s picture

Hi Stijn.
As said by Klausi we could manually promote your module to a full project but not give you the "vetted git user" status (see https://groups.drupal.org/node/184389#short for more details).

Do you want us to promote your module?

Btw.: please remove the version from your .info-file since it is added by the drupal.org packaging script automatically when creating the download for a release.

kscheirer’s picture

Status: Reviewed & tested by the community » Needs work

Blocking issues:

  1. Remove license.txt, Drupal's packaging scripts all add all licensing info

Non-blocking issues:

  • You can remove the master branch
  • Rename the 7.x-1.0 branch to "7.x-1.x", and then when its ready for a release, that will be tagged 7.x-1.0

As noted by previous reviewers, this module is too short to grant "git vetted user" role, but we can promote this module for you, we just need some confirmation that this is acceptable to you.

PA robot’s picture

Status: Needs work » Closed (duplicate)
Multiple Applications
It appears that there have been multiple project applications opened under your username:

Project 1: https://www.drupal.org/node/2438375

Project 2: https://www.drupal.org/node/2316793

As successful completion of the project application process results in the applicant being granted the 'Create Full Projects' permission, there is no need to take multiple applications through the process. Once the first application has been successfully approved, then the applicant can promote other projects without review. Because of this, posting multiple applications is not necessary, and results in additional workload for reviewers ... which in turn results in longer wait times for everyone in the queue. With this in mind, your secondary applications have been marked as 'closed(duplicate)', with only one application left open (chosen at random).

If you prefer that we proceed through this review process with a different application than the one which was left open, then feel free to close the 'open' application as a duplicate, and re-open one of the project applications which had been closed.

I'm a robot and this is an automated message from Project Applications Scraper.

avpaderno’s picture