Closed ghost closed 6 years ago
My plan here is to:
If there are any partial features that you don't think you'll be able to finish on the timescale of the playtest please list them them here, and I can move them to a branch so that the partial functionality won't be exposed in the initial deployment.
I can not reliably say if #13 and #18 will be ready in time which are the two features that I would like to be included in the first release. If it turns out that they won't be ready by then, I'll branch off a 'development' branch including all WIP features and remove them from master. Agree with your plans and will do my best to deliver in time.
I would ideally like to act on this over this coming weekend. Is this too soon for you?
Overview of pending todos:
[ ] #18: Finished but has some limitations: once a default badge is selected, you can not remove all default badges from the profile but only add/change them. Removing the last selected needs a reset all button. Needs +1 if we can leave it like it is for the moment.
[x] #7: Pending but is just copy/paste.
[x] #20: Can/will be deleted
[x] #25: Pending, will use confirm_box() that only triggers when there is no (revoked) key in the db for the user.
[x] ACP: Replace file selection with a textbox to enter URL for badge icon.
[x] ACP: Radio input for badge_os and badge_mod. The module is useless without them.
[x] ACP: New mode to add badge types.
[x] ACP: Show how many badges are linked to a badge type .
[x] ACP: Show how many users use a badge.
[ ] #14: Changed everything to reference to 24px icons, unless we want to leave that open to gather testing results I consider this done.
[x] #15: Pending, will be a SELECT 'revoked' ... WHERE fingerprint = $fingerprint
after if($duplicates) and then return the appropriate duplicate error.
[x] Check functionality of all features/buttons/critical errors (duplicates...) after everything above is done
[ ] Grammar and spelling check for descriptions, titles etc. and general +1 for them
re badge_os
and badge_mod
: we will want a different way to implement these - adding a new database column for each default badge category doesn't scale. For now we can use either one category for everything or hardcode the badge ids in the templates. We can't afford to delay the first release over getting this right.
You are right, my idea here is to add a openra_badge_types
table with columns badge_type_id
and badge_type_name
and add the column badge_type_id
to openra_badges
. This would allow to retrieve all default badges in one query instead of one per "type" like now and order the result set by badge_type_name
for example.
Ready to move.
There have been some more things I had to do:
Set line endings to LF
in all files.
Use consistent indentation in all PHP files, tab size is 8 spaces.
Remove WIP code from acp_badges.php
for the WIP module to refer badges to users.
Minor code change: S_ADD
in acp_badges.php
used isset()
to check if a array is empty, changed to use empty()
. This fixed the reset button not showing up in the ACP badges / types interface.
Remove prototype files from gitignore and remove them from the local repo. Added /.vscode
for my personal editor settings.
Changed my nick in the authors file.
I have tested the features after the changes and everything seems to work.
There have been some more changes since the last comment and the repository has been moved to OpenRA/openrauseraccounts, so I'm happy to close this.
It would be very cool if the repository could move over to OpenRA and I have no objections against passing over ownership, losing push access or other privileges. I consider my job with things I can do independently almost done and future implementations would probably need to be discussed between the OpenRA devs. I already feel a bit out of place when suggesting or even implementing things which affect their project.
The changes, issues or recently added and assigned milestones represent my very limited experience in coding and software development (this is my first real project) and I would be glad if more experienced people took the lead here while I stay contributing and learning. In fact, I wouldn't want to have push access to an official OpenRA repository considering how often I break things. There are still a lot of things that I would like to implement as I have fun working on this (yes, php can be fun!) but from here on I would feel happy to do it on a pr basis.
If this is possible would have to fix things like formatting in files and remove outcommented WIP code before.