extensions-directory issueshttps://lab.civicrm.org/extensions/extensions-directory/-/issues2018-03-29T14:31:04Zhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/24Auto-releaser: Allow hosting extensions on lab.civicrm.org2018-03-29T14:31:04ZbgmAuto-releaser: Allow hosting extensions on lab.civicrm.orgCurrently the extension directory only allows hosting extensions on Github.com. Now that we have https://lab.civicrm.org/extensions/, we would like to allow/encourage to host extensions there as well.
Reported by @jaapjansmaCurrently the extension directory only allows hosting extensions on Github.com. Now that we have https://lab.civicrm.org/extensions/, we would like to allow/encourage to host extensions there as well.
Reported by @jaapjansmabgmbgmhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/23Allow in-app messages from extension authors2019-07-19T19:49:31ZbgmAllow in-app messages from extension authorsProposal discussed at CiviCamp Brussels, for consideration by the Ext WG and Core Team:
Context: Extensions do not have a way to communicate with their users. This may be to communicate:
* that the extension is being deprecated (possibl...Proposal discussed at CiviCamp Brussels, for consideration by the Ext WG and Core Team:
Context: Extensions do not have a way to communicate with their users. This may be to communicate:
* that the extension is being deprecated (possibly in favour of another one),
* fundraising request,
* promote trainings/workshops, or other services.
Implementation:
* Partner benefit (as a way to validate that the extension author's message is compatible with CiviCRM values/branding/community).
* Currently in-app messages are fed from a google-doc. In the short term, we could open up write permissions to the google-doc to a few people/partners, who could handle the requests. The requests could be done on Mattermost or Gitlab (transparency).
* In-app messages for extensions, for now, would only be shown to administrators (in-app messages currently have options to show that message only to admins, all users, etc)
* and of course, an in-app message would only be shown if the extension is enabled.
Technically, this requires small changes to civicrm core, as well as the in-app messaging app. As the community grows, eventually, we may want to have a forms for this on civicrm.org, but that's more work, which we can address when it becomes necessary.
cc @xavier @totten @ginkgofjg @AllenShaw @joshhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/22In-app extensions manager does not notify about new release of com.elisseck.c...2020-04-22T17:24:53ZginkgofjgIn-app extensions manager does not notify about new release of com.elisseck.civihoneypotTo reproduce, install v 1.0.3 of the extension. Visit the extensions manager, hit refresh. Despite the publication of a [release node](https://civicrm.org/extensions/civihoneypot/105) for v 1.0.5, note that you are not prompted to upgrad...To reproduce, install v 1.0.3 of the extension. Visit the extensions manager, hit refresh. Despite the publication of a [release node](https://civicrm.org/extensions/civihoneypot/105) for v 1.0.5, note that you are not prompted to upgrade. Note that the same is not true for other out-of-date extensions. (On the system where this behavior was discovered, CiviRules was also out of date but showed that an upgrade was available.)
Created as an issue here (rather than in the extension's issue tracker) because -- with the information we have now, anyway -- this seems more like an infrastructure problem than something the maintainer needs to change.
Note that this extension, despite submitting a request, has not yet been flagged for automated distribution. Could it be that extensions which are not whitelisted are treated differently?ginkgofjgginkgofjghttps://lab.civicrm.org/extensions/extensions-directory/-/issues/21"The Fully Qualified Name did not match parent extension" validation failure2021-03-16T21:33:06Zxurizaemon"The Fully Qualified Name did not match parent extension" validation failureSee also #12 #20
I am getting this error but I don't understand what it actually means.
> From: info@civicrm.org
> Subject: Your extension release on civicrm.org
> Date: 19 November 2017 at 16:11
>
> This is a message from the automa...See also #12 #20
I am getting this error but I don't understand what it actually means.
> From: info@civicrm.org
> Subject: Your extension release on civicrm.org
> Date: 19 November 2017 at 16:11
>
> This is a message from the automated release system on civicrm.org. Congratulations on releasing version v1.0 of extension 'Environment Indicator Integration'.
>
> Unfortunately we have found a few errors while processing your release:
> - The Fully Qualified Name did not match parent extension: contrib.environmentindicator
>
> You will need to correct these errors before we can accept this release.
>
> Further help is available in the developer guide at https://docs.civicrm.org/dev/en/latest/extensions/publish/.
>
> You can also request help on Mattermost at https://chat.civicrm.org/civicrm/channels/extensions.
>
> If you no longer wish to publish this release, deleting the v1.0 tag from your extension's repository will stop these notices.
>
> Thank you so much for being an active contributor to CiviCRM and our community.
* Is it saying that the extension name ("Environment Indicator Integration") and the extension key (contrib.environmentindicator) do not match? (The docs say it's OK if the extension "basename" matched the file tag?)
* Is it reporting to me that it's detected the historic change of this extension key from contrib.environmentindicator to nz.co.fuzion.environmentindicator?
* Should it be reporting invalid info.xml in unpublished releases? (I published v1.2 of this ext in order to fix the mismatch in info.xml, why validate unsupported / unpublished releases?)
* Daily emails feels a bit on the heavy side!
I know this is a repeat of #12 but I can't tell what the actual invalidity is from that ticket, only that removing a git tag will somehow fix it. Hoping that by asking I can help document the solution for the next person ...https://lab.civicrm.org/extensions/extensions-directory/-/issues/20Automated release system email warning about older release2023-03-08T13:05:12ZxurizaemonAutomated release system email warning about older releaseI have this email from the automated release system:
> This is a message from the automated release system on civicrm.org. Congratulations on releasing version v1.1 of extension 'Environment Indicator Integration'.
>
> Unfortunately we...I have this email from the automated release system:
> This is a message from the automated release system on civicrm.org. Congratulations on releasing version v1.1 of extension 'Environment Indicator Integration'.
>
> Unfortunately we have found a few errors while processing your release:
> - The version numbers in the info.xml ("1.0") and in the git tag ("1.1") do not match.
>
> You will need to correct these errors before we can accept this release.
The current release of that extension is 1.2 at https://civicrm.org/extensions/environment-indicator-integration
Is there a way to prevent these notifications for releases other than the current release of an extension?
* Download URL: https://github.com/fuzionnz/nz.co.fuzion.environmentindicator/archive/v1.2.zip
* Version in release: 1.2
* Repo: https://github.com/fuzionnz/nz.co.fuzion.environmentindicator
* Uploaded info.xml: https://civicrm.org/sites/civicrm.org/files/extensions/info_315.xml
* CiviCRM extension node: https://civicrm.org/extensions/environment-indicator-integration
AFAICT there isn't a node on CiviCRM.org for v1.0 or v1.1https://lab.civicrm.org/extensions/extensions-directory/-/issues/19Condense Installation x 3 to a single header with more explanation2017-11-08T23:03:41ZMichael McAndrewCondense Installation x 3 to a single header with more explanationSee https://lab.civicrm.org/extensions/extensions-directory/issues/13
https://github.com/totten/civix/blob/master/src/CRM/CivixBundle/Resources/views/Code/readme.md.php has three different headers for installation instructions. A single...See https://lab.civicrm.org/extensions/extensions-directory/issues/13
https://github.com/totten/civix/blob/master/src/CRM/CivixBundle/Resources/views/Code/readme.md.php has three different headers for installation instructions. A single header with 'delete as appropriate' is probably more user friendly for both the extension author and consumer.https://lab.civicrm.org/extensions/extensions-directory/-/issues/18word change to heading USAGE2020-10-20T20:26:50ZAnneDruword change to heading USAGELooking at this boilerplate from a non-technical 'user' point of view, the term 'USAGE' is unfamiliar. I suggest we keep USAGE, but add /Getting Started.
eg . Usage/Getting started
etc
This is related to issue #13Looking at this boilerplate from a non-technical 'user' point of view, the term 'USAGE' is unfamiliar. I suggest we keep USAGE, but add /Getting Started.
eg . Usage/Getting started
etc
This is related to issue #13https://lab.civicrm.org/extensions/extensions-directory/-/issues/17Add link to further documentation2022-08-28T13:45:36ZMichael McAndrewAdd link to further documentationFollowing on from https://lab.civicrm.org/extensions/extensions-directory/issues/13, it would be good to add a header to the boiler plate along the lines of
```
### Documentation
(*FIXME: Where can one find full documentation for this...Following on from https://lab.civicrm.org/extensions/extensions-directory/issues/13, it would be good to add a header to the boiler plate along the lines of
```
### Documentation
(*FIXME: Where can one find full documentation for this extension? If all the
documentation that this extension requires is contained in this readme, feel
free to delete this heading.*}
```https://lab.civicrm.org/extensions/extensions-directory/-/issues/16Prepare specification of information that will assist users in deciding wheth...2022-08-28T13:47:44ZginkgofjgPrepare specification of information that will assist users in deciding whether to install an extensionPer @mattwire, some work to prepare such a document was done at the recent London sprint. I've reached out to the author (clairew) to request access. Ultimately, we'd like to use this user input to build a specification for the new in-ap...Per @mattwire, some work to prepare such a document was done at the recent London sprint. I've reached out to the author (clairew) to request access. Ultimately, we'd like to use this user input to build a specification for the new in-app extensions UI.ginkgofjgginkgofjghttps://lab.civicrm.org/extensions/extensions-directory/-/issues/15Expose "available for automated download" field to anonymous users on c.o2021-03-16T21:34:22ZAllenShawExpose "available for automated download" field to anonymous users on c.oGeneral consensus in EXT-WG is that this is valuable information for site admins, and that it should be easy to expose it to anonymous users.
TODO:
* Find out who can make this change on c.o
* Convince them to make the change.General consensus in EXT-WG is that this is valuable information for site admins, and that it should be easy to expose it to anonymous users.
TODO:
* Find out who can make this change on c.o
* Convince them to make the change.AllenShawAllenShawhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/13boilerplate for extension readme and documentation2022-08-28T13:37:50ZMichael McAndrewboilerplate for extension readme and documentation@mattwire is going to implement boilerplate for extension documentation. Anne Smale and Claire Williams have worked on some user oriented guidelines that can be used for writing this documentation (which they can add to this ticket).
I ...@mattwire is going to implement boilerplate for extension documentation. Anne Smale and Claire Williams have worked on some user oriented guidelines that can be used for writing this documentation (which they can add to this ticket).
I appreciate that this is the extensions directory project but I wasn't aware of a better place for it. I'd be happy to move if you let me know where.https://lab.civicrm.org/extensions/extensions-directory/-/issues/12Keep receiving extension release email error2018-03-29T14:31:04Zmattwiremjw@mjwconsult.co.ukKeep receiving extension release email errorFor an older release so no longer valid, should not keep receiving the following email:
```
This is a message from the automated release system on civicrm.org.
Congratulations on releasing version 1.0 of extension 'Smart Debit Direct
De...For an older release so no longer valid, should not keep receiving the following email:
```
This is a message from the automated release system on civicrm.org.
Congratulations on releasing version 1.0 of extension 'Smart Debit Direct
Debit'.
Unfortunately we have found a few errors while processing your release:
- The Fully Qualified Name did not match parent extension:
uk.co.vedaconsulting.smartdebit
You will need to correct these errors before we can accept this release.
Further help is available in the wiki at
http://wiki.civicrm.org/confluence/display/CRMDOC/Publish+an+Extension.
You can also request help in the Extensions community forum at
http://forum.civicrm.org/index.php/board,57.0.html.
Thank you so much for being an active contributor to CiviCRM and our
community.
```https://lab.civicrm.org/extensions/extensions-directory/-/issues/14Usage on civicrm.org extension pages is stale2020-03-11T16:12:59ZKarinGUsage on civicrm.org extension pages is stalestats.civicrm.org has iATS Extension at 478 - but https://civicrm.org/extensions/iats-payments was stuck at 219stats.civicrm.org has iATS Extension at 478 - but https://civicrm.org/extensions/iats-payments was stuck at 219https://lab.civicrm.org/extensions/extensions-directory/-/issues/11Resolve duplicate nodes for "Click and Pledge" extension2019-09-02T13:18:55ZSean ColsenResolve duplicate nodes for "Click and Pledge" extensionWe seem to have several nodes for the same extension:
* https://civicrm.org/extensions/click-pledge-payment-gateway
* https://civicrm.org/extensions/click-pledge-payment-processor-1
* https://civicrm.org/extensions/click-pledge-payment...We seem to have several nodes for the same extension:
* https://civicrm.org/extensions/click-pledge-payment-gateway
* https://civicrm.org/extensions/click-pledge-payment-processor-1
* https://civicrm.org/extensions/click-pledge-payment-processor-0
* https://civicrm.org/extensions/click-pledge-payment-processor
* https://civicrm.org/extensions/click-pledge-payment-gateway-1
* https://civicrm.org/extensions/click-pledge-payment-gateway-0
Kind of a mess.
It would be great to:
1. Merge these into one
1. Try to figure out how this happened and how we can avoid it from happening again.bgmbgmhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/10Provide extension developers with the ability to communicate with their users2019-07-19T19:52:54ZginkgofjgProvide extension developers with the ability to communicate with their usersThere are a number of reasons an extension developer may wish to communicate with her user base:
* To alert users about a security issue
* To make announcements re the project roadmap, etc.
* To ensure sufficient community engagement ...There are a number of reasons an extension developer may wish to communicate with her user base:
* To alert users about a security issue
* To make announcements re the project roadmap, etc.
* To ensure sufficient community engagement to sustain development/maintenance
* To offer related paid services (e.g., training on the ins and outs of CiviMobile)
End users benefit from all of the above as well, but participation, naturally, should be opt-in.
Each developer is free to implement her own system for engaging users, but to:
* Prevent duplication of effort
* Provide a consistent user experience across extensions
* Provide legitimacy
... I posit that CiviCRM should provide some of the infrastructure.
A few ideas on potential implementation:
* When a user opts in, an API call is made to CiviCRM.org. This API will create a contact record for the Domain Organization, if one does not already exist on CiviCRM.org. Said contact will be added to a group named for the extension.
* The Domain Organization may not have useful contact info. It may be necessary to specify a technical contact as well. We have also discussed ideas for specifying who from the organization should be opted into the group -- different staffers may have interest in different extensions -- needs fleshing out.
* Provided they are CiviCRM Partners, maintainers of the extension (as specified on the extension node) will be granted access to this group via an ACL. They won't have access to CiviMail or anything of the sort -- CiviCRM, LLC is just providing the list.
* We'll need to write a code of conduct about how the contacts may be used. It should be pretty common-sensical. We should not make CiviCRM, LLC responsible for managing opt-outs -- users opt out from the maintainer's list.
* The [new extension manager](https://github.com/twomice/org.civicrm.extensionsui) that Allen has been working on as an extension will house the user interfaces (and the corresponding logic to trigger the API call). At some point we'll need to discuss measuring its robustness and the path to shipping it with core. The default will be that an extension offers the relevant UI -- if a developer wishes to opt-out (e.g., because it's a one-off extension, or because the extension serves a particularly sensitive audience) we'll give them a hook or something.ginkgofjgginkgofjghttps://lab.civicrm.org/extensions/extensions-directory/-/issues/9Support extension dependencies2022-08-28T10:49:42Zmattwiremjw@mjwconsult.co.ukSupport extension dependenciesWe need to support dependencies for extensionsWe need to support dependencies for extensionshttps://lab.civicrm.org/extensions/extensions-directory/-/issues/8Support multiple authors for extensions2022-08-28T13:36:21Zmattwiremjw@mjwconsult.co.ukSupport multiple authors for extensionsSupport specifying multiple authors in the extension info.xml.
We can't add multiple author/email tags as (the core extension browser) parses those as a string and will display "Array (Array)" if you specify more than one.
So my proposa...Support specifying multiple authors in the extension info.xml.
We can't add multiple author/email tags as (the core extension browser) parses those as a string and will display "Array (Array)" if you specify more than one.
So my proposal is that we add authors/emails tags that UI components parse as a string/array in which you can specify additional authors:
```
<maintainer>
<author>Mr Ben</author>
<email>ben@example.org</email>
<authors>Bob</authors>
<emails>bob@example.org</emails>
<authors>Bert</authors>
<emails>bert@example.org</emails>
</maintainer>
```
See https://github.com/mattwire/civicrm-core/tree/extension_multiple_authors for a PR that makes this work in the core extensions browser.https://lab.civicrm.org/extensions/extensions-directory/-/issues/7Investigate point-release compatibility for extensions2021-03-16T21:37:19ZginkgofjgInvestigate point-release compatibility for extensionsWhat are the barriers to flagging an extension as compatible with 4.7.13+, for example?
Brain dump:
* Presently the notation in info.xml supports explicit version numbers, not patterns like you see elsewhere in composer.json, etc. (It ...What are the barriers to flagging an extension as compatible with 4.7.13+, for example?
Brain dump:
* Presently the notation in info.xml supports explicit version numbers, not patterns like you see elsewhere in composer.json, etc. (It would be really tedious as an extension maintainer to have to update info.xml for each point release if there are no other code changes.)
* There is presumably some service which tells CiviCRM instances out in the wild which versions of which extensions are compatible with their instance. This would need to be updated.
* We'll need to support the old way of doing things, of course. Can't go breaking the service for people who aren't on the bleeding edge.
* We may want to update the extdir module which fetches release metadata from GitHub, publishes extension releases, etc. to display human-readable version-compatibility strings.
Useful links:
* [extdir](https://github.com/civicrm/civicrm-org-platform/tree/master/sites/all/modules/custom/extdir) - module responsible for scraping GitHub and updating the extensions directory
* [mock extdir build](https://github.com/civicrm/civicrm-extdir-example) - buildkit build type which mocks (to some extent) the URL used to refresh the extension cache (e.g., https://civicrm.org/extdir/ver=4.7|cms=Drupal)AllenShawAllenShawhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/6Limit length of Extension Summary field and provide help text2017-07-06T17:39:21ZginkgofjgLimit length of Extension Summary field and provide help textThe `maxlength` Drupal module is installed and enabled. We had discussed setting a maxlength and providing help text to keep the summaries consistent in length and style. Here's some suggested text to guide users; feel free to adjust as ...The `maxlength` Drupal module is installed and enabled. We had discussed setting a maxlength and providing help text to keep the summaries consistent in length and style. Here's some suggested text to guide users; feel free to adjust as you like:
> This text will be used wherever your extension appears in a list. Your summary should begin with a verb, end with a period, and identify the functionality added (or the problem solved) by your extension. Here's an example: Allows the admin to create and manage discount codes that can be used on membership and event pages.AllenShawAllenShaw2017-07-06https://lab.civicrm.org/extensions/extensions-directory/-/issues/5Add links to "View Extension" page2020-11-26T13:14:05ZginkgofjgAdd links to "View Extension" pageFor example: https://civicrm.org/extensions/civivolunteer
* [x] Add link field for documentation (see how hard it would be to modify module [extdir](https://github.com/civicrm/civicrm-org-platform/tree/master/sites/all/modules/custom/ex...For example: https://civicrm.org/extensions/civivolunteer
* [x] Add link field for documentation (see how hard it would be to modify module [extdir](https://github.com/civicrm/civicrm-org-platform/tree/master/sites/all/modules/custom/extdir) to populate an extension node with the documentation field from the latest release node)
* [x] Make the Git URL clickable. This field is currently of type Text, which means we don't have easy options available for making it a link. One easy option is to create a new field of type Link. However, this means we'd have to migrate existing content to this field (probably not awful) and update the extdir module to populate the new field.
These items are grouped together because they both depend on learning more about how extdir works and possibly changing it.ginkgofjgginkgofjg2017-07-06