TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692012-07-08T11:48:30ZTYPO3 Forge
Redmine TYPO3 Core - Bug #38749 (Closed): Wrong relation count after FAL update wizardhttp://forge.typo3.org/issues/387492012-07-08T11:48:30ZIngmar Schlechtingmar@typo3.org
<p>After executing the FAL upgrade wizards, the field "image" in tt_content should contain the relation count but instead contains an empty string.</p> TYPO3 Core - Feature #37251 (Closed): Use FAL file extension filter in TCAhttp://forge.typo3.org/issues/372512012-05-17T12:58:41ZIngmar Schlechtingmar@typo3.org
<p>Use FAL file extension filter in TCA</p> TYPO3 Core - Task #37250 (Closed): Remove non-working / not needed TCA configuration related to FALhttp://forge.typo3.org/issues/372502012-05-17T12:44:28ZIngmar Schlechtingmar@typo3.org
<p>Remove non-working / not needed TCA configuration related to FAL</p> TYPO3 Core - Feature #37249 (Closed): TCEForms: Rendering different element browser typehttp://forge.typo3.org/issues/372492012-05-17T12:39:31ZIngmar Schlechtingmar@typo3.org
<p>For relations to files (sys_file) in FAL, it should be possible to render an element browser of type "file" even though it is a database relation.</p>
<p>Therefore, a new property [appearance][elementBrowserType] should be introduced which can be set to either "file" or "db" to render that type of element browser regardless of the actual relation type.</p>
<p>Also, the "allowed" list for the element browser should be configurable as well.</p> TYPO3 Core - Bug #36875 (Closed): Small typos in comments in browse_links classhttp://forge.typo3.org/issues/368752012-05-06T07:13:15ZIngmar Schlechtingmar@typo3.org
<p>Small typos in comments in browse_links class</p> TYPO3 Core - Feature #36839 (Closed): Add getUid method to abstract record collectionhttp://forge.typo3.org/issues/368392012-05-04T12:35:02ZIngmar Schlechtingmar@typo3.org
<p>Add getUid method to abstract record collection</p> TYPO3 Core - Feature #36835 (Closed): Record collection repository is lacking a findAll methodhttp://forge.typo3.org/issues/368352012-05-04T11:48:59ZIngmar Schlechtingmar@typo3.org
<p>Record collection repository is lacking a findAll method</p> TYPO3 Core - Feature #36810 (Closed): Filtering "group" and "inline" field items in TCEMainhttp://forge.typo3.org/issues/368102012-05-03T14:25:44ZIngmar Schlechtingmar@typo3.org
<p>For some situations it would be great if it was possible to allow relations to only certain foreign records in a "group" type relationship.</p>
<p>In "select" fields that is possible via the "foreign_where_clause", but for "group" fields there is no such possibility.</p>
<p>This patch implements that functionality in a versatile way, which is also used by the FAL core parts, to ensure only relations to allowed file types (such as "images only") are ensured as configured in specific locations.</p> TYPO3 Core - Feature #33045 (Closed): Enable TCA type field to depend on field of foreign table b...http://forge.typo3.org/issues/330452012-01-08T14:45:02ZIngmar Schlechtingmar@typo3.org
<p>Sometimes it would be useful to make a TCA type switch not directly based on a value of the current record, but based on a value of another table.</p>
<p>This is e.g. useful for IRRE when used with an intermediate table (making a relation to a third table). Sometimes it's useful to make the fields dependent on the type field of the third table.</p>
<p>Say you have a relation between "houses" and "building objects" and an "intermediate table" for making the relation and storing some properties on how exactly the building objects are used in that particular house. Now, depending on the "building object" that the user makes a relation to, the intermediate table should show different fields.</p>
<p>The patch (as pushed to gerrit) implements this.</p> TYPO3 Core - Feature #33044 (Closed): Add possitbility to create hidden palettes in TCEFormshttp://forge.typo3.org/issues/330442012-01-08T14:17:47ZIngmar Schlechtingmar@typo3.org
<p>Hi guys,</p>
<p>sometimes it's useful to have fields rendered in TCEForms, but never display them anywhere.</p>
<p>One such occasion, where that is useful, is for the "foreign_field" feature of IRRE. As you might know, IRRE makes it possible to render something called a "foreign_selector" which lets the user choose from records of another (third) table (not the IRRE child table) to create relations to by using an intermediate table (the IRRE child table). However, there is one problem with it: IRRE requires the field of the intermediate table, which carries the link to the third table, to be always displayed in the form, even though it only carries technical information (the relation) which the user doesn't need to see at all. Of course, one could also change IRRE to not require the field to be present any more, but that would be technically much more challenging and more error prone.</p>
<p>Also, there might be other cases where it's useful to render a field but not display it anywhere, e.g. when you want to set a value of a (hidden) field by some JavaScript of a user-defined (other) field. Therefore, the feature to hide a field is rather universally useful.</p>
<p>Now: Why go the way of "hidden palettes" instead of "hidden fields" directly?</p>
There are two points speaking in favour of implementing the hide functionality per palette instead of per field:
<ul>
<li>It's more flexible: Fields can be hidden in one scenario and displayed in another scenario (depending on which palette they're rendered in)</li>
<li>it's easier to implement: For palettes, you can simply hide the link to the palette. For fields, it's hard to do, because fields always go into a strict template for which a new table row is created by TCEForms, so they remain visible.</li>
</ul> TYPO3 Core - Feature #29296 (Closed): Add possibility to define foreign_match_fields for IRRE inl...http://forge.typo3.org/issues/292962011-08-27T15:13:32ZIngmar Schlechtingmar@typo3.org
<p>This patch request adds the possibility to define foreign_match_fields (similar to MM_match_fields) for IRRE inline relations. This is required for the upcoming file abstraction layer in TYPO3.</p>
<p>New documentation:</p>
<p>For TYPO3 Core API, Chapter: ['columns'][fieldname]['config'] / TYPE: "inline"</p>
<p><a class="external" href="http://typo3.org/documentation/document-library/core-documentation/doc_core_api/4.3.0/view/4/2/#id2529282">http://typo3.org/documentation/document-library/core-documentation/doc_core_api/4.3.0/view/4/2/#id2529282</a></p>
<p>parameter name: foreign_match_fields<br />parameter type: array<br />parameter description: Array of field=>value pairs to both insert and match against when writing/reading IRRE relations. This feature is useful if you want to use the same child table in two inline fields within the same parent table. In that case you can then define an "identifier" field in the child record to distinguish the two relations.</p> TYPO3 Core - Bug #23731 (Closed): Felogin shouldn't show the permalogin form controls when permal...http://forge.typo3.org/issues/237312010-10-14T18:32:31ZIngmar Schlechtingmar@typo3.org
<p>The subject says it all:</p>
<p>Felogin shouldn't show the permalogin form controls when permalogin is set to "forced on" in intall tool.</p>
<p>(issue imported from #M15993)</p> TYPO3 Core - Bug #23730 (Closed): Incorrect default value of permaloginhttp://forge.typo3.org/issues/237302010-10-14T18:30:47ZIngmar Schlechtingmar@typo3.org
<p>The default value of permalogin (2) in config_default at the moment doesn't make sense and should be corrected.</p>
<p>0, which means "by default off, but can be enabled by a form control" is the best for most situations and should therefore be used as new default.</p>
<p>(issue imported from #M15992)</p> TYPO3 Core - Bug #25623 (Closed): Various small issueshttp://forge.typo3.org/issues/256232009-10-12T14:40:00ZIngmar Schlechtingmar@typo3.org
<p>Some language string mistakes / typos:</p>
<p>- two verbs in the following sentence: "The script to execute to run the Scheduler from the command line is"</p>
<p>- missing word "to" in "The webserver user is not allowed execute this script."</p>
<p>- the message is misleading in Windows and should be removed for Windows: "The webserver user is not allowed execute this script."</p>
<p>- wrong indentation in the file mod1/index.php in line 364 (starts with $dateFormat )</p>
<p>(issue imported from #M12211)</p> TYPO3 Core - Bug #25621 (Closed): Creation of late taskhttp://forge.typo3.org/issues/256212009-10-10T11:27:40ZIngmar Schlechtingmar@typo3.org
<p>I have a question (or maybe a feature request) regarding the creation of single (not recurring) tasks.</p>
<p>When I enter a date as "start date" that lies in the past, the BE module detects that and on-save changes the record to "disabled". So directly after saving the status of the newly created task is "Disabled, will not be executed, except manually".</p>
<p>Wouldn't it be nicer if it was instead "Late, will run with next execution"? I think people would expect that and also it would be a very convenient way to make tasks execute at the next occasion: Just set the date to something in the past, and it will appear as "Late".</p>
<p>(issue imported from #M12177)</p>