Closed (won't fix)
Project:
Recurring Events
Version:
8.x-1.x-dev
Component:
Recurring Events (Main module)
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
1 Apr 2020 at 09:54 UTC
Updated:
7 Apr 2020 at 19:55 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
technotim2010 commentedDoh, my bad, forgot about field inheritance, it works as designed.
Tim
Comment #3
technotim2010 commentedI just tested this on a clean site with the latest revisions of this module and field inheritance
What I am trying to achieve is the following:
Inherit one taxonomy field and three content entity reference fields into editable fields on the event instance.
Inherit the description field into a text area field on the event instance
Inherit the title into a new text field called Event Name.
Inherit is no use except for title.
append does not work with any of the fields
prepend does not work with any of the fields
fallback does not work with any of the fields
The only solution that seems to work is inherit, but this does not offer any way of editing the data in the event instance afterwards.
Interestingly I tried to create a series of views to see what was going on.
On a view based on the event instance entity type bundle default
append, prepend and fallback methods would allow me to show the id,
All 3 would allow me to show the fields being inherited to though all were empty
But would not allow me to show any of the inherited versions of the fields listed in views instead showing error
Error: Call to a member function getType() on null in Drupal\views\Plugin\views\field\EntityField->defineOptions() (line 382 of /var/www/punchprototype/web/core/modules/views/src/Plugin/views/field/EntityField.php)Inherited would not allow any of the inherited fields to be added but add a relationship to event series and you can at least list the original entries.
Not sure what this proves but shows up some issues.
Regards
Tim
Comment #4
owenbush commentedI'll take a look at this and see what info I can provide.
Comment #5
owenbush commentedThere may be a misunderstanding, or miscommunication, regarding what field inheritance does. The purpose of field inheritance is not to pull data into editable fields, but rather pull over data at display time. So, for example, you wish to display the address of the location of an event. The event has inheritance set up from the specific location and pulls down the address field whenever that event is displayed. Field inheritance does not pull the data into an editable field.
Having said that, you can 'override' or 'enhance' the value of the field by using 'append', 'prepend' or 'fallback'. But these strategies require another field on the event instance which is of the same type as the one from the source entity. So if it is a taxonomy field, you would need to set up a term reference field on the event. If it was an addressfield you would need to create an addressfield on the event.
Then you pick the strategy that suits your needs the best and you specify the source field on the source entity, the destination field on the destination entity, and then a computed field inheritance field is created which you can arrange on your manage display for the event. This computed field will show the data from the source and destination (if using append or prepend), and will show the data from the destination (if it is set) or the source (if using fallback).
So taking the example of 'Inherit the description field into a text area field on the event instance' what you would have is:
A description field on the source entity type
A description field on the event (presuming it is the destination entity type)
A field inheritance configuration to using the fallback strategy specifying the above fields
Then you can place that inherited field on the event manage display wherever you want and it will display the description field from the event instance (if set) otherwise it falls back to showing the description field from whatever the source is.
Comment #6
technotim2010 commentedHi Owen
That is what I did, I created new fields on the event instance for inheriting data from, where they were referencing other entities or taxonomies they were essentially the same field..
a
So if you use a prepend or append or fallback strategy and have a taxonomy field for taxonomy category field_a on your event series and an exact copy on the event instance field_b set for example the prepend to have a source of field_a and a destination of field_b, does that mean you still cannot edit field_b afterwards? Is this just impossible in Drupal or should it be a feature request.
As an example the event may have a decimal field called costs on the event_series, you create a series of event instances on each monday but some Mondays like Bank Holidays the costs of the event increase and you want to edit and increase that decimal field on one event instance.
Is this not possible?
Regards
Tim
Comment #7
owenbush commentedHi Tim
What your describing should definitely be possible. I'll take a moment to spin up a site and confirm things are working as expected and report back.
Comment #8
owenbush commentedOK I spun field_inheritance and recurring_events up on simplytest.me just now to test and got the example you provided working. Here is what I did:
- Add a field named 'Series Price' to the eventseries default type.
- Add a field named 'Instance Price' to the eventinstance default type.
- Added a field inheritance called 'Price' with the following settings (see screenshot)
- Label: Price
- Inheritance Strategy: Fallback
- Source Entity Type: eventseries
- Source Entity Bundle: default
- Source Field: field_series_price
- Destination Entity Type: eventinstance
- Destination Entity Bundle: default
- Destination Field: field_instance_price
- Modified the 'Manage Display' of the eventinstance default type to ensure that the 'Price' field is showing up (you can optionally remove the Instance Price field if you don't want to see that too. I kept it there to be sure things were working.
- I then created a series with a Series Price of 50.
- I then visited one of the instances and saw the 'Price' field displaying as 50.
- I then edited that instance and changed the 'Instance Price' field to 100.
- When I re-visisted that instance I now could see the 'Price' field set to 100 and I could see the 'Instance Price' field set to 100 (because I decided not to hide the instance price field). (See screenshot)
Comment #9
technotim2010 commentedHi Owen
I just tested this on a clean 8.8.4 site and indeed if you use fallback and change the data the fields reflect that,
That is not the issue, if a user is taken to the edit event instance form the fields that have been inherited don't show the values that have been inherited, This would be fundamentally confusing for the user.
Is it not possible to make the default value of a clean unedited event instance field, the value inherited from the event series. So show the cost field as £100 so at least the user knows what the current value is, otherwise it will be confusing for them as it looks like that field has no value.
Only if you change the value in a field does it show up on the edit form.
see screenshot
Comment #10
owenbush commentedOK, now I understand better and can see this would be helpful. However, this issue is more suited to the Field Inheritance module as all that functionality has been stripped out of the Recurring Events module and replaced with the Field Inheritance module.
Comment #11
technotim2010 commentedIts a bit difficult to raise it as an issue on field inheritance when I only have a specific use case for it.
In fact I am struggling to ascertain when you would use this on other entity types, I can see the concept in theory just not in practice.
Either way it really needs fixing to enable adoption of either this module and possibly in other scenarios, the field inheritance module.
Is there a way I can somehow change the field values to get the value of the inherited fields into the fields default value, perhaps using tokens or similar solution. (have not really looked at this yet.
It would help as a workaround if setting the default value from the inherited fields module is not viable.
Regards
Tim
Comment #12
owenbush commentedBecause this should be addressed by field_inheritance I am closing this issue out, I have made an issue over at #3125797: Display inherited field value in destination edit form to track this functionality.