[Webcom] Service Provider Fix/Upgrade

Adam Włodarkiewicz adam.wlodarkiewicz+osgeo at gmail.com
Thu Aug 1 04:49:57 PDT 2013


Hi,

> As far as I can see, your suggestion doesn't allow an institution to log in
> and edit their own profile - instead someone with the correct role can edit
> all 'service provider' nodes?

I suggest to keep the service provider profile and user profile
separate. A user would be able to edit a service provider profile if
they are its author. Alternatively, we could somehow link the user
profile with service provider profile. There's lots of flexibility
here, but a simple solution, upon which we could expand later, would
be to have content type 'service provider profile' and keep regular
users.

> Is your plan for migrating the exiting profile information to cut and
> paste?  We'd then remove the old pages and allow external search engines to
> reindex?

I think it should be easy to export the information in a machine
friendly format and then import them as Drupal content. I'm not sure
there's anything to reindex on search engines.

> The new guidelines would be to contact WebCom to get pages added or updated?

Thanks for bringing this up. There's lots of flexibility here too. I'd
suggest that every user should be able to create and edit their own
service provider profile(s).

I don't see any reason to keep custom legacy code, when you can use
core or almost core Drupal features. Moving the service provider
profiles to Drupal content would have many advantages, among them
gaining access to a nice UI and being able to use the many other
modules, which could further enhance the functionality.

Best Regards,
Adam Włodarkiewicz

>
> """
>
>
>
> On Tue, Jul 30, 2013 at 11:37 AM, Frank Warmerdam <warmerdam at pobox.com> wrote:
>>
>> Folks,
>>
>> I'm opening a new thread to discuss Adam Włodarkiewicz's suggested plan to fix the Service Provider Directory which is currently broken due to the mysterious loss of a page of PHP code, described in:
>>
>>   http://trac.osgeo.org/osgeo/ticket/1105
>>
>> Adam has suggested:
>> """
>> I propose introducing a 'service provider' content type. This would give it
>> the advantage of customizable permissions and easy integration with views
>> among other Drupal goodness. Permissions can be configured to give editing
>> rights not just to osgeo.org maintainers, but any user with the correct
>> role (again, configurable in Drupal). Such role can be given to users who
>> are representatives of the service providers. Views module allows creation
>> of different kinds of lists and displays of content. A list containing only
>> the service provider content type would be trivial to create, much like
>> creating filters to limit the list to only service provider from a given
>> country, etc. Further more, this filter can be exposed to the user (for
>> example as a select box) and ajax can be used to refresh the list. As far
>> as I understand, this pretty much covers the current functionality and
>> more, in addition to being drupalish. All of the above mentioned
>> configuration can be done via clicking in the administration menu.
>>
>> Importing existing entries can be easily done via a proper import module,
>> assuming it would not be too difficult to export the current data in, for
>> example, csv format.
>> """
>>
>> I'm slightly concerned that the filtering may be more clumsy than the
>> service provider directory.  Adam, can you point me at something similar
>> done with Drupal so I have a sense of what it might look like and interact
>> like?
>>
>> I will note that the existing service provider directory is in a mysql table
>> - the same one as the drupal content.
>>
>> Ian has also expressed interest in helping with this issue - Ian, do you
>> have thoughts on this approach?
>>
>> Personally, it sounds pretty good to me.  I'm wondering if it is something
>> we could start prototyping on Drupal now and just not link to it from
>> anywhere prominent on the web site.  If there are no immediate concerns
>> I would be interesting in starting an experiment on this new content type
>> and filtering interaction and could arrange appropriate access for Adam.
>> Perhaps a motion covering the experiment would be appropriate to
>> gauge support.  I'd also include adding Adam to Webcom.
>>
>> Best regards,
>> --
>> ---------------------------------------+--------------------------------------
>> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>> light and sound - activate the windows | http://pobox.com/~warmerdam
>> and watch the world go round - Rush    | Geospatial Software Developer
>
>
>
>
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Software Developer


More information about the Webcom mailing list