Federico

Members
  • Content count

    39
  • Joined

  • Last visited

Community Reputation

6 Neutral

About Federico

  • Rank
    Jr. Member
  1. Awesome, I didn't try this ajax conditional and the call made twice was the cause. I've changed only this to the above, to wrap all into one sigle $out $out .= $pl->execute(); // .= instead of simply = thank you very much
  2. this depends on the number of users inputing working hours per day, as they could be like 100 every days, resulting in a potential scenario like 100(users)x24(max hours) = 2400 repeaters items every day (so a single page could potentially hosts like 2400 repeaters). Does this sound doable? I've tried it, very powerful, but first I have to find the most appropriate logic to store working hours. I'll definitely give it a another try with the above logic, if no better solution will arise
  3. Thank you for the inputs Francis My situation is very similar to what you have narrowed down, though my major doubt is still how to store such ever increasing amount of data in database. In particular, I am thinking to store user working hours as follow: under page "timesheet", the custom module will generates children pages corresponding to each inputed days (even if only one single user will input a working hour for certain day, the module will generates a children page named with the current date) - so after one working week I will expect to get a structure similar to this: Home - Projects -- Project 01 -- Project 02 .... - Timesheet (all children pages contain repeaters to store user working hours) -- ts-2017-12-02 -- ts-2017-12-03 -- ts-2017-12-04 -- ts-2017-12-05 -- ts-2017-12-06 - Admin -- Users --- user 01 --- user 02 .... Each timesheet children page contains a repeater to include every working hours for each users. Doing so I will limit the usage of repeaters within the same page, as this is the only parameters I can assume will stay under reasonable number (it depends only on how many users will be inputing working hours, but they can normally need just 1 repeater/user) Do you think this is a valid approach? (referring to the Timesheet children pages corresponding to each working days, where each children pages have repeater inside them to store the user working hours) Alternative to this approach? much appreciated
  4. Hi there, I would love to hear your opinion regarding the possibility to store and manage users timesheets in relation to some projects, all within PW system. In essence, I need to find a working solution to let some users under this page tree: - Admin -> Access -> Users to fill a timesheet (under custom admin module), for every working day. The info I need to store in database is composed as follow: 1 - the user selects the day by picking it from a daytime inputfield -> Date 2 - then the user select an existing page located elsewhere in the system (called projects) -> Project name 3 - user adds number of working hours dedicated to that project, repeating the whole set if within the same day the projects where more than one -> Nr. of hours Each PW users should be able to see only their inserted values (all days stacked in a table manner), not what other users placed from their own. So depending on user login, one might see different rows in the timesheet table. I am thinking a sort of repeater list with sort of user permissions - all within the custom module form - but since repeaters are not suitable for unknown large dataset, I am still looking for better paths. What do you suggest about storing such potential infinite scalable data? Thank you very much fm
  5. Can you please suggest how to disable the AddNew page button in this case? like this? $pl->addNew = false; // ??? just an assumption, as this doesn't exists in lister options
  6. Hello everyone, I am using a custom module with lister, which works just fine. The only thing that troubles me is how to display only one button at the top, instead of many duplicates that the lister module generates. here couple of snapshots to show it This is the button (green one on top right) on the header, which is the expected position. So the header looks perfect, whereas in the footer the module generates automatically two additional buttons (not wanted) the code to generates the lister and the button is all in ___execute() function. Here's the code $btnAddNew = $this->modules->get("InputfieldButton"); $btnAddNew->showInHeader(); $btnAddNew->href = "{$this->wire('config')->urls->admin}page/add/?parent_id=1101"; $btnAddNew->icon = 'plus-circle'; $btnAddNew->value = "Create new project code"; $btnAddNew->aclass = "classeAnchor"; $btnAddNew->addClass = "pw-modal"; $btnAddNew->id = "Test"; $pl = $this->modules->get("ProcessPageLister"); return $pl->execute() . $btnAddNew->render(); I've also tried this lister option: $pl->toggles = array('collapseFilters', 'noButtons'); // setting the deafult filter as collapsed, and no additional buttons but no luck for me. Then also I'm experiencing problem with the modal window for the button, as when I click the button the modal appear and abruptly redirects to add page section of PW, outside of the modal. But this is just a different issue.. Any help would be much appreciated
  7. Hi all, what is the best way to get a custom field value, currently viewing in a single user page (admin side) and within the ready.php? I tried the following, without success $fieldValue = $page->customFieldName; // tentative 01 - fails $fieldValue = $this->customFieldName; // tentative 02 - fails $fieldValue = $this->page->customFieldName; // tentative 03 - fails note that the custom field is a simple text field I need it to auto populate another custom field that follows the one above thanks!
  8. works like charm! thanks!
  9. Hi all, I am having trouble on setting a fieldtype visibility from API, I need to set it as locked on a page save. here is the code from the module, which is called on init() $this->addHookBefore("Inputfield::render", $this, "renderFieldFolder"); Now, everything's ok except the locked feature, I can collapse or open the field from API but no way to lock it public function renderFieldFolder(HookEvent $event) { $field = $event->object; if($field->name == 'proj_code_folder') { $field->collapsed = Inputfield::collapsedNoLocked; } } Any clue?
  10. @Robin S after additional tests, I've found that the "007" release works as expected for fieldset visibility only outside individual templates (fields visibility overwrite). correct?
  11. your math is correct @adrian a simple text field type does the job. Thank you all
  12. Thanks @Robin S, awesome support! For whatever reason, my fieldset did not changed its behaviour from 0.0.6 to 0.0.7, I still cannot control it via custom selectors after page save. I reverted back to the combo presentation "closed" and checkbox fieldtype "yourcheckboxfieldtypeName" as "not checked", as this is still a working solution for me. I mean, when the checkbox is checked and the page is saved, than the fieldset is showed. If not checked, the fieldset is hidden via css
  13. Thank you all, It was my mistake, as the module itself was not properly loaded. The code above actually...works! sorry for that. Good to know that in PHP methods are not case sensitive! @Robin S yes I know and tried the module, what I do not like of that is the fact that creates additional db table to store progressive numbering, but I can't really say anything about what is the best approach in terms of efficiency and data storage. Btw, do you know how to store padded numerical values within the integer fieldtype? like this "0013" - I guess it requires changes to the default fieldtype behaviour in order to achieve this
  14. Hello PW community, I know this is a discussed topic in some other posts, but none of them seem to work when I try to implement found suggestions. Sorry for duplicate it. Goal: I would like to populate an integer fieldtype (called proj_code_sint) before a page is rendered in the admin, all from an autoload module. here's the sample code, which for unknown reason it doesn't do anything... <?php class moduleTitle extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return string * */ public static function getModuleInfo() { return array( 'title' => 'moduleTitle', 'version' => 001, 'summary' => 'Autopopulate integer fieldtype with incremental number', 'author' => 'mf', //'singular' => true, 'autoload' => "template=admin", ); } public function init() { $this->addHooKBefore("Inputfield::render", $this, "renderField"); } public function renderField(HookEvent $event) { $field = $event->object; // here custom logic if($field->name == "proj_code_sint") { $field->set('value', '123'); // example } } } Can you please suggest what I am missing here? maybe to save() the page at the end? thank you very much
  15. That's true, as you also stated in the github issue. My aim was focused on finding a temporary solution to let custom php selectors hide/show the fieldset group on a page save. By apply custom php selector with presentation "open", these selectors will not work simply because the fieldset group will be not rendered in the html code (at least in may case). Oppositely, by considering fielsdet presentation as "closed", your php-based filters seem working as the fieldset is rendered in the html code (thus managed by css on a page load). <div class="InputfieldContent">....</div> is the part of the fieldset that will be hidden/shown based on your php selector ( in my case I display the whole fieldset with a checkbox, after a page save). Bottom line: I totally agree with you statement below, that secures that no one can manipulate the hidden fieldset