extensions-directory issueshttps://lab.civicrm.org/extensions/extensions-directory/-/issues2020-04-22T17:24:53Zhttps://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/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/38Extensions directory v2019.102019-07-24T13:15:05ZtottenExtensions directory v2019.10The main `civicrm.org` website currently runs Drupal 7. There's an on-going process to [upgrade it](https://lab.civicrm.org/marketing/civicrm-website/wikis/2019-cms-upgrade) around the time of the Barcelona community summit (Oct 2019). (...The main `civicrm.org` website currently runs Drupal 7. There's an on-going process to [upgrade it](https://lab.civicrm.org/marketing/civicrm-website/wikis/2019-cms-upgrade) around the time of the Barcelona community summit (Oct 2019). (~~I believe that the new platform is D8, although I'm not certain that's final yet.~~ *The linked wiki lists evaluations of possible migrations. At time of writing, I only see a full entry for D8.*)
The extension directory was originally built as a set of D7 modules, content-types, views. Migrating to D8 (or WP) is a significant undertaking and an opportunity to reconsider these workflows. This means we're running down a clock and need to reassess/reimplement/port/etc.
The current functionality of the directory includes:
1. A public web-page for browsing/filtering extensions and their releases
2. A backend web-page for submitting extensions and releases
3. Workflow tools for extension [reviewers](https://docs.civicrm.org/dev/en/latest/extensions/lifecycle/#formal-review)
4. A backend job for scanning each extensions' git repo for new releases
5. A web-service/feed used by CiviCRM sites to list available/compatible extensions
Concurrently, at the recent sprints, we discussed https://lab.civicrm.org/infra/comex/ - which is working POC micro-service. It provides (4) backend scanner and (5) web-service/feed (independent of the `civicrm.org` CMS). It adds some significant functionality (i.e. composer bridge; also, automatic handling of silly `info.xml` fields like `<releaseDate>` and `<stability>`). However, currently, it only works with extensions published via Git (*any public git repo is OK*), and does not provide (1) public web-page for browsing extensions, (2) backend web-page for submitting extensions, or (3) workflow tools for reviewers.
I've filed this issue specifically because items (1), (2), and (3) need some planning/attention.
------
# List of general approaches
*This part of the ticket should try to keep an index of general approaches*.
* (P1) __Forward Port__: Migrate everything (1,2,3,4,5) as full stack into whatever `c.o` uses next.
* (P2) __Two Tier:__ For all UIs (1,2,3), use `c.o` CMS tooling. For backend (4,5), use micro-service.
* (P3) __Gitlab JSON__: For managing the canonical extension list (2,3), use Github/Gitlab PRs. For public browsing (1), use CMS tooling (Feeds+Views?). For backend stuff (4,5), use micro-service.
* (P4) __Backdrop "Project"__: Use Backdrop "Project `___`" modules for (1,2,3). Create submodules or alterations for (4,5).https://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/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/34Request review for com.aghstrategies.tsys2019-07-15T20:07:44ZalicefruminRequest review for com.aghstrategies.tsysGithub Link: https://github.com/aghstrategies/com.aghstrategies.tsys
Extensions Page on CiviCRM.org: https://civicrm.org/extensions/tsys
Documentation: https://docs.civicrm.org/tsys/en/latest/
Best Contact: alice@aghstrategies.com Github Link: https://github.com/aghstrategies/com.aghstrategies.tsys
Extensions Page on CiviCRM.org: https://civicrm.org/extensions/tsys
Documentation: https://docs.civicrm.org/tsys/en/latest/
Best Contact: alice@aghstrategies.com https://lab.civicrm.org/extensions/extensions-directory/-/issues/27Please list the eWAY Recurring Payment Processor by Agileware in the CiviCRM'...2019-06-25T19:16:17Zjustinfreeman (Agileware)Please list the eWAY Recurring Payment Processor by Agileware in the CiviCRM's internal Extensions DirectoryPlease list the eWAY Recurring Payment Processor by Agileware in the CiviCRM's internal Extensions Directory.
https://civicrm.org/extensions/eway-recurring-payment-processor-agileware
I posted this request in the old Jira over 12 month...Please list the eWAY Recurring Payment Processor by Agileware in the CiviCRM's internal Extensions Directory.
https://civicrm.org/extensions/eway-recurring-payment-processor-agileware
I posted this request in the old Jira over 12 months ago too, https://issues.civicrm.org/jira/browse/EXT-57
Have been trying to get this actioned for 4 years now...https://lab.civicrm.org/extensions/extensions-directory/-/issues/28Request review for "uk.artfulrobot.civicrm.gocardless"2019-06-25T19:15:57ZRichRequest review for "uk.artfulrobot.civicrm.gocardless"On the <https://docs.civicrm.org/dev/en/latest/extensions/publish/> page it tells you to:
> One of the extension's maintainers must [request an extension review](https://issues.civicrm.org/jira/secure/CreateIssue!default.jspa?selectedPr...On the <https://docs.civicrm.org/dev/en/latest/extensions/publish/> page it tells you to:
> One of the extension's maintainers must [request an extension review](https://issues.civicrm.org/jira/secure/CreateIssue!default.jspa?selectedProjectId=10400&issuetype=10000).
But following that link (after having logged in a jira) gives:
> Proxy Error
>
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request GET /jira/secure/CreateIssue!default.jspa.
>
> Reason: Error reading from remote server
I'm trying to request a review of <https://civicrm.org/extensions/gocardless-direct-debit-payment-processor-for-civicrm>https://lab.civicrm.org/extensions/extensions-directory/-/issues/35Request review for org.wikimedia.thethe2019-06-25T19:15:30ZeileenRequest review for org.wikimedia.thetheAllenShawAllenShawhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/36Request review for com.physicianhealth.sms.ringcentral2019-06-25T19:12:56ZDaveDRequest review for com.physicianhealth.sms.ringcentralhttps://civicrm.org/extensions/sms-provider-for-ringcentral-telus
~"Extension Review Request"https://civicrm.org/extensions/sms-provider-for-ringcentral-telus
~"Extension Review Request"https://lab.civicrm.org/extensions/extensions-directory/-/issues/37TEST, IGNORE Request review for [FIXME_COM.FIXME_VENDOR.FIXME_NAME]2019-06-14T19:02:05ZAllenShawTestReviewerTEST, IGNORE Request review for [FIXME_COM.FIXME_VENDOR.FIXME_NAME]TESTTESThttps://lab.civicrm.org/extensions/extensions-directory/-/issues/33test, ignore2019-05-31T16:02:44ZAllenShawtest, ignorehttps://lab.civicrm.org/extensions/extensions-directory/-/issues/32test, ignore2019-05-31T15:51:22ZAllenShawtest, ignorehttps://lab.civicrm.org/extensions/extensions-directory/-/issues/31test, ignore2019-05-31T15:50:50ZAllenShawtest, ignorehttps://lab.civicrm.org/extensions/extensions-directory/-/issues/30ignore, test issue2019-05-31T15:50:39ZAllenShawignore, test issue/label fdsa/label fdsahttps://lab.civicrm.org/extensions/extensions-directory/-/issues/26Extension auto-release recently started sending a lot of emails for mismatchi...2018-06-19T14:10:25ZbgmExtension auto-release recently started sending a lot of emails for mismatching tagsSince ~ 2018-06-05, the extdir nightly job for extension auto-release has started sending out a lot of emails about mismatching tags.
Example from `cividiscount`:
```
Unfortunately we have found a few errors while processing your relea...Since ~ 2018-06-05, the extdir nightly job for extension auto-release has started sending out a lot of emails about mismatching tags.
Example from `cividiscount`:
```
Unfortunately we have found a few errors while processing your release:
- The version numbers in the info.xml ("2.0") and in the git tag ("v2.0")
do not match.
```
ref: https://chat.civicrm.org/civicrm/pl/kxr4xdmh37bafqwk6yekhs5xhobgmbgmhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/25Extension auto-release does not populate the 'zip' field for extensions on la...2018-05-28T13:55:42ZbgmExtension auto-release does not populate the 'zip' field for extensions on lab.civicrm.orgc.f. https://chat.civicrm.org/civicrm/pl/rcox8zncrffzjdaiqk6pjrwera
cc @jaapjansmac.f. https://chat.civicrm.org/civicrm/pl/rcox8zncrffzjdaiqk6pjrwera
cc @jaapjansmahttps://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/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.
```