CiviCRM.org Maintainer Modifications or Change Node Author?

[davidbarratt]

Is there a way to allow maintainers to modify the extension page(s) on CiviCRM.org?
i.e. these pages:
https://civicrm.org/extensions/authorizenet-echecknet
and
https://civicrm.org/extensions/campaign-monitor

If that's not possible, is there a way I can change the node author of the page to someone else? If not, who would I contact to have it changed?

Thanks!

[JoeMurray]

Good question. The answer is, yes, of course the maintainer should be allowed to edit that. But then the question of how becomes trickier. I think only the Drupal user author can update it at the moment, or a site admin. So there are two questions: a) what's a short term work-around for you, and b) is there a good way and a budget to update this in a more general way for everyone. I'll loop in FreeForm, who donated time to put together the current system to answer b).

Looking at the two mentioned extensions I see that you are the node author, so you should be able to edit. You'll likely need to do this on behalf of the other maintainers in the short term; alternatively, someone could assign that privilege to one of them. Not great, but hopefully sufficient in the short term.

Sorry this isn't very helpful. But thanks for the feature request. Cheers,
Joe

[petednz]

Not used it but
https://www.drupal.org/project/nodeaccess_userreference
looks like it would do it, if we added a 'user reference' field to the node.

That way the author could add others from their team and they would then also have permission to 'edit'

I.e. Eileen could write the node originally. Then come back and add me via 'node reference' and that should allow me to then do subsequent edits.

[kasiawaka]

When we designed the extensions directory (with core team and few people from the community), we were considering a situation when additional maintainers will need to update the Extensions details. Each Extension has a field "Maintainers" where civicrm.org site users can be added by username. Those maintainers can then edit the Extension details and add new people to the maintainer list.

If there are no maintainers, the original author of the Extension would need to be approached to update the details. What is that author is not available? We may want to have some community process that switches the extension ownership to another author - or maybe, a new extension should be created under slightly new name, especially when many changes were introduced? I think we may want to be cautious on allowing too easily to change the author of the Extension to avoid ownership clashes.

[petednz]

Thanks for info Kasia - I see that field is running off entity reference - out of curiosity how are the permissions granted to let a 'maintainer' edit the node?

EDIT - okay I see a custom module doing the required for CiviCRM. Nice. Will give that https://www.drupal.org/project/nodeaccess_userreference a test some time to see if it delivers the goods too.

[JoeMurray]

@davidbarratt, could you confirm that maintainers cannot edit for logged in maintainer who is not node author? If not, then post bug report on JIRA for infrastructure component. Please post link to jira ißue back here to help close the loop.

Thanks for releasing the extensions.

Cheers.

[petednz]

I just masqueraded as Dave and as far as I could see I/he could then Edit content he was maintainer on, but not other content.

[JoeMurray]

there were a couple of other maintainers on the first extension iirc.

[petednz]

Maintainers are listed publicly on the page eg https://civicrm.org/extensions/campaign-monitor - all those users should have edit rights on the node based on Kasia's info and my limited testing

[JoeMurray]

When I masqueraded as dbarratt I could edit, but not when masquerading as cnasal or cruhlen. This is a bug according to Kasia's description of implemented functionality.

[JoeMurray]

I just created CRM-15588 for this.

[petednz]

doh - i didn't check that dbarret was also down as the author - thanks for double checking on that.

If debugging the issue is problematic then switching to using user reference field and the module above might be an alternative - but let the bug squishing commence ;-)