Hi,

Unfortunately currently there is no way to move category due to data restriction, for example, if category A has some fields that category B doesn't have, then it might result in data mismatch. We will see how we can remedy this in the future.

Regarding the category description, I will add this in 1.3.4

Hi Jason. Understood.... and thanks for squeezing the display of the category description into 1.3.4... that should stop my people making mistakes!

So I'll just have to be careful to set up the correct categories in the first place! Maybe in some future version, moving will be possible subject to losing data (I think that's what happens when you move a user from one profile type to another)

Thanks... and if you haven't heard it enough, ES EVENTS is AMAZING

@Andy,

Yup indeed that is what happens with Profile and it was a "test" that we include for profile to see how it goes. By its core, group category and event category works similarly with Profile so it is possible to port this feature over, but we will have to see how it goes for now.

And thanks for your kind words!

Hi Andy,

I totally agree: EasySocial is amazing and your work is amazing.
But with all this great features, it feels like it is slightly "too good". If the great feature of custom fields by category leads into a loss of flexibility, this is not really a progress for me.

Most custom fields, for Events as well as for Profiles, will have a meaning for me in all categorys/profile-types. And switching category/profile-type is essential in my opinion.

Just a thought:
Imagine, the custom fields would be handeled globally and then can be turned on and of for an event-category/profile-type. That would mean, the data is saved in EVERY category/profile-type, but simply not shown if the custom field is not turned on for the category/profile-type. This could keep your flexibility in creating custom fields for only one category and add the prossibility to keep the data when switching and also make it easier to create custom fields that should be valid globally.

Well, I am not a coder and I think, my Idea might not be possible to create it in the structure you have. But otherwise ... please keep in mind some points:

- Switching profile-types/event-categories is ESSENTIAL
- Lots of custom fields will be used in more then one category/profile-type and it´s much easier to create a global one then to create a single one for every category/profile-type

Please take care that the developement of custom fields is not getting into a stuck state, where it will be impossible anymore to handele them general. I extremly appreciate the great flexibility that you put in the system by the custom fields, but don´t loose the "Easy going" for tasks that don´t need so much flexibility.

All the best, Julian!

Julian - Very good points you make here... and a good possible solution too. Thanks. Hopefully it'll be possible when our Developer Heroes take a look and consider this...

Hi,

Switching profile is already possible, switching category will be in the upcoming future releases.

Hi everybody,

I also wrote something about this topic here:
http://stackideas.com/forums/custom-fields-in-different-profile-types

All the best, Julian!

After migrationg all events from JomSocial, I need to adjust the categorys. It makes no sense to me to have all Events in the same category.
Is there a way to change categorys by changing data in the sql-table for this purpose?

All the best, Julian!

Hi,

Sorry bout the previous reply.

We will add this directly in the next version where you can have an interface to switch category. (This is ported over from the Switch Profile logic).

Take note though, both categories must have SIMILAR FIELDS with SIMILAR unique_key as data is being transferred through unique_key matching.

Hi Jason,

Sorry bout the previous reply. We will add this directly in the next version where you can have an interface to switch category. (This is ported over from the Switch Profile logic).

I don´t know what you mean, I am a little confused.
There was an answer how to change the category by database-manipulation.
That´s what I did now, and the events show up in the different category as desired.

Is there expected any problem when doing so?

Take note though, both categories must have SIMILAR FIELDS with SIMILAR unique_key as data is being transferred through unique_key matching.

This was the reason for me to write that much in the other thread.
-> http://stackideas.com/forums/custom-fields-in-different-profile-types

I think it will be a very unsatisfying workflow if all fields have to created for every single category.
This workflow would for example mean: If you have a typo in the newly created custom field of the second category, by moving all events you will loose all data that is saved in custom fields...

All the best, Julian!

Hi,

If you were to follow Mark's reply by directly changing the category ID through database, that works but field data won't be preserved.

In the upcoming version, data will be preserved if you change category (provided that both category has similar fields and unique_key).

To further elaborate, there are mandatory fields and optional fields for categories.

Mandatory fields (provided that you didn't change the unique_key and stick with the system default), when you change an event's category, the data will be preserved.

For Optional fields however, if there is TEXTBOX in category 1 and TEXTBOX in category 2 (Regardless of what the data type and data content is), then the data will be preserved.

What about a button to "copy custom fields"?
This way, a data-loss because of a typo could be prevented.
Also it would be easier to create simular custom fields if neccecary in different profile-types/categorys.

Thanks as always! Awesome support.

@Julian, if you were to "create a new category", a standard set of custom field is created (which uses similar unique_key).

If you were to add a new field, a standard format of unique_key is used as well (since most users does not mess with unique_key anyway).

Hi Jason,

after playing around the whole night I still have the feeling:
It drives into a "messy" style if custom fields are attached to categorys and vary from category to category.

Maybe I found some better words to describe the solution I have in mind:
If a custom field is valid for EVERY category, but in a hidden state, it would sort out a lot of things.
It would make it possible to keep the data saved when switching a category. In that case, the data would be hidden ... but not lost.

And if I like to use the custom field in another category, I can "activate" the present one for this category instead of creating a new one.

Sorry about posting this again, but I couldn´t get this thoughts out of my mind the whole night.
It could be very easy, to have custom-fields that are hidden in some categorys, but still valid sitewide.
It looks very messy to me, if sitewide custom fields need to get created every category and then somehow aligned/connected with the same custom-field in another category. Imagine the amount of work if you simply want to change an option in one of the custom fields ...

All the best, Julian!

Hi,

Unfortunately this cannot be implemented, at least not on 1.3.

Fields are connected through "UNIQUE_KEY", and as of now, unique_key is the only link that needs to be considered in order to ensure that there are no data loss.

Fields are connected through "UNIQUE_KEY", and as of now, unique_key is the only link that needs to be considered in order to ensure that there are no data loss.

I already tried this in the recent version, but it didn´t work.
But if it works, it will still need the process of creating a custom field for every single category.

One more example:
I create seminars sorted by categorys:
Financial, Emotional, Career, Communication, Health,...

How I like to create a custom-field to make a difference between "beginners" and "advanced"-seminars.
This is a custom-field that is valid for ALL seminars, but I have to create it for every single category. Even with I create a new category next year, I have to keep in mind that I have to create the category with the same Key as it was built before.

This is a huge workflow for a simple task.
I just wanted you to keep this in mind.

in order to ensure that there are no data loss.

What, if the Unique_key is similar, but the field-type is different?
When I try to match a text-field with a radio-button?

I guess, there will be a lot of potential problems inside this solution.

All the best, Julian!

Hi,

Unfortunately for now, we are going along with this structure and it takes a major overhaul to change how it works currently, and we will see what we can do in the future release.