Organization Management via filamentphp admin

[bogdankharchenko]

admin system

We need a mechanism to login, and manage the Orgs model.

We will use filamentphp

Orgs Model

• title (string)
• path (string)
• city (string)
• focus_area (string)
• uri (string)
• primary_contact_person (string)
• organization_type (string)
• event_calendar_uri (string)
• service (event service)
• service_api_key (nullable, string)
• status (enum)
• established_at (date time)

[allella]

Historically, I've been the main one editing these and perhaps a couple folks like Pam occasionally editing a detail.

I wouldn't be opposed to an interim solution of this being a JSON file that gets imported and cached if that saves a lot of work.

Zach did build and admin UI on the HG site, but I don't even recall what you can change or that I having a login for it.

[allella]

I'm alright slimming things down, but we would lose some ability with the list of fields above.

For instance, this view is built off of the regular day of the month and regular time of the day. There are so few competing orgs right now that I think the calendar view on HG is good enough to replace this feature. So, we can kill those fields off

The list does miss an alternative for _field_yearinactive, which has been handy for keeping a history of when groups started and ended. I think we should keep that field since it's a simple int. I've shared some spreadsheets that I was able to generate using that info, which was helpful last year in telling the story of the pre and post pandemic.

There's both a path and a uri listed above. The "path" in the old site is the internal URI. If the uri was intended to replace _fieldhomepage, then keeping homepage in the name may help differentiate it from any internal URI.

This isn't in the API, but a _urislug field is sometimes helpful for referencing the last portion of the internal URI.

I'm imaging _field_orgtags may be another table, but that has been a useful / important field, like for rendering OpenWorks' dashboard.

As you indicated, nid and uuid fields in the existing API may not be needed, but some primary key for an org is likely useful.

The _field_organizationtype key|values in the old API are

code-school|Code Schools
conference|Conferences / Festivals / Hackathons
meetup|Meetup Groups
workforce|Workforce Development

The _field_eventservice key|values in the old API are as below, but not all values are actually applied to an org

eventbrite|Eventbrite.com
facebook|Facebook.com
ical|iCal Feed
gettogether|GetTogether.community
meetup|Meetup.com
newsletter|Newsletter
open-collective|OpenCollective.com
unknown|Unknown

_field_organizationstatus key|values are

active|Active
inactive|Inactive
on-hiatus|On Hiatus
planned|Planned

I think that's all I have for now.

Thanks for moving things forward, again.

[bogdankharchenko]

We can certainly have a json file which holds all of the data for organizations, I think that may be a good solution to manage this data without having to manage the admin side. That being said it would probably be much fast building the admin UI than building a parser for the data.

@ThorntonMatthewD @JSn1nj4 what do you guys think?

[JSn1nj4]

I like the idea of building an admin UI in Filament. It handles admin UI and CRUD automatically out of the box, including obeying model policies by default.

That mostly leaves defining the shape of record displays and forms + validation rules.

[JSn1nj4]

@bogdankharchenko have you started this already? If not, I'd be down to at least get it started tonight and tomorrow.

@allella @ThorntonMatthewD if we drop either nid or uuid, what would be a good way to determine which is more heavily relied on? I was thinking of leaning towards keeping UUIDs, at least since the primary key in Filament will be used for accessing an individual record.

[allella]

@JSn1nj4 the nid (Drupal node id) and uuid are only there because Drupal adds it automatically and we may have used that as a primary key.

UUID are more of a universal concept, so we could keep with it, but I don't know that it's being relied upon by anything more than as a key to avoid duplicates on import. We could seemingly replace it with any unique primary key value.