Extend service provider

[mikejmets]

This PR (#206) creates a new content type ServiceProvider. The plone.org site already makes use of collective.casestudy which has a Provider content type. Instead of creating the ServiceProvider type here or adding the additionally requested fields in this PR to Provider, we could create a behavior in collective.casestudy called provider_extras that extends Provider with the following fields:
logo: use Preview Image
sponsorship_type
rating
languages
country: exists
services
portfolio
certificates
body: use Blocks on the page
customer_retention
industries
contact_role
email2
phone2
contact_form_url
linkedin
instagram
youtube
facebook
twitter
photo1
photo2
photo3
photo4
photo5
start_date
end_date
payment_date
last_verified_date
notes (title=Private Notes)
public_notes

Are all these fields necessary and/or desirable?

[astridjuizi]

Thanks Mike. As discussed this morning, yes, let's use preview for logo (ssot) if that reduces the risk of having outdated logos.

Thanks Vitaliy for including all the headings from the spreadsheet that we've been working on.

Mike, you asked if we need all these field. These are my thoughts:

Can leave out, unless it is hard to add/amend them later,:
rating
certificates

Add:
mastodon
bluesky

change:
twitter should be x

Not sure about:
customer_retention - might be better to use "years in business"

[stevepiercy]

I'd suggest to put the schema into a Google Sheet to make it easier to communicate each field's input type, validation rules including required or what are valid options, whether it's new or existing from collective.casestudy, and its purpose.

For example, payment_date should be:

last_payment_date, date, optional, new, Indicates the most recent date that the Plone Foundation received payment for a Provider listing.

Thanks for moving this forward!

[ericof]

@astridjuizi, @mikejmets: First of all, I'm not part of the Marketing team and I'm not aware of all your needs, but I would like to mention I see many fields in the list that could be used from plonegovbr.socialmedia, and other fields that should not be fields at all (photo{1,4}) as the provider content type is already a folderish that supports images.

Additionally my two cents would be:

• Focus on the migration to the latest Plone, Volto and Volto Light Theme because adding any feature now seems to be a big overhead
• Plone.org specific fields be added to a behavior on the plone.org codebase (rating, sponsorship_type, start_date, end_date, payment_date, last_verified_date, notes)

[erral]

@mikejmets I have checked the fields that collective.casestudy provides and we have almost all of them.

We can use blocks for all the text-based fields.

Regarding the payment date and co. do we really need them? I thought that we were removing the payment requirements for provider listings. If so, we can just go ahead with the content migration from the current content (Sponsors) to the new (Providers).

[stevepiercy]

Regarding the payment date and co. do we really need them? I thought that we were removing the payment requirements for provider listings. If so, we can just go ahead with the content migration from the current content (Sponsors) to the new (Providers).

I'd oppose payment date here. It adds work to someone (1-2-3 not it!), and it's not realistic to expect the Treasurer to maintain this here when it's already tracked in Quickbooks.

If anything, it should be a listing_expires_date, which would shut off the Provider listing after that date as well as send an email notification to interested parties. It would be up to whoever maintains Providers to keep that value current. This date could be for any reason, whether it's for a payment or making in person contact to ensure that the Provider still provides Plone services.

[erral]

If anything, it should be a listing_expires_date, which would shut off the Provider listing after that date as well as send an email notification to interested parties. It would be up to whoever maintains Providers to keep that value current. This date could be for any reason, whether it's for a payment or making in person contact to ensure that the Provider still provides Plone services.

We can handle that with effective and expires dates, we already have that included in Plone, no need to have extra fields!

[vipod]

This PR (#206) creates a new content type ServiceProvider. The plone.org site already makes use of collective.casestudy which has a Provider content type. Instead of creating the ServiceProvider type here or adding the additionally requested fields in this PR to Provider, we could create a behavior in collective.casestudy called provider_extras that extends Provider with the following fields: logo: use Preview Image sponsorship_type rating languages country: exists services portfolio certificates body: use Blocks on the page customer_retention industries contact_role email2 phone2 contact_form_url linkedin instagram youtube facebook twitter photo1 photo2 photo3 photo4 photo5 start_date end_date payment_date last_verified_date notes (title=Private Notes) public_notes

Are all these fields necessary and/or desirable?

I wasn't aware of casestudy addon at the time of merge request. Yes, it'll be better to extend existing Provider content type with those extra fields. Yes, we need most of them.

[vipod]

@astridjuizi, @mikejmets: First of all, I'm not part of the Marketing team and I'm not aware of all your needs, but I would like to mention I see many fields in the list that could be used from plonegovbr.socialmedia, and other fields that should not be fields at all (photo{1,4}) as the provider content type is already a folderish that supports images.

Additionally my two cents would be:

• Focus on the migration to the latest Plone, Volto and Volto Light Theme because adding any feature now seems to be a big overhead
• Plone.org specific fields be added to a behavior on the plone.org codebase (rating, sponsorship_type, start_date, end_date, payment_date, last_verified_date, notes)

Good idea. Probably no need for Photox fields. Only main header image would be good to have. We'll use in at the top of a Provider details page.

[vipod]

@astridjuizi, @mikejmets: First of all, I'm not part of the Marketing team and I'm not aware of all your needs, but I would like to mention I see many fields in the list that could be used from plonegovbr.socialmedia, and other fields that should not be fields at all (photo{1,4}) as the provider content type is already a folderish that supports images.

Additionally my two cents would be:

• Focus on the migration to the latest Plone, Volto and Volto Light Theme because adding any feature now seems to be a big overhead

I'd also like this way. But based on current admin team business I don't think it'll happen any soon. Let's not push back our marketing efforts because of technical issues...

• Plone.org specific fields be added to a behavior on the plone.org codebase (rating, sponsorship_type, start_date, end_date, payment_date, last_verified_date, notes)

Whatever works easier for devevelopers to support it.

[vipod]

Regarding the payment date and co. do we really need them? I thought that we were removing the payment requirements for provider listings. If so, we can just go ahead with the content migration from the current content (Sponsors) to the new (Providers).

I'd oppose payment date here. It adds work to someone (1-2-3 not it!), and it's not realistic to expect the Treasurer to maintain this here when it's already tracked in Quickbooks.

If anything, it should be a listing_expires_date, which would shut off the Provider listing after that date as well as send an email notification to interested parties. It would be up to whoever maintains Providers to keep that value current. This date could be for any reason, whether it's for a payment or making in person contact to ensure that the Provider still provides Plone services.

Yes, makes sense.

[mikejmets]

@mikejmets I have checked the fields that collective.casestudy provides and we have almost all of them.

We can use blocks for all the text-based fields.

Regarding the payment date and co. do we really need them? I thought that we were removing the payment requirements for provider listings. If so, we can just go ahead with the content migration from the current content (Sponsors) to the new (Providers).

Hi @erral, I'm not sure what you mean. I see that FoundationSponsor has a lot of the fields that @astridjuizi and @vipod are requesting, are you saying we can simply rename the FoundationSponsor type to Provider? Or does a new type Provider already exist?

[erral]

No, I am saying that we neither need a new content-type and nor a behavior, the collective.casestudy product already provides a "Provider" content-type with all those fields.